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

    Multiple different networks on VPN IPSec ?

    Scheduled Pinned Locked Moved IPsec
    8 Posts 3 Posters 14.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.
    • X
      XZed
      last edited by

      –- Update ---

      I've found this : http://doc.pfsense.org/index.php/IPsec_with_Multiple_Subnets

      So i suppose i'm right about my setup ...


      Hello,

      Before beginning this post, i want to wish you all a happy new year  ;D !

      Yesterday i was faced to a setup like this one (ip adresses are examples) :

      --- Network1 10.100.1.0 -<>-<>-<>-<>- Network2 10.200.1.0 ---> pfSense ---> VPN IPSec

      To resume :

      The LAN has two subnets. One of them has pfSense that offers IPSec tunnels.

      So, IPSec are setup, for the network parts, like this example :

      Local Net : 10.200.1.0

      Remote Net : 10.300.1.0

      IPSec was working great but the remote net couldn't join Network1 (10.100.1.0).

      So i understood that IPSec tunnel needed to be setup with all subnets that need to be reachable.

      On remote gateways, i can fill the different needed networks....

      But in pfSense, i can only specify one local subnet...

      Obviously, to debug the situation i needed to specify 10.0.0.0/8...

      but you could understand that this setup is...dirty  ;D...

      Any help or link to tutorial would be very appreciated.

      Thank you very much,

      Sincerely,

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

        http://doc.pfsense.org/index.php/IPsec_with_Multiple_Subnets

        In 2.0 this will be much easier, you can specify multiple phase 2 subnets/hosts per tunnel.

        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!

        1 Reply Last reply Reply Quote 0
        • X
          XZed
          last edited by

          @jimp:

          http://doc.pfsense.org/index.php/IPsec_with_Multiple_Subnets

          In 2.0 this will be much easier, you can specify multiple phase 2 subnets/hosts per tunnel.

          Thank you very much for your answer  ;D !

          So i keep waiting for the v2.x  ;D

          1 Reply Last reply Reply Quote 0
          • P
            phaesler
            last edited by

            Excuse me if this is a stupid question, but the linked howto is a bit terse.

            The pfSense side of our (IPSEC) VPN has a 192.168.x.x address.

            The other side (a Fortigate box FWIW) has a 10.x.x.x (private side) address, and a route to a 172.16.x.x subnet (NB: no actual interface in the 172.16.x.x subnet).  The connection is initiated from the Fortigate side.

            We've successfully got connectivity between the 192.168.x.x subnet and the 10.x.x.x (private) interface on the Fortigate, but can't route from 192.168.x.x to 172.16.x.x.

            As I read the howto, I need to setup a second tunnel config on pfSense, identical to the first except:

            a) with a different identifier; and
            b) with 172.16.x.x as the subnet

            And presumably do something similar on the Fortigate side?  Does it matter for the second tunnel that the private ip address on the Fortigate side is not on the relevant subnet?

            I realise you guys can't help me too much with the Fortigate side of things, but I need to understand what the pfSense side is and isn't capable of.

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

              Usually you need something like this:

              A = 192.168.x.x

              B = 10.x.x.x

              C = 172.16.x.x

              A needs tunnels to B for B and C
              B needs tunnel to A for A, C for C
              C needs tunnels to B for A and B

              Otherwise C doesn't know how to get the traffic for A back to B, so it can make its way back to A.

              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!

              1 Reply Last reply Reply Quote 0
              • P
                phaesler
                last edited by

                C knows to route to A via the gateway on B.

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

                  So is there no IPsec involved between B and C then?

                  You'd still need phase 2 definitions for IPsec like so between A and B:

                  On A:
                  src A, dst B
                  src A, dst C

                  On B:
                  src B, dst A
                  src C, dst A

                  That may not have been clear how I phrased it before.

                  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!

                  1 Reply Last reply Reply Quote 0
                  • P
                    phaesler
                    last edited by

                    OK - got it working now!

                    In fact, we only need connectivity between networks A and C.

                    Setting up:

                    On A:
                    src A, dst C

                    On B:
                    src C, dst A

                    Seemed counterintuitive because the tunnel was terminating in B, which never gets referenced.  But it worked (after some unrelated but confounding firewall issues were resolved).

                    Thanks for your patience - I understand IPSEC a little better now.  :)

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