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

    (Solved) Setting up multiple IPsec VPNs

    Scheduled Pinned Locked Moved IPsec
    5 Posts 3 Posters 1.5k 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.
    • A
      awsiemieniec
      last edited by

      pfSense 2.1.5

      I have two branch offices with the same subnet - 192.168.1.0/24
      Both branches need to connect to the same HQ office at IP 198.145.XXX.YYY
      Branch A has a server at 10.10.10.21/30
      Branch B has a server at 10.10.10.28/30
      I don't want communication between branches.
      Branches have SonicWALL devices.

      I have been running the first branch fine for months; no issues.  With the addition of the second branch I get trouble.
      In the HQ pfSense, Firewall, Rules, IPsec I have a destination set to the specific server this branch needs to access (10.10.10.21/30)  When I created the second rule I realized I had to make a determination that this branch needs to only access their server at 10.10.10.28/30.  Since both offices have the same subnet, I can't set a rule up that says source = 192.168.1.0/24.

      What is the best way to handle this?  Do I need to setup an external IP for each branch at the HQ and IPsec tunnel to that?  Do I change a port…?

      Thanks.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        @awsiemieniec:

        pfSense 2.1.5

        I have two branch offices with the same subnet - 192.168.1.0/24

        Oops.

        Both branches need to connect to the same HQ office at IP 198.145.XXX.YYY
        Branch A has a server at 10.10.10.21/30
        Branch B has a server at 10.10.10.28/30
        I don't want communication between branches.
        Branches have SonicWALL devices.

        I have been running the first branch fine for months; no issues.  With the addition of the second branch I get trouble.
        In the HQ pfSense, Firewall, Rules, IPsec I have a destination set to the specific server this branch needs to access (10.10.10.21/30)  When I created the second rule I realized I had to make a determination that this branch needs to only access their server at 10.10.10.28/30.  Since both offices have the same subnet, I can't set a rule up that says source = 192.168.1.0/24.

        What is the best way to handle this?  Do I need to setup an external IP for each branch at the HQ and IPsec tunnel to that?  Do I change a port…?

        Thanks.

        As far as I know, at least one of the SonicWALLs will have to 1:1 NAT their LAN and present it as something else so pfSense doesn't have two routes to the same subnet.

        That or renumber one of them.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • A
          awsiemieniec
          last edited by

          Thanks!

          So, to summarize - all IPsec tunnels have to have a unique subnet on the "distant"/client side when looking at the subnet from the pfSense/HQ/server side.  Is that right?

          As far as 2.1.5 - I had big problems upgrading from 2.1.5 to some 2.2 version a while back and had to restore back from an image taken before the upgrade.  I know - I need to update that sucker.

          1 Reply Last reply Reply Quote 0
          • D
            djamp42
            last edited by

            Yes, all remote sides need to have different subnets. In your case you would have 3

            VPN Core - Subnet #1
            Remote Site 1 - Subnet #2
            Remote Site 2 - Subnet #3

            There might be some ugly hacks to make it work, if it were me i would just re-subnet/ip the site.

            1 Reply Last reply Reply Quote 0
            • A
              awsiemieniec
              last edited by

              Thank you all for the assistance.  I did change the subnet on one of the branch offices and all went smooth after that.

              Thanks.  :)

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