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

    P2 subnet overlap

    Scheduled Pinned Locked Moved IPsec
    8 Posts 3 Posters 863 Views
    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.
    • W
      wickeren
      last edited by wickeren

      Was wondering when p2 subnet overlap will be problematic.
      I do understand that if both local and remote subnet overlaps it will cause problems.

      But what if I have two different P1โ€™s with both just one P2, with different local subnets, but duplicate/overlapping remote subnets?

      e.g:
      one P2 with local 192.168.0.0/24 and remote 10.10.10.0/24 and
      one P2 with local 192.168.1.0/24 and remote 10.10.0.0.16
      Both p2โ€™s on DIFFERENT P1.

      Will that lead to routing confusion between the remote subnets because they partially overlap? Or will the source subnet be taken into account to determine where packets should go and will it all be fine?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        In that specific case with IPsec, the source:destination combination is taken into consideration so you shouldn't have any problems with the setup as you describe it there.

        Not relevant to your case, but in other cases with routing, a more specific match wins. So if this was with, say, OpenVPN or standard interface routing, the more specific route (/24) would win without considering the source. You could still talk to the /16 except for the portion that overlapped.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        JeGrJ 1 Reply Last reply Reply Quote 2
        • W
          wickeren
          last edited by wickeren

          Thanks a lot, that will make my life and the life of the administrator of the other side of the IPSEC-tunnel easier because no NAT-translation before IPSEC is needed. Sometimes itโ€™s not even possible to do that on the remote device, depending on the brand and type.

          Your second remark is also good to know, more specific/smaller subnet has priority. It might be useful one day or another.

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator @jimp
            last edited by JeGr

            @jimp said in P2 subnet overlap:

            In that specific case with IPsec, the source:destination combination is taken into consideration so you shouldn't have any problems with the setup as you describe it there.

            Quick question about that: So I could probably have two phases with identical remote network (say 192.168.0.0/24) for two different customers with different local networks (each customer its own project network) and as they are in different P1/P2 combinations they wouldn't interfere with each other?

            Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            W 2 Replies Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              As long as you don't have both a local and a remote which overlap (e.g. 192.168.0.0/24 locally and on a remote) then the other scenario should be fine, since it takes an exact source and destination match for traffic to be associated with a given P2.

              Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              JeGrJ 1 Reply Last reply Reply Quote 1
              • JeGrJ
                JeGr LAYER 8 Moderator @jimp
                last edited by

                @jimp said in P2 subnet overlap:

                As long as you don't have both a local and a remote which overlap (e.g. 192.168.0.0/24 locally and on a remote) then the other scenario should be fine, since it takes an exact source and destination match for traffic to be associated with a given P2.

                Thanks for clarification. Somehow I forgot about that tidbit and that it's one of the reasons IPSEC routes aren't shown/handled via system routing table :)

                Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 1
                • W
                  wickeren @JeGr
                  last edited by

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • W
                    wickeren @JeGr
                    last edited by

                    @JeGr said in P2 subnet overlap:

                    So I could probably have two phases with identical remote network (say 192.168.0.0/24) for two different customers with different local networks (each customer its own project network) and as they are in different P1/P2 combinations they wouldn't interfere with each other?

                    That matches exactly my use case!
                    Too be honest, there already was some remote subnet overlap. Normally I would ask the other end to do some NAT before IPSEC to prevent overlap, but I missed it in a couple of occasions and it just seemed to work. I asked just to make sure if it was supposed to work that way.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.