pfSense

this doesn't appear to happen on stock FreeBSD 11 unless there's something more to it than a single pass rule with keep state. Need to evaluate further to determine if it's still an issue in 2.3/10-STABLE.

I can confirm this still happens with both GRE and GIF tunnels over IPsec on pfSense 2.3.1

I can confirm this still occurs on 2.3.2. Probably worth checking on 2.4 since Chris had mentioned it seemed to be resolved on FreeBSD 11

Jorge Albarenque wrote:

I can confirm this still occurs on 2.3.2. Probably worth checking on 2.4 since Chris had mentioned it seemed to be resolved on FreeBSD 11

It is broken in 2.4 as well.

It appears to be worse than before now too.... ICMP doesn't work across the tunnel now either.

Testing on 2.4 won't be reliable until #6937 is fixed.

Jim Pingle wrote:

Testing on 2.4 won't be reliable until #6937 is fixed.

Apparently this only affects mobile IPSEC. Is this still applicable?

After some further testing, ICMP does work across the tunnel (Windows Firewall tricked me), but TCP connections are still being blocked (I can see it in the log)

Has anyone managed to test on 2.4 yet? Experiencing this issue in 2.3 latest.

Confirmed still not working on 2.4

This affects both GRE over IPSEC transport and IPSEC tunnel mode carrying a GRE

All traffic exiting the GRE tunnel is seen as coming from the host itself and matched by the following rule inserted by filter.inc, which comes way before any user rules:

1. let out anything from the firewall host itself and decrypted IPsec traffic
   pass out {$log['pass']} inet all keep state allow-opts tracker {$increment_tracker($tracker)} label "let out anything IPv4 from firewall host itself"

It is therefore impossible to filter traffic coming in across the GRE at all and state is not created for the return traffic on the GRE interface.

The 'workaround' of creating a floating rule on GRE with sloppy state, combined with the matching above effectively means no firewall at all on the GRE tunnel and is not an accepable solution!

Tested on the latest 2.4 snapshot:
2.4.0-BETA (amd64)
built on Tue Mar 21 07:14:38 CDT 2017
FreeBSD 11.0-RELEASE-p8

I don't see any target version on this bug. Is this being worked on? Any chances this could be fixed for 2.4?

I'm on 2.4-RC... if I reset the states, it starts working.

Wagner Sartori Junior wrote:

I'm on 2.4-RC... if I reset the states, it starts working.

Check your states for traffic matching what should be the GRE outer and inner traffic when it does and does not work. What is the difference?

1. Working
   enc0 gre 1.1.1.1 -> 2.2.2.2 MULTIPLE:MULTIPLE

1. Not Working
   pppoe0 gre 1.1.1.1 -> 2.2.2.2 MULTIPLE:MULTIPLE

I tried to kill only this state, but it also doesn't work. only flushing the whole state table made it work again.

Add a floating rule to block, quick, in the out direction on that WAN (pppoe0) any GRE traffic, then reboot and see if it makes a difference.

OK, if that fixed it, then it isn't related to the problem originally stated on this ticket, which is for a state issue inside the tunnel.

sorry for that than.

Any chance 2.4.0, with the FreeBSD 11.1 ipsec changes, may resolve this?

Michael OBrien wrote:

Any chance 2.4.0, with the FreeBSD 11.1 ipsec changes, may resolve this?

Just loaded up 2.4.0 on a few firewalls and tested. Unfortunately, the bug still exists.

I can confirm that 2.4.2_1 is still affected. So for now, its not possible to do site to site IPSec tunnel (except in tunnel mode, which doesn't scale as soon as you have more than two or three networks per site). Any workaround ? For now I'm using OpenVPN, which is far easier to deal with, but is a bottleneck performance wise on high speed links.

Can someone confirm whether or not this bug explains the following situation?

I have a GRE tunnel set up between OpenBSD and pfSense, secured via IPSec in transport mode. From the remote OpenBSD system, I can ping a host in my pfSense "LAN" subnet even though there is no rule allowing that traffic (I've disabled the default any/any). I can also send TCP SYN packets; the replies never get back through, blocked by the default IPv4 block rule.

Running 2.4.2_p1. Is this also an issue with upstream FreeBSD?

For what it is worth, I have reproduced this on stock 12-CURRENT.
-Eric

For reference, the upstream bug opened by Eric: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226411

Ermal says there is code in Darwin that addresses this.

Does pfSense patch freebsd kernel for some custom/not working on plain kernel? It will take some time until somebody on freebsd actually implement that.

Darwin freebsd kernel probably have this fixed as explained earlier.

He recently said to check the current code and compare:
https://github.com/apple/darwin-xnu/blob/master/bsd/net/pf.c

Interested to know why do you (or pfSense) think this is not a high priority.

On my point of view (that I know doesn't matter to you or pfSense), this is a huge problem as there's no way to restrict the traffic on the GRE interfaces when running through ipsec.

I confirm the problem in the version 2.4.4

I stumbled across this issue when deploying pfSense for a wireless carrier integration. We needed to do things like policy routing and so the workaround using floating rules is not an option as it does not match incoming traffic.

As a result we had to use an alternative open source router/firewall platform for the project.

This is similar, if not identical, to #8686 -- and the same workaround functions for both, it turns out.

You can make this work by going to VPN > IPsec on the Advanced Settings tab, and setting IPsec Filter Mode to filter on VTI assigned interfaces. This will block all tunnel mode traffic, but the states will work correctly in both directions on transport mode GRE interfaces.

I'll update the GUI text to reflect that discovery.