Upgrade from 16.7.14: Firewall rules doesn't works as before

[mw01]

OpenVPN Client with specific firewall client rules routed through the WAN-VPN gateway no longer works the way it used to - the default gateway WAN-DHCP is always utilized. 

OpenVPN advanced configuration with "route-nopull; route-noexec;" following OpenVPN stop/start results in broken pipe log message - probably why it does not work.  Removing these results in OpenVPN added routes and all traffic from all VLANs is routed through the WAN-VPN gateway.

Feb 5 06:49:21    openvpn[19626]: MANAGEMENT: Client disconnected
Feb 5 06:49:21    openvpn[19626]: MANAGEMENT: TCP send error: Broken pipe
Feb 5 06:49:21    openvpn[19626]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Feb 5 06:49:21    openvpn[19626]: Initialization Sequence Completed

[franco]

Dragon, I have the same issue here locally for incoming IPsec traffic. It could be FreeBSD 11.0 in this case indeed. I fixed it up temporarily by allowing IPsec subnets from WAN to LAN, disabling blocking of private networks. We're investigating this, too.

[dragon2611]

I'll be redoing my network at somepoint soon so the design may change.

At the moment the Opensense is doing the Site2site VPNS and IDS/IPS for the IOT vlan.

The other Vlans go directly to a routerOS vm which also has the PPP termination from the ISP (I couldn't seem to get the performance on my N3150 in KVM with IPS enabled, I think because FreeBSD's network drivers are a bit shit in KVM, have to use E1000's as VirtIO + IDS/IPS = Crash) Anyway that's why the LAN/Wan interface are the same as far as opnsense is concerned.

Going from ~68/17 VDSL2 to 200/20 cable due to a move sadly, probably with most of my traffic limited to 100/20 by an L2TP tunnel (Old ISP lets me L2TP-in capped at 100M and I want to keep my static IP's)  Now normally people would consider going from 68 > 200 an upgrade but I'm essentially going from a Decent ISP to a not so Decent one.

Might have to get an ADSL2+ line (About 15/1 if I'm lucky) from the current ISP if the cable proves to be congested in that area (No VDSL2 service available )

[mow4cash]

I think I'm having the same issue? I route an alias through Opnvpn gateway and have a rule to block the alias on the default wan gateway. Something failed and the traffic is getting routed through the wan. This is a huge security issues, I'm not sure if it's something I did or not.

[mw01]

Thank you all.  Upgraded to OPNsense 17.1 to 17.1.1, no issues. 

Started up OpenVPN and broken pipe fixed.  Initially could not resolve address (tracert) through VPN (DNS servers specified on Windows box).  Started/stopped OpenVPN and everything lined up.  Works great!

[Andreas]

Any News? Any new fix? actually i dont have a functional IPSec

[miclan]

Me too, still waiting for a fix...

[franco]

Workarounds for different issues are available. Unfortunately, there are a number of interleaving issues in this thread. I am not sure which one you are waiting for.

Some have been addressed for 17.1.1. We're adding more for 17.1.2 including going back to the default incompatible routing behaviour of pf and ipfw. The feature can still be used, but needs to be enabled in the GUI.

This should bring is back to a state that is unmodified, not counting problems with could still be present in the base system due to the FreeBSD 10.3 to 11.0 switch. At this point, it's unclear how much changed, but we know of an IPsec state tracking issue that is new there and likely also IPv6 policy routing problems. We are actively investigating all of those.

The bottom line is: there is a reason we are seeing these problems now going forward, because they are incredibly hard to catch. We are not alone in this, as such issues pop up in other FreeBSD-related projects as well, even in the FreeBSD bug tracker. If we decided not to go forward with an OS update, the downsides become more and more with time, increasing the amount of time it takes to adapt to another OS update in the future. It's a slippery slope.

If anything, we need to avoid standing still.


Cheers,
Franco

[pbolduc]

I wanted to mention I have recently setup a clean install of 17.1 & experienced most concerns mentioned above. (Traffic not flowing through IPsec tunnels). I had performed the 17.1.1 update out of desperation hoping it would address the problem and it did for about 2 minutes then the traffic stopped flowing through the tunnels again. It wasn't until I performed a factory reset back to factory defaults using the latest firmware 17.1.1 and setup the IPsec tunnels again before the problems were completely resolved.

Going forward, my concern would be after upgrading to 17.1.2 down the road will it require us to factory default the router before things work as expected or can we still use our existing configs without needing to reconfigure everything over again?

[franco]

I can't say for sure, mostly be cause there are no details about your setup. But I can say that 17.1.2 should behave the same as 17.1.1 with one exception in the policy routing domain: we will be using the stock FreeBSD behaviour by default again. If your setup is affected by this because you run Policy/Gateway Routing in firewall rules *and* use the traffic shaper or captive portal, this option needs to be reenabled under firewall: settings: advanced: "Use shared forwarding between packet filter, traffic shaper and captive portal".


Cheers,
Franco

[miclan]

I upgraded to 17.1.2 and my situation with IPsec tunnel site to site is:

VPN site A (main) 17.1.2
VPN site B (remote office 1) 17.1.2
VPN site C (remote office 2) 16.7.14

From A to B connection is OK, but no traffic on LAN
From A to C connection and lan traffic OK

I understood that this problem is very difficult to isolate, but what can I try to have lan traffic between A and B?

[franco]

On B, add a floating rule for interface "IPsec", set it to direction "any", go to advanced, choose "sloppy state". Save and apply the rules.

Then, from the console run:

# sysctl net.inet.ipsec.filtertunnel=0

You should now be able to make connections from A to B?

[Andreas]

Hi,
updated on 17.1.2 still having problems
firewall blocks all communication and i see that in the logs

[Andreas]

HI Franco
i tested your solution in the post from February the 22 - at my setup it doenst work

[lordwarlock]

Same here,

Workarround 
sysctl net.inet.ipsec.filtertunnel=1
doesnt work anymore after upgrade from 17.1.1 to 17.1.2

tried

sysctl net.inet.ipsec.filtertunnel=0 + Floting Rule does not work

Connection from LAN to IPSEC possible
Connecitons from IPSEC to LAN (Ping -> Possible, everything else -> Impossible)