Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Unexpected Phase 2 behaviour - combines two P2 to one established

    Scheduled Pinned Locked Moved
    IPsec
    1
    4
    208
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • keyserK
      keyser Rebel Alliance
      last edited by

      Hi All.

      I have two sites - both with proper internet connection, and all is working well. I have a IPSec Site-to-Site running between the two LAN networks which also works as expected.

      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

      I’m attempting to have a small subsection of static IPs on the site 2 LAN use the Internet breakout at site 1 instead of the local break out.
      So I created an additional P2 on each site (and the needed NAT rule on site 1):

      Site1 extra Phase 2:
      Local: 0.0.0.0/0
      Remote: 192.168.253.224/29

      Site2 extra Phase 2:
      Local: 192.168.253.224/29
      Remote: 0.0.0.0/0

      My expectation was that the policy tunnel routing would route the 8 named IPs (192.168.253.224/29) towards internet using the IPsec tunnel to Site 1 and provide internet access that way.

      But: While it works - the IPs are getting internet using site1’s NAT/public IP - the problem is all my LAN hosts on site 2 now uses the remote internet connection.
      When looking at IPSec status, only one Phase 2 is connected in both ends and looks like this (from site2):

      Local: 192.168.253.0/24
      Remote: 0.0.0.0/0

      So something unexpected is happening with my two phase 2 definitions. They get “combined” to the largest mask on both ends? Is that intentional or a flaw?
      Is there a workaround to have it honor the actual entered masks?

      keyserK 1 Reply Last reply Reply Quote 0
      • keyserK keyser referenced this topic on
      • keyserK
        keyser Rebel Alliance @keyser
        last edited by

        @keyser I created a redmine on this issue.
        I have confirmed by multiple tests that this is definitively a IPsec tunnled policy routing bug.
        And a rather security sensitive one at that:
        It also wrongly allows local/remote subnets in different P2s to reach each other - across P2’s - even though no P2 says they can.

        https://redmine.pfsense.org/issues/15460

        keyserK 1 Reply Last reply Reply Quote 0
        • keyserK
          keyser Rebel Alliance @keyser
          last edited by

          This post is deleted!
          keyserK 1 Reply Last reply Reply Quote 0
          • keyserK
            keyser Rebel Alliance @keyser
            last edited by

            Jim was so kind to update my redmine with the explanation and closed the ticket.

            The gist of it is that it is intended behaviour because SPDs are not an actual routing Table.
            But If you want proper separation between the overlapped example I made, you can enable “Split connections” on the P1 that contains multiple P2s. That ways they each become a distinctive P2 SPD in the kernel, and it only routes the specific P2 associations you have defined.

            Nice to know there was a solution, and case closed. Thanks @Jimp

            1 Reply Last reply Reply Quote 1
            • First post
              Last post