| Summary: | traffic to IPsec N2N destinations is emitted to the internet directly | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Peter Müller <peter.mueller> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | ASSIGNED --- | QA Contact: | Peter Müller <peter.mueller> |
| Severity: | Security | ||
| Priority: | Will affect an average number of users | CC: | arne.fitzenreiter, michael.tremer, stefan.schantl |
| Version: | 2 | Keywords: | Security |
| Hardware: | all | ||
| OS: | All | ||
| See Also: |
https://bugzilla.ipfire.org/show_bug.cgi?id=12256 https://bugzilla.ipfire.org/show_bug.cgi?id=12280 |
||
| Bug Depends on: | 12260 | ||
| Bug Blocks: | 11618 | ||
|
Description
Peter Müller
2019-12-12 19:41:26 UTC
/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/ . 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). 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. |