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

[framura]

HI,

I just upgraded from 16.7.14 version and all seems works very well but not firewall rules.

I have some firewall rules (LAN Tab) to force VPN use on my LAN net: with 16.7.14 all works well but with 17.1 (I haven't modify any configuration) same rules doesn't works anymore.

Can you give me some advice?

Thanks in advance

P.S.: Now I reverted to 16.7.14 (Vmware machine) but I will try also with a fresh installation

[franco]

Hi,

We've had a similar situation here in 17.1-BETA:

https://github.com/opnsense/core/issues/1331

Can you send us a copy of the file /tmp/rules.debug on the working 16.7.14 *and* the broken 17.1?

If yes we can fix this in no time. Send via mail: project AT opnsense DOT org


Thanks,
Franco

[Andreas]

Hi.
updated also and this behavior also. My IPSEC Connection is now blocked - the rules are set and it worked before 17.1

thx

[mircsicz]

Hi hi, just upgraded three of my installation's two of them went smooth a third has firewall rule issue's as mentioned!

[franco]

At least in one of these cases it was a pfSense config.xml. We're investigating the rules generation now.

[virusmoere]

Hi,

I have the same problem. Some rules are not working after upgrate to 17.1.


Regards

[mmoser]

Hi,

I have the same problem. I had a rule that routes a VPN connection to a dedicated WAN interface and it's not working anymore.

I've attached the rule itself that worked before the upgrade to 17.1.

Thanks,
Martin

[dragon2611]

Same here ipsec doesn't appear to work unless I disable PF.

I did import from a pfsense config though so totally posisble that's screwed something

[franco]

Can you guys confirm this is happening specifically to IPsec? If yes, which software/appliance is on the other end? Just to make sure we pin this down correctly and I think we can exclude the possibility of compatibility issues with pfSense imports.

I'm having trouble with a FortiGate, it seems that TCP state is not properly tracked and thus times out prematurely. Anything larger than a few seconds is killed by pf / the default rule. These blocks show up in my firewall log with the default rule as the culprit, which is odd, because the IPsec rule says allow all and ICMP/UDP fully works and TCP kind of works. Something is wrong with the state tracking it seems, settings in the GUI didn't help so far.


Cheers,
Franco

[Trebor1]

Hi,

I have 3 WAN and after upgrading to the 17.1 I do not respect me the GW's in rules. Always it use default gateway.

Thanks

[framura]

Hi,

I just sent via email my two rules.debug files, one from 16.7 (working) and other from 17.1 (not working).

[mmoser]

Hi,

I just tested to add a rule that should route IPv4* traffic from any source to a specific IP address using a dedicated Gateway. The rule is not applying and the default Gateway is being used instead. So it's not limited to IPSec.

Thanks,
Martin

[framura]

Hi,

these is any news about this?

Thanks

[franco]

The IPsec instability in TCP is caused by a faulty state tracking. I have no idea where to look at the moment but I found that the state tracking can be disabled using the following workaround for the IPsec connections:

You can check whether you're affected by verifying this via command line:

# pfctl -s info

"state-mismatch" will increase frequently, one time for every reset TCP session.

Create a floating rule with "pass" and "quick" (default), interface "IPsec", direction "out", source is your local IPsec reachable network (or an alias if you have multiple networks), destination is your remote IPsec network (or an alias if you have multiple networks), go to the bottom and click "advanced options", set "state type" to "sloppy state". Save + Apply.

Please let us know if that helps your issue(s). We are looking for a way to fix this within FreeBSD itself if that is possible.


Cheers,
Franco

[framura]

Thanks franco,

but my problem is not linked to IPSec: I use some rules on LAN side with a specific gateway group (I sent yesterday my two /tmp/rules.debug files, one for 16.7 and one for 17.1).

Thanks