GRE over IPSec state issues

Started by obrienmd, October 11, 2017, 12:33:22 AM

Previous topic - Next topic
Hi all - I was hoping that OPNSense would resolve this issue I've had long-standing on the pfSense side. Essentially, the firewall is unable to properly set states on traffic coming over a GRE that's using an IPSec transport. Here's the pfSense issue:

https://redmine.pfsense.org/issues/4479

Does anyone have stateful firewalling over GRE/IPSec(transport) working? It's possible I'm just missing something simple :)

I tried this a little while ago but the problem was the strong swan implementation. I tried the openbsd ipsec and there I got this working though.

As in you tried it in FreeBSD via a port?

It's totally unclear what the issue is despite 2 years of bug history. 11.1 is radically different in terms of IPsec, but I doubt that it magically fixes this. It could just be a filter rule generation bug that they try to work around there with floating rules.

Setting "sloppy state" or not state at all on both sides via the IPSEC rules tab for the pass rule specifically for GRE may help, after all it should go into the tunnel, or does it not?


Cheers,
Franco

Historically, I've had to do one of two things to resolve this, and have never had luck with sloppy state.

1) SEEMS OK: Set a floating rule, include the GRE interface, enable quick, target outbound only, set state to none and TCP flags to any, and use action pass. Traffic is controlled by knowing that only the router and any traffic it lets in to forward to send outbound on that interface.

2) BAD CLEARLY: Set a pair of stateless floating rules for each stateful rule I would normally configure, for example if my floating rule was to allow devices over the GRE tunnel in 192.168.0.0/24 to reach 192.168.99.10 over RDP (3389) locally, I would create the following two rules:
a) int lan,gre0 direction any src 192.168.0.0/24 srcport any dst 192.168.99.10 dstport 3389 flags=any state=none
b) int lan,gre0 direction any src 192.168.99.10 srcport 3389 dst 192.168.0.0/24 dstport any flags=any state=none

I'm open to better ideas. 2 is terrible as it allows any traffic from srcport 3389 on .99.10 to anything, obviously. 1 doesn't seem bad given if someone owns the firewall we're in trouble anyway.



So the bug should be fixed in the FreeBSD base? I'm not an expert, do you know if it is safe and how to apply the workaround:
"set skip on gre0" to allow the traffic to go through the tunnel?

__
Augusto B.

Maybe I missed the basics, but trying to investigate
sysctl -w net.inet.gre.allow = 1
I get: sysct: unknown oid 'net.inet.gre.allow'
It seems the kernel module if_gre.ko is loaded.

__
Augusto B.