• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Apr 27, 2017, 7:23 PM

    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 Apr 29, 2017, 5:25 AM

      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 Apr 29, 2017, 5:59 AM

        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 Apr 29, 2017, 6:20 AM

          @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
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received