Pfsense missing return packets during NAT

[Derelict]

You have no default gateway so there is no route in the firewall for traffic to 174.208.9.223.

[Derelict]

Do you have a gateway defined on the REVNET_SERVER interface configuration?

[PetersonG17]

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?

[Derelict]

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.

[PetersonG17]

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 IP

So the packets should return out of the same gateway that they came in on, correct?

[Derelict]

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.

[PetersonG17]

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?

[Derelict]

10.1.13.10 is refusing that connection.

[PetersonG17]

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!

[Derelict]

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.