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

    Source NAT IPSEC

    Scheduled Pinned Locked Moved NAT
    4 Posts 2 Posters 2.7k 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.
    • W
      wupperi
      last edited by

      Hi guys,

      need some help with NAT. Follwoing scenario:

      I have two pfsense FWs, A nd B. I have an IPSEC Tunnel between A and B. A has couple of static IP Adresses assigned to the external interface. Firewall B has a couple of webservers in its LAN, which I need to present through to the outside world using one of A's external IPs. Normally no issue. You just send all traffic down the tunnel and FW A becomes for everthing the default gateway.
      Now here comes the complexity: I do need local browing to remain intact on B, meaning, Firewall B will still need to have their outbound NAT rule to translate LAN B to external IP of FW B. So in fact FW B will need to act as dfgw for LAN B, however any reply packet  that comes returns a request from the internet to one of the webservers will need to go through the tunnel and exit through FW As outbound NAT.

      The only way I can see working is, if I do double NAT:

      external broswer source IP, Destination: FW A public IP:80 ->  Port Forward replacing destination IP to physical LAN B as destination & Source NAT (replacing source IP with an IP from a network "C"  -> Down the tunnel -> Packet routed to Server IP on LAN B

      Return packet:

      Webserver LAN B -> Down the tunnel to IP Adress from LAN "C" -> NAT Table restores original destination which is original external broswer IP -> Outbound with restored source IP from Port forward

      So in fact, I need to fully mask the source and destination adresses that FW A sees towards firewall B. Firewall B should only know about its LAN b and the NAT LAN C.

      No idea how to configure this though???

      1 Reply Last reply Reply Quote 0
      • I
        isolatedvirus
        last edited by

        if youre doing a site to site tunnel you dont have to nat each end behind their respective firewalls. This way to get to LAN A from LAN B it gets routed to FIREWALL B, through tunnel to FIREWALL A, then to LAN A.

        1 Reply Last reply Reply Quote 0
        • W
          wupperi
          last edited by

          I know I do not have to NAT to do a site to site tunnel. However I do want to masquarade the source IP adresses that come in from the internet through firewall A so firewall B does not see them but natt'ed adresses.

          So it is a combination of port forwarding to a destination address which is reachable through the tunnel and a source NATting before the packet travels into the tunnel.

          With IPSEC I could not get it running, however with OVPN for wahtever reason it worked.

          1 Reply Last reply Reply Quote 0
          • I
            isolatedvirus
            last edited by

            @wupperi:

            I know I do not have to NAT to do a site to site tunnel. However I do want to masquarade the source IP adresses that come in from the internet through firewall A so firewall B does not see them but natt'ed adresses.

            So it is a combination of port forwarding to a destination address which is reachable through the tunnel and a source NATting before the packet travels into the tunnel.

            With IPSEC I could not get it running, however with OVPN for wahtever reason it worked.

            you should just need a port forward, and a outbound nat rule.

            Internet source -> Firewall A -> Port forward to host B -> outbound NAT on IPSEC (Match source = !Local Lan Subnets) -> vpn tunnel -> Firewall B -> Route Source 'Firewall A (due to outbound nat) to Host B.

            youve already got it working though so it seems you're good to go :)

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