2.4.4 Broke NAT Rules
-
We have NAT Rules for a webserver/Exchange setup and after upgrading to 2.4.4 among the hundreds of things that broke one of them was our NAT rules, it says its passing the traffic but nothings actually making it inside.
Anyone else having this issue?
-
As always, go through the steps and see where it fails, then post exact details if you really want help: https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html
-
It doesnt appear to be failing is the issue, its making it inside the network however it doesnt seem to be getting a response out.
I am running wireshark on both servers in question and they are seeing the traffic from an external port scanner when I probe the port however its reporting closed which is seemingly correct as im unable to reach them from my phone either.
-
So I have a NAT Rule setup like so
WAN TCP/UDP * * WAN 80(HTTP) 10.202.12.4 80(HTTP)I have verified the Traffic is passing to the internal interface checked the internal host doesnt have a firewall on itself blocking the traffic and have wiresharked the traffic on the internal host and verified the traffic is making it through PFSense and into the internal host yet the connection times out over Numerous LTE connections on various different providers and using an online port checking tool the ports being reported blocked.
I verified that NAT Reflection IS enabled (Pure NAT) and its still not working. and No the port isnt being blocked at our ISP's side cause we're on a dedicated business fiber connection and I have double checked with them just to make sure there's nothing wrong on their end.
It might be worth mentiioning also that we have a Hybrid Outbound NAT setup however none of the rules on there have anything to do really with our LAN/WAN and ive tried switching it to automatic outbound NAT and that did not resolve anything.
-
@trees-spanning-the-land said in 2.4.4 Broke NAT Rules:
So I have a NAT Rule setup like so
WAN TCP/UDP * * WAN 80(HTTP) 10.202.12.4 80(HTTP)I have verified the Traffic is passing to the internal interface checked the internal host doesnt have a firewall on itself blocking the traffic and have wiresharked the traffic on the internal host and verified the traffic is making it through PFSense and into the internal host yet the connection times out over Numerous LTE connections on various different providers and using an online port checking tool the ports being reported blocked.
What is being sent by 10.202.12.4 in response to the connection attempts it is receiving?
I verified that NAT Reflection IS enabled (Pure NAT) and its still not working. and No the port isnt being blocked at our ISP's side cause we're on a dedicated business fiber connection and I have double checked with them just to make sure there's nothing wrong on their end.
If you are testing from the outside, NAT Reflection should not be coming into play.
It might be worth mentiioning also that we have a Hybrid Outbound NAT setup however none of the rules on there have anything to do really with our LAN/WAN and ive tried switching it to automatic outbound NAT and that did not resolve anything.
Outbound NAT should have nothing to do with connection attempts from the outside, either.
As an aside, why do you have UDP forwarded for a TCP-only protocol like HTTP?
-
@derelict said in 2.4.4 Broke NAT Rules:
What is being sent by 10.202.12.4 in response to the connection attempts it is receiving?
Just a normal HTTP Get
as for the TCP/UDP thing must have selected that by accident, either way changing it to TCP only makes no difference
-
No. When you test the connection you will see a SYN go to the server. It will have to respond. I am talking about the three-way handshake at the beginning of every TCP connection. What is the server sending in response to the SYN from the outside host that is being forwarded to it?
-
So thats interesting it looks like PFSense is replying to the server with "Host Unreachable" when I try to do a WGET from the external host but it most certainly is reachable.
Im seeing the same behavior when i try to reach the server from my phone over LTE.
-
That is completely opposite of what you have been saying.
I would post packet captures of a connection attempt. One capture taken on the WAN interface with the port forward and one taken on the LAN interface with the server.
Easiest thing to filter on is probably the outside address of the device making the test connections inbound.
-
Check that pfSense has a default route in Diag > Routes. If not set a default gateway in System > Routing.
For external requests to the server though I would expect repy-to to allow replies even in the absence of a default route.
Steve
-
You sir are my new best freind THANKS SOOOOOOOOO MUCH! :D
It was trying to route everything out a Management VLAN at our Provider :)
Looks like it also fixed some of our VPN issues and other things. Hope this thread helps someone who may also be in the same situation.
