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

    Full NAT scenario

    Scheduled Pinned Locked Moved NAT
    3 Posts 2 Posters 1.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.
    • J Offline
      janosh
      last edited by

      Hi,
      We have a IPSec VPN tunnel from Asia to Europe. The endpoint of the tunnel is our firewall 192.168.1.4 (which is a secondary IP). Earlier we had a webserver here but now it is hosted externally, so we have redirected the internal traffic to the external hoster using following Full-NAT rule:

      Full NAT [Translate internal requests from Asia to External Hoster]
      Traffic selector: 192.168.10.* (Asian user) → HTTP → 192.168.1.4 (Virtual 2nd IP)
      Source translation: 46.47.48.49 (external IP) HTTP
      Destination translation: 46.47.50.51 (Hoster) HTTP

      Opposite direction is also possible, so the external hosted application is able to call an internal Web server using following Full-NAT rule:

      Full NAT [Translate requests from External Hoster to internal WebSvr]
      Traffic selector: 46.47.50.51 (Hoster) → 8089 → 46.47.48.49 (external IP)
      Source translation: 192.168.1.1 (Firewall primary IP) HTTP
      Destination translation: 192.168.10.13 (Web Server) HTTP

      Has pfSense the capabilities to setup this kind of rules?

      Tks and brgds, janosh

      1 Reply Last reply Reply Quote 0
      • M Offline
        mikee
        last edited by

        Unless you are after something more convoluted or have any special reason to push the traffic from Asia through the tunnel, why not to access the server (that is now in a public IP addressing space) directly from the user workstation?

        I mean, your web server is now a standard public webserver as they are the ones of google to say. And that is what you are trying to do with your nat translations. Instead of connecting to 192.168.10.4 they may connect to the public address of the server.

        Anyway if there are any special considerations so that you need to pass the traffic for that server through the tunnel you can have a look at this document that depicts a similar scenario that you are showing.

        http://lutung.lib.ums.ac.id/freebsd/pfSense/docs/special_nat_configuration_with_pfsense.php.html

        Hope this help.

        Regards.

        1 Reply Last reply Reply Quote 0
        • J Offline
          janosh
          last edited by

          Tks for your reply so far.
          The connection speed and stability through public internet is quite bad from Asia to Europe, while it is far better using the internal way through our MPLS (leased line).

          Your answer convers the part with the virtual address, which seems to be fine with pfSense.
          In the linked tutorial under "NAT IP" the description says one can only enter an INTERNAL ip as the destination IP, but in our case the destination IP should be the EXTERNAL ip of our hoster. Do I understand it right that way?

          regards,
          janosh

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