y 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 only use NAT Reflection with version 2.0 and newer.
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:
- www.example.com resolves to public IP 1.2.3.4, which is your WAN IP
- You forward port 80 on 1.2.3.4 to port 80 on 192.168.1.5
- You override www.example.com using System > DNS Forwarder and point www.example.com to 192.168.1.5
- You could also override this with some other internal DNS mechanism.
Some screenshots that show the above in practice:
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:
ifconfig lo0 inet 1.2.3.4 netmask 255.255.255.255 alias
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.
Nenhum comentário:
Postar um comentário