NAT problem on OPT-WAN
-
And to which interface are these servers connected? Are you doing bridging?
Servers are connected to the opt-wan interface, that is also their default gateway. I'm not doing bridging, but the opt-wan is part of the load balancer. could it be a probelm? I cannot actually get screenshot of the configuration (only ssh access from here), is there anything I should look for?
-
Besides the outgoing WAN, I've tried to disable it and connected to an external server both via ssh and web, the result is that the server connects from its address, that is the pfsense box is not doing any nat. This could be good since the network connected to the OPT WAN is not a pure LAN, but a LAN. However, since each server is using the pfsense as router, the pfsense box should do the NAT-ting of incoming packets on any interface.
To make it clearer, this is my situation:
LAN –- pfsense ---- WAN (from LAN to WAN nat is ok!)
|
+------- server1, server2, server3
|
OPT WAN (here from server1,2,3 no nat, even if specified in outgoing)It seems the server is not using the nat rule specified in outgoing nat, but I cannot understand why. I've checked with traceroute from the servers and the logs into the pfsense machine and I can see the traffic going thru the interface, but it seems that the box is forwarding the traffic as it is before the nat rule passes. Could it be a problem of ordering of the pf rules?
-
I attach screenshots of the configuration of my optional wan, port forwarding and outbound nat. Anyone sees something wrong in the configuration?
I really don't understand what I'm missing here.
-
What is the default gateway for server1,2,3? I suspect it's xxx.xxx.xxx.142. For outbound NAT de servers need to be behind the pfsense firewall, not next to it in the same subnet.
-
No, each server has the pfsense machine as router, and I've double checked it also with traceroute.
-
Ok, but your network drawing from a few posts earlier shows otherwise. AFAIK even with pfSense as the default gateway, it won't do outbound NAT this way, but only an ICMP redirect to the default gateway (xxx.xxx.xxx.142). A tcpdump might reveal this behaviour.
-
Uhm…so there is no way to do outbound nat on an optional WAN? What is therefore outbound nat purpose?
If anyone has a suggestion on how to achieve what I want please advice, I'm quite stressed by this...
Thanks -
The purpose of outbound NAT is rewriting of source address (and port sometimes) in ip packets, usually used to hide private rfc1918 (10/8, 172.16/12 and 192.168/16) addresses from appearing in packets when they reach the real internet where they would be dropped.
In your case I think the problem is that pf (the packet filter in pfSense) can't do NAT for packets that would leave the firewall via the same interface they came in. -
If you want the outbound NAT function to work, the traffic needs to come in from a different interface. So you'll need a separate interface (and subnet) for the servers. That way you can also protect the servers with the firewall (which is currently not the case). But obviously you won't be able to use the public IP's from the same subnet then.
-
If you want the outbound NAT function to work, the traffic needs to come in from a different interface. So you'll need a separate interface (and subnet) for the servers. That way you can also protect the servers with the firewall (which is currently not the case). But obviously you won't be able to use the public IP's from the same subnet then.
This souds reasonable!
Now, since I'm curious, what could happen if I bridge an interface to the public one, so that I keep the server with the public IPs and routed thru a bridged interface? Could this improved/solve the NAT problem or nothing chanes? -
I thought about this, but I'm not sure wether it'll work. But since the firewall part also works with bridging, I see no reason why it wouldn't work. Apart from it being theoretically possible, why would you want to perform NAT on public IP's?