Pfsense missing return packets during NAT

[PetersonG17]

Another bit of info that I just thought of. Since making these NAT and firewall changes, I have not reset the state table or rebooted the Pfsense box. Would either of those be required to make sure that the new NAT and associated Firewall Rules are functioning correctly?

Also, when checking the firewall rules, I can't see any current states with the ones in question.

Is there a way to reset the states only for specific rules?

[Derelict]

Your NAT port forward needs to be on WAN, not REVNET_SERVER.

If the screen shots above are not what you currently have, please post new ones for WAN, LAN, and the the port forward.

Whatever is responding as 10.1.13.1 is saying it has no route for 174.208.9.223.

Are you sure you don't have something else on the network on 10.1.13.1?

You probably want to post the output of this executed in Diagnostics > Command Prompt:

netstat -rnfinet

[PetersonG17]

Thanks for the reply. The screenshots in the original post are current.

REVNET_SERVER is a WAN Interface, as are:

COMCAST_VOICE
COMCAST_DATA
CENTURYLINK_FAILOVER

My LAN Interfaces are:

DATA
MGMT
SERVERS
PHONES
FINANCE
GUESTWIFI

If I look in the Interfaces >> Assignments, there is no WAN option.

Interfaces:

To my knowledge I have nothing else on the 10.1.13.1 network but that one server at 10.1.13.10.

Here is the output of the command you listed:

Under the NAT rule there is no option for "WAN". But as I said previously the REVNET_SERVER is a WAN interface. It uses DHCP to receive its Reserved IP from my ISP.

I apologize if I am still misunderstanding. Thank you so much for helping me figure out this issue.

I have never used the command you listed "netstat -rnfinet" and am not familiar with the output. Is it revealing?

[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.