Bug #15460
closed
Kernel routing SPD Database gets “supenetted” wrong from multiple P2’s
0%
Description
I have confirmed this bud with multiple tests:
Scenario:
Two sites - both with proper internet connection.
IPSec tunneled policy based Site-to-Site between the two LAN networks created with one P2 on each site:
Site1 Phase 2 setting:
Local: 192.168.255.0/24
Remote: 192.168.253.0/24
Site2 phase 2 setting:
Local: 192.168.253.0/24
Remote: 192.168.255.0/24
Everyting is working completely as expected.
Attempting to have one IP or a small subsection of static IPs on site2 LAN use the Internet breakout at site 1 by adding an additional P2 will expose the SPD Database routing flaw:
Example of Additional P2 added to each each site:
Site1 extra Phase 2:
Local: Network: 0.0.0.0/0
Remote: Address: 192.168.253.224
Site2 extra Phase 2:
Local: Address: 192.168.253.224
Remote: Network: 0.0.0.0/0
Expectation is that the policy tunnel routing would route the named IP (192.168.253.224) towards internet using the IPsec tunnel to Site 1 and provide internet access that way.
But: The Kernel SPD database is constructed falsely from the two P2’s an consequently starts routing all Site2 hosts towards internet over the IPSec tunnel.
When looking at IPSec status, only one Phase 2 is connected in both ends and looks like this (example from site2):
Local: 192.168.253.0/24
Remote: 0.0.0.0/0
The two phase 2 definitions get “combined” to one SPD routing entry in the kernel with the largest mask used in both ends.
This causes all hosts to get routed towards the internet using site 1 (which is wrong here)
Other examples of problems that arise from this bug is that all P2 named local subnets can reach all P2 named remote subnets (if a firewall rule allows) regardsless of weather there is a P2 policy allowing it.
I consider this not only a bug that prevents conditional routing with different P2s but also a major security issue if you are using more than one P2 in a Site-2-Site connection.
Updated by Jim Pingle 12 days ago
- Status changed from New to Not a Bug
- Priority changed from High to Normal
There are two things that could be a factor here and either one could be affecting it, but neither is a bug.
1. The IPsec SPD is not a routing table and doesn't work the way you describe. You could put the more specific P2s up higher in the list.
2. If you are using IKEv2 then combining P2 networks is the default but you can change that by enabling the "split connections" option in P1: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html#advanced-options
Updated by Tue Madsen 12 days ago
Hi Jim. I stand corrected for calling it a bug. Thanks for Clarifying how this actually works in the Kernel.
Reordering the P2s does not change anything and it still combines the two P2s to one with the widest mask in local and remote.
But I can confirm that enabling “split connections” does the trick and creates two separate P2’s - each restricted to the actual traffic they are supposed to route.
So you are evidently correct - it’s not a bug, but in my opinion a pretty “dangerous” default to use.
I think “split connections” should be the default - In fact, I fail to see the usecase for not having that enabled.