Why can’t I access forwarded ports on my WAN IP from my LAN/OPTx networks?

By default, pfSense does not allow LAN/OPTx connected PCs to reach forwarded ports on the WAN interface. This is a technical limitation of how the underlying PF functions, it cannot « reflect » in and out the same Interface; it only works when passing « through » the router. NAT Reflection employs some simple bouncing daemons to redirect the connections, which works but isn’t always desirable, or even functional for some scenarios. Usually, split DNS is the better way if it is possible on your network. Both are explained here.

Method 1: NAT Reflection

In order to access ports forwarded on your WAN interface from internal networks, you need to enable NAT reflection.

In order to do this, you must go to System > Advanced, and from there uncheck « Disable NAT Reflection ». Click save, and it should work. This will only work with single port forwards or ranges of less than 500 ports. If you’re using 1:1 NAT, you can’t use NAT Reflection.

Example of system with NAT Reflection enabled. (Disable choice is unchecked).

Method 2: Split DNS

The more elegant solution to this problem involves using Split DNS. Basically this means that internal and external clients resolve your hostnames differently.

Your internal clients would access your resources by hostname, not IP, and clients on your local network would resolve that hostname to your LAN IP, and not the WAN IP as others outside your network would see.

In order for this to work using the DNS forwarder in pfSense, your clients will need to have the IP Address of the pfSense router as their primary DNS server.

Example:

Some screenshots that show the above in practice:

Split DNS Example, adding DNS Override

Split DNS Example, what your screen should look like with http://www.example.com overridden as 192.168.1.5

 

Method 3: Experimental Routing Tricks

This should be considered experimental, and could possibly cause bad things to happen!

If you’re using 1:1 NAT, you can’t use NAT Reflection. If you’re a service provider (a web host, say), you may not have all relevant DNS entries under your control, so « Method 2: Split DNS » may be difficult to implement.

If you have a CIDR network block allocated to you which is all behind your pfSense firewall, you might be better off using public addresses on your internal network, or using a mix of public and private addresses.

If you have only a portion of your CIDR block behind pfSense, and you’re using 1:1 NAT, you may have a difficult situation. Here’s a possible approach you can consider. This may not work, or may work in only some situations. Be careful: don’t try this if you’re remote or don’t have console access to your devices.

1. Make the external IP address an alias on your loopback interface (the interface with localhost/127.0.0.1 on it). In FreeBSD, that’s something like this on the command line:

Used in <shellcmd> tags in pfSense, as described here.

2. Cause every other internal host to route traffic destined to your external IP to your internal IP. There may be 3 ways to do this:

a) Add a static route on every other host with something like route add -host 1.2.3.4 10.0.0.4 but you have to run that on every other host. This option can quickly become administratively difficult as the number of internal hosts goes up, but this can be mitigated if you have centralized administration (via something like cfagent, say).

b) Run a routing protocol – routed for example – on your internal network, and publish routes reflecting the external/internal 1:1 NAT mapping. This might be the most complicated choice, but might scale better than the other alternatives.

c) This seems to not work, presumably because pfSense already knows a route to the external network: Add static routes on the LAN interface of your pfSense firewall with a destination of the external address (1.2.3.4/32) and a gateway of the internal address (10.0.0.4/32). This alternative worries me a little bit, as I’m afraid it might confuse the firewall – I don’t think so, but please be careful.

Source: http://dablog.informafix.net/204

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s