Bug #15460
closedKernel 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.