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

    Multiple IPSEC VPNs

    Scheduled Pinned Locked Moved IPsec
    6 Posts 4 Posters 5.4k 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.
    • D Offline
      dagerb
      last edited by

      We have a pfSense firewall at our main office and Netgear firewalls at our five branch offices.  All the VPNs show as connected but traffic only travels across the first VPN.  In other words, we can ping site1 but sites 2-5 are not accessible.  The only rule on the IPSEC interace is to allow all traffic.  All firewalls have public IPs.  Does anyone have any experience with this?

      *We are currently using a Netgear firewall at the main office and all the branches are connected and traffic flows properly.  We would like to take advantage pfSense but cannot afford to upgrade all the firewalls.

      1 Reply Last reply Reply Quote 0
      • D Offline
        dagerb
        last edited by

        After much work, I have a stable working VPN setup between pfSense and Netgear firewalls.  The exception is Netgear FVS124G firewalls.  I could not get these units to handle multiple connects to pfSense firewalls but they will handle a single site to site VPN.  Below is the configuration I am using.  I hope this helps others.

        VPN: IPsec: Phase 1
        Disabled:  unchecked/enabled
        Internet Protocal:  IPv4
        Interface:  WAN
        Remote gateway:  <public ip="" address="">Description:  <whatever you="" want="">Athentication method:  Mutual PSK
        Negotiona mode:  main
        My identifier:  My IP address
        Peer identifier:  Peer IP address
        Pre-Shared Key:  ************
        Policy Generation:  Default
        Proposal Checking:  Strict
        Encryption algorithm:  AES 128
        Hash algorithm:  SHA1
        DH key group:  2 (1024 bit)
        NAT Traversal:  Disable
        Dead Peer Detection:  unchecked/disabled

        VPN: IPsec: Phase 2
        Disabled:  unchecked/enabled
        Mode:  Tunnel IPv4
        Local Network:  LAN subnet
        Remote Network:  <private network="" ip="" address="" of="" remote="">and <subnet mask="">Description:  <whatever you="" want="">Protocal:  ESP
        Encryption algorithm:  AES 128
        Hash algorithms:  SHA1
        PFS keygroup:  off
        Lifetime:  28800
        Automaticaly ping host: <private ip="" address="" of="" remote="" router=""></private></whatever></subnet></private></whatever></public>

        1 Reply Last reply Reply Quote 0
        • K Offline
          kejianshi
          last edited by

          Which version of pfsense?

          1 Reply Last reply Reply Quote 0
          • D Offline
            dagerb
            last edited by

            I have tested this with 2.0.2, 2.0.3, and 2.1.  Our corporate VPN/Firewall is running 2.1 which started as 2.0.1 and has been upgraded with each release.  We have branch office using 2.1 as a fresh install.  Both are very stable.

            1 Reply Last reply Reply Quote 0
            • M Offline
              mikee
              last edited by

              You don't need any rules in the IPSEC interface. All traffic inside the VPNs are allowed by default. That said, having or not the rule should make no difference.

              Given that, as you said, all VPNs are up and connected I will focus now on the routing part:

              1.- Is your pfSense firewall the default gateway of your network?
              2.- Are all the branch office's networks different from each other and from the one at the main office?
              3.- On every branch office, is the Netgear firewall the default gateway or does it exist a route back to the internal network of the main office?

              You may try swapping the configuration of the first VPN with the one of the second one and see if traffic now flow to that branch office instead of the former. This may indicate that actually a routing issue is the problem, not a IPSEC one.

              Remember that, though an IPSEC firewall rule is not neccesary for the VPN traffic to flow inside the VPN, it is still necessary to add LAN interface rules to allow traffic flow from the LAN subnet of the pfSense firewall to the branch offices internal networks. Check the firewall logs for rejects on traffic comming from or going to the branch offices, if any.

              EDIT: updated to fix an error regarding the direction of traffic to allow

              1 Reply Last reply Reply Quote 0
              • G Offline
                georgeman
                last edited by

                If I understood correctly, you want 2 sites (which are not connected directly between them), to use your main office as "hop" to get connected?

                If that's the case, it is a routing problem. BranchA doesn't know that it has to route traffic intented to BranchB through your main office. Since you cannot really add static routes that play with IPsec, the solution is to add another Phase2 at BranchA and BranchB (and the main office, of course) which connects the opposite site subnet.

                Example: let's say main office is 192.168.0.0/24, BranchA is 192.168.1.0/24 and Branch B is 192.168.2.0/24

                On BranchA you add a Phase2 that reads:
                Local Subnet: 192.168.1.0/24
                Remote Subnet: 192.168.2.0/24

                Same (but opposite) on BranchB and main office. You would need as many Phase2's as sites you want connected.

                After that it should work. Some time ago I had the same problem and solved it in this way.

                Whether you can add or not another Phase2 on the Netgear firewalls, that's a different story. You could also solve this by using NAT before IPsec (which should be available on 2.1, haven't tested it yet), but you won't have full transparent connectivity.

                Regards!

                If it ain't broke, you haven't tampered enough with it

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