Bug 12257

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: 2Keywords: 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
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.
Comment 1 Peter Müller 2019-12-12 20:02:20 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.
Comment 2 Michael Tremer 2019-12-13 11:53:41 UTC
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.
Comment 3 Peter Müller 2019-12-13 17:31:06 UTC
This is partially fixed by https://patchwork.ipfire.org/patch/2644/ .
Comment 5 Peter Müller 2020-01-26 16:39:58 UTC
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. :-)
Comment 6 Peter Müller 2020-01-27 15:07:17 UTC
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).
Comment 8 Peter Müller 2020-04-10 11:14:53 UTC
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.
Comment 10 Michael Tremer 2020-04-27 09:17:06 UTC
(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.