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

[mickbee]

What's your rule on the IPsec tab? Isn't it easier to use any -> any there?

Hi guys and Franco, any news on this? this is an issue since last december already and no sign of a fix for this :(

@Franco, i never thought that i'll see the day when someone suggest using any>any rules on an opensource/firewall product forum!?

[kyferez]

@Franco, i never thought that i'll see the day when someone suggest using any>any rules on an opensource/firewall product forum!?

I agree, but perhaps he was meaning as a troubleshooting step to verify it's not a issue with a rule not working as intended?

Which brings me to: Why do the rule logs not show Which Rule was hit? :(

[franco]

So just quickly I spent a whole week in total trying to chase this down in FreeBSD 11 but have been unable to find the bug in the kernel so far. If someone is up for the task that would be tremendously helpful.

The filtering in the IPsec tab is for "incoming" IPsec traffic only. If you want to prohibit traffic from entering the tunnel it's the wrong place.

Establishing an IPsec tunnel to another end places trust into it. I do not think it counts as leaving the door open to anything and all possible threats. The filtering here is convenient, but having had 6 months with no conclusion may also point to experts who could fix this judging that it's not worth fixing.

I'm no such expert. I don't know. We can surely find a fix for this eventually, but between spending a week and spending the amount necessary there is a big gap that a community will either have to help close or feel comfortable not closing.


Cheers,
Franco

[liberomic]

Hi Franco,

thanks for your reply, do you have a tecnique to set my workaround permanent?

I have deleted this line from /tmp/rules.debug
block in  log inet from {any} to {any} label "Default deny rule"
block in  log inet6 from {any} to {any} label "Default deny rule"

I have added this line at the end of file  (all interface without IPSEC "enc0")

block in  log on $WAN inet from {any} to {any} label "Default deny rule"
block in  log on $WAN inet6 from {any} to {any} label "Default deny rule"
block in  log on $LAN inet from {any} to {any} label "Default deny rule"
block in  log on $LAN inet6 from {any} to {any} label "Default deny rule"

# pfctl -f /tmp/rules.debug

Regards,
Liberomic

[franco]

There is a new test kernel that restores inbound logging / filtering for me...

# opnsense-update -kr 17.1.9-ipsec
# /usr/local/etc/rc.reboot

To go back to the normal kernel, use...

# opnsense-update -k
# /usr/local/etc/rc.reboot

Feedback welcome, maybe able to merge in time for 17.7 :)

[franco]

I think I have an unproblematic solution now with the kernel posted above. It's really crucial to get feedback to get this into 17.7 in time... ;)

[liberomic]

Hi Franco,

IT WORKS!!!!  ;D ;D ;D

I have tested in my lab and work fine!!!!

In my production enviroment I have the version 17.1.6, Do you suggest doing any updates first to 17.1.10 and then changing the kernel?

Many thanks
Liberomic

[mickbee]

I have one device i can test and rollback (vm) without disrupting some realtime stuff - i can do that tomorrow morning CET and feed back immediately. This is exciting!

@Franco, really appreciate your efforts and help in this space!

[franco]

@liberomic it should work by only replacing the kernel. but don't forget to reboot.

@mickbee thanks, looking forward to your feedback.

To be honest, the issue is still obscure: the packet filter receives "garbage" as the IP header, and that only for inbound packets from the tunnel.... it may still not work for filtering TCP ports, I haven't checked. What I could find was that this affects a subset of IPsec connections, namely the ones that do have their IPsec not connected to WAN so NAT-T handling in IPsec plays a heavy role in solving this in a way that compares to the state of FreeBSD 10.3.


Cheers,
Franco

[franco]

BTW, the patch is this, it will be available in 17.7.

https://github.com/opnsense/src/commit/0de7c3a57


Cheers,
Franco

[mickbee]

Hi Franco, again thanks for following up!

I tried the upgraded kernel and it doesn't seem to change much but then again, the VM machine sits behind a physical opensense box which I can't really touch (several thousand km away and no one to help fix it in case it becomes irresponsive) and which has the issue in question.

I have another one next to me which suffers from the same bug but this one needs to be up for the next 7 hours. I'll try as soon as people go home and report back.

Still, since the patch will already be included, i suppose thorough testing can wait for the weekend?

regards,
m.

[franco]

Hi m,

We have tested a number of deployments with and without NAT-T, the behaviour is not different without it and considerably better when NAT-T is used.

If there are reasons to pull it from 17.7 please speak up. All testing is appreciated to see where we are at to make a balanced decision.


Cheers,
Franco

[liberomic]

Hi Franco,

we want test this on new device in production but the file is missed.

opnsense-update -kr 17.1.9-ipsec
Fetching kernel-17.1.9-ipsec-amd64.txz: ...opnsense-verify: Unable to open /var/cache/opnsense-update/69564/kernel-17.1.9-ipsec-amd64.txz: No such file or directory
failed

We have updated to 17.1.11, this fix is included?

Regards,
Liberomic

[franco]

Liberomic,

Sorry, I removed the test kernel. You can use the upcoming 17.7 release kernel safely:

# opnsense-update -kr 17.7


Cheers,
Franco