Page MenuHomeFreeBSD

Add an ability accept encapsulated packets from different sources by one gif(4) interface
ClosedPublic

Authored by ae on Mar 3 2015, 5:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Jul 3, 11:36 AM
Unknown Object (File)
Apr 26 2024, 7:03 AM
Unknown Object (File)
Apr 6 2024, 2:41 PM
Unknown Object (File)
Jan 9 2024, 12:27 AM
Unknown Object (File)
Dec 19 2023, 11:28 PM
Unknown Object (File)
Nov 7 2023, 5:49 AM
Unknown Object (File)
Nov 3 2023, 5:30 AM
Unknown Object (File)
Nov 2 2023, 2:28 PM
Subscribers

Details

Reviewers
ae
Group Reviewers
network
Summary

In some cases it can be handy, to be able handle encapsulated packets from several load balancers without need to configure individual gif(4) interface for each balancer. This patch add the option "ignore_source" for gif(4) interface. When it is enabled, gif's encapcheck function requires match only for packet's destination address.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ae retitled this revision from to Add an ability accept encapsulated packets from different sources by one gif(4) interface.
ae updated this object.
ae edited the test plan for this revision. (Show Details)
ae added a reviewer: network.

Hi!

I'd rather we added an option to have a v4/v6 table for source/destination for gif. Sort of like the table option for ipfw does.

So, I'm okay with this as it serves a real purpose, but I'd be much happier with a table driven solution.

Just curious, is it difficult to handle this situation by using multiple gif(4) interfaces?

Even if so, I am feeling we still need some measure to limit an address range because it makes injecting malicious packets easier. If I understand this load balancer case correctly, packet's source addresses which need to be accepted are in a small address range which can be calculated by using the address of gif(4)'s tunnel endpoint and an address mask. Thus it may be reasonable to implement prefix length option to allow a range of addresses instead of completely disabling the source address comparison.

Both table and "multiple gif interfaces" approaches require us to know in advance the exact list of sources. In our situation (connections come from IPVS balancer(s) with ipv6-in-ipv6 encapsulation, IPVS balancers are managed by other people) it is hard to keep this list up-to-date.

It will be point of failure when new IPVS balancer is added and everyone forget to add the corresponding gif interface.

As far as I understand, Linux' tunnel6 kernel modules acts like this: it ignores src, removes outer IP6 header and injects packet back to network stack for further processing.

Ok. I'm ok with this feature then. I recall the WCCP GRE IPv4 decapsulation setup is much the same.

Have you tested this on both v4 and v6 interfaces?

Speaking of me, I tested only IPv6 case.

We use this patch for two months, and if there are no objection against it, I'll commit it.

ae added a reviewer: ae.
This revision is now accepted and ready to land.May 15 2015, 12:22 PM