As mentioned in https://lists.ipfire.org/pipermail/development/2019-December/006724.html , after installing Core Update 139 (testing), traffic to the remote end of IPsec N2N connections is not routed through the IPsec tunnel - if it eventually comes up -, but emitted to the internet directly. This is an information leakage which puts user data at risk. Root cause is unknown at the time of writing.
/var/log/messages contains these log lines when trying to manually establish the IPsec N2N connections: Dec 12 20:55:06 maverick ipsec: Creating route to 10.XXX.XXX.0 [REMOTE IPSEC #1 GREEN NETWORK]/255.255.255.0 (via 10.XXX.XXX.1 [GREEN IP] and ppp0) Dec 12 20:55:06 maverick ipsec: Creating route to 10.XXX.XXX.0 [REMOTE IPSEC #1 ORANGE NETWORK]/255.255.255.0 (via 10.XXX.XXX.1 [GREEN IP] and ppp0) Dec 12 20:55:06 maverick ipsec: Creating route to 10.XXX.XXX.0 [REMOTE IPSEC #2 GREEN NETWORK]/255.255.255.0 (via 10.XXX.XXX.1 [GREEN IP] and ppp0) Dec 12 20:55:06 maverick ipsec: Creating route to 192.XXX.XXX.0 [REMOTE IPSEC #3 GREEN NETWORK]/255.255.255.0 (via 10.XXX.XXX.1 [GREEN IP] and ppp0) I never observed them before.
This is caused by having NFQUEUE rules for suricata in place, but suricata itself isn't running. I consider this being a problem in the Linux network stack that we probably cannot fix. However we can work around this by moving the IPSECBLOCK chain before the IPS chains so that packets will be classified by the correct XFRM policies. Peter knows how to do this. Please submit a patch.
This is partially fixed by https://patchwork.ipfire.org/patch/2644/ .
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fd2dccaabb2e28cf875d7d81c7faf90f7941f56b
This problem is much worse than initially thought: If Suricata is enabled and running, IPsec traffic from the firewall machine itself to an remote IPsec N2N destination is also emitted directly to the internet. Steps to reproduce: (a) Create an IPsec N2N connection (remote IPsec software does not matter). (b) Enable the IPS and reboot. (c) Wait for the IPsec tunnel to come up and ping any remote destination from the local firewall itself. This traffic is now directly emitted to the internet. (d) Disable the IPS and reboot. (e) Repeat (c). Traffic is now correctly passed through the IPsec tunnel. Perhaps another strange NFQUEUE bug where the packets lose its tags? Since I do not have sufficient network knowledge for solving this, I am assigning it to Michael and be happy to answer questions. :-)
https://patchwork.ipfire.org/patch/2727/ fixes the VPN traffic leak if the IPS was enabled but crashed meanwhile. However, this still does not fully solve this issue, as traffic from the firewall itself is still emitted directly to the internet under certain circumstances (see comment #5).
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5dba838282f23954a1cfeb4586b1cabc294a9b32
Well, at least this one is ON_QA now (https://blog.ipfire.org/post/ipfire-2-25-core-update-143-is-available-for-testing). However, there is still a solution for #c5 missing.
https://blog.ipfire.org/post/ipfire-2-25-core-update-143-released Solution for https://bugzilla.ipfire.org/show_bug.cgi?id=12257#c5 is still missing.
(In reply to Peter Müller from comment #9) > Solution for https://bugzilla.ipfire.org/show_bug.cgi?id=12257#c5 is still > missing. What can we do about this one? We could in theory drop all packets that have not been marked (i.e. suricata has crashed), but then we would cut off people's Internet. Removing the --bypass switch can do that for us, too.