Navigation

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

    SOLVED: Routing multiple IPsec tunnels

    IPsec
    2
    6
    5303
    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.
    • M
      Mattski last edited by

      Hi all,

      I've done some reading around the forums and tried to see if this had already been answered but couldn't find anything. So if it HAS been answered, my apologies. Anyway….

      I currently have the following network setup:

      10.1.x.x (AWS) <-- IPsec --> 172.16.x.x (pfSense) <-- IPsec --> 10.2.x.x (AWS)

      Each of the AWS instances can talk to the pfSense router with no issues. However, 10.1.x.x can't get to 10.2.x.x and vice-versa. What am I missing here? Phase 2 entries, or static routes, or both, or something else? Any advice would be massively appreciated as I'm by no means an expert on IPsec.

      (FWIW: my proposal was to have an IPsec tunnel directly between the two AWS VPCs, and I had that working, but it's been decided that this is too "complex".)

      1 Reply Last reply Reply Quote 0
      • J
        jonathanbaird last edited by

        @Mattski:

        Each of the AWS instances can talk to the pfSense router with no issues. However, 10.1.x.x can't get to 10.2.x.x and vice-versa. What am I missing here? Phase 2 entries, or static routes, or both, or something else? Any advice would be massively appreciated as I'm by no means an expert on IPsec.

        The two gateways at AWS don't currently have any routes to either remote network so they have no way of knowing how to get there. Easiest thing to do is add an additional phase 2 at both AWS sides and also on the pfSense. Just tested this on my side and it works a treat. Don't forget to permit the traffic through your pfSense  :)

        1 Reply Last reply Reply Quote 0
        • M
          Mattski last edited by

          Thanks for the advice! I'm no networking guru by any means though :(

          What I've done so far is add static routes to each VPC, pointing to the other VPC via the VPN connection. What should I be adding in the pfSense IPsec phase 2 sections? Ex: for one of them I have:

          Local subnet - 172.16.0.0/16
          Remote subnet - 10.1.0.0/16

          Should I add the following or similar to this particular tunnel:

          Local subnet - 10.2.0.0/16
          Remote subnet - 10.1.0.0/16

          ?

          1 Reply Last reply Reply Quote 0
          • J
            jonathanbaird last edited by

            Hi,

            Scrap your static routes, they're not needed! I'll try to explain best I can…

            AWS

            On your 10.1.x.x add a phase 2 entry for 10.2.x.x
            On your 10.2.x.x add a phase 2 entry for 10.1.x.x

            pfSense

            On your pfSense for your 10.1.x.x tunnel, add a phase 2 entry with a local network of 10.2.x.x and a remote network of 10.1.x.x
            On your pfSense for your 10.2.x.x tunnel, add a phase 2 entry with a local network of 10.1.x.x and a remote network of 10.2.x.x

            Renegotiate your tunnels at boh sides and you should see IPsec SA's come up. As long as your firewall(s) permit traffic you should now be able to route between both networks.

            1 Reply Last reply Reply Quote 0
            • M
              Mattski last edited by

              That's got it, thanks! :)

              Just to clarify for anyone else looking for this:

              • Add static routes to the other VPCs in the VPN connection static route table
              • Add phase 2 entries for the opposing VPCs in the pfSense IPsec settings, so for example as jonathanbaird amazingly pointed out:

              10.1.x.x tunnel, add a phase 2 entry with a local network of 10.2.x.x and a remote network of 10.1.x.x
              10.2.x.x tunnel, add a phase 2 entry with a local network of 10.1.x.x and a remote network of 10.2.x.x

              Apply them and that should do the trick. 10.1.x machines can now SSH to the 10.2.x net and vice-versa.

              jonathanbaird - thanks a ton for the help!

              1 Reply Last reply Reply Quote 0
              • J
                jonathanbaird last edited by

                No problem glad I could help. Just to confirm though you shouldn't actually need the static routes. Either AWS network should know how to get to the other side due to the phase 2 entries that you've created. The static routes can be removed in your instance.

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

                Products

                • Platform Overview
                • TNSR
                • pfSense Plus
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy