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

    How to nat ipsec subnets

    Scheduled Pinned Locked Moved IPsec
    4 Posts 3 Posters 3.9k 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.
    • C
      capitangiaco
      last edited by

      Hi all

      I have many remote networks connected to the master site network via ipsec tunnels.
      In the master site I have a pfsense on soekris firewall, and in the remote sites I have cisco routers (837).
      Using a proxy server in the master site, remote pc's can browse the internet.
      But now I must make connections between pc's in the remote site and public servers on the internet exiting from the internet connection of the master site.
      I had remote subnets in the nat rules of the firewall, but I am not able to make this thing work.

      Any suggestions ?

      Thanks

      Giacomo

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        This won't work unless you add a parallel tunnel for each public IP you have to reach via the master site. Otherwise the traffic won't be encapsulated into the tunnel as it doesn't match the tunnel definition. Routing over IPSEC doesn't work.

        1 Reply Last reply Reply Quote 0
        • V
          Voami
          last edited by

          @hoba:

          Otherwise the traffic won't be encapsulated into the tunnel as it doesn't match the tunnel definition.

          Hmm, are you totally sure about this? I don't have any positive contrary evidence, but I successfully run an IPSEC VPN like this:

          Local Net Remote Net
          172.16.0.0/22 172.16.2.0/24

          Even though the remote net is technically a subnet of the local net, I have had this work without issue. Note: it was not totally intentional, originally.

          The next step:
          –------------------
          If one expanded this into:

          Local Net Remote Net
          172.16.0.0/22 172.16.1.0/24
          172.16.0.0/22 172.16.2.0/24
          172.16.0.0/22 172.16.3.0/24

          Now you can send traffic bound from each remote net to another to the localnet.

          The 64000 dollar question

          Can you cause these packets to be routed back out to the correct remote net? Maybe with static routes, if neccessary?

          Weak answer: I have no idea, and no leisure of time and equipment to test it. But I thought I would muddy the water a little.

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by

            @Voami:

            @hoba:

            Otherwise the traffic won't be encapsulated into the tunnel as it doesn't match the tunnel definition.

            Hmm, are you totally sure about this? I don't have any positive contrary evidence, but I successfully run an IPSEC VPN like this:

            Local Net Remote Net
            172.16.0.0/22 172.16.2.0/24

            Even though the remote net is technically a subnet of the local net, I have had this work without issue. Note: it was not totally intentional, originally.

            The next step:
            –------------------
            If one expanded this into:

            Local Net Remote Net
            172.16.0.0/22 172.16.1.0/24
            172.16.0.0/22 172.16.2.0/24
            172.16.0.0/22 172.16.3.0/24

            Now you can send traffic bound from each remote net to another to the localnet.

            This will work. Nobody said it wouldn't. If you can sum up your networks this way it will work. I have a 10 location setup running this way with 8 of the locations coming from dynamic IPs. The thing you can't do is add a static route across the tunnel.

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