Pfsense missing return packets during NAT
-
You have no default gateway so there is no route in the firewall for traffic to 174.208.9.223.
-
Do you have a gateway defined on the REVNET_SERVER interface configuration?
-
Now that you mention it, I did just remove another line of internet around the same time this started happening. It was probably the default gateway.
Does it matter which of my Gateways I mark as default?
-
You mark the one you want to use as the default. It will be the route for traffic that is not policy routed.
Derelict Netgate 2 minutes ago
Do you have a gateway defined on the REVNET_SERVER interface configuration?
This question matters.
-
Yes, I do have a gateway defined on that interface (It is not the default though)
If I define a different gateway as the default gateway, will it mess with the routing of these packets on the return trip?
The way I understand it, the packets should take this path:
External IP >> REVNET_SERVER Interface >> SERVERS Interface >> SFTP Server >> SERVERS Interface >> REVNET_SERVER Interface >> External IPSo the packets should return out of the same gateway that they came in on, correct?
-
No. A gateway on the interface configuration itself, under Interfaces > REVNET_SERVER.
OK. It's DHCP. It should have a gateway there.
Yes, the traffic should go out the interface it came into. But it needs a route or FreeBSD will not accept the traffic so pf can do its reply-to thing. Which gateway is selected as the default should not matter with the exception of traffic generated on the firewall itself. That will use whatever is set as the default.
-
I just made the COMCAST_DATA interface the default gateway, and things have changed a little.
Now the WinSCP client I am using to test from an external IP is getting the "Network Error: Connection to 199.244.15.85 is refused" error. I have never gotten this before, so I assume this is a step in the right direction.
The Pfsense Packet Captures look the same as the screenshots I put in the original post, except for the Wireshark capture on the server which no longer has a "Host unreachable" error.
@Derelict When you say that "it needs a route" are you talking about static routes? Or shouldn't my firewall and NAT policy based routing be enough?
-
10.1.13.10 is refusing that connection.
-
Got it! I had typed the password incorrectly for the user to the SFTP server. Now the connection is working perfectly!
So to sum up, sounds like the issue was that I did not have a default gateway selected. Once I selected a gateway to be the default gateway (and typed in the password correctly for the SFTP Server) then everything functioned.
Can anyone explain why a default gateway selection is required for NAT to work? (Just curious) I had thought that through my firewall rules and policy based routing that I could direct the packets just fine....
Thanks all for your help!
-
When the reply packet was received by the firewall it had no route in the routing table for the destination so it returned Destination Unreachable.