Problem with NAT port forward



  • I want to port forward from WAN to LAN. Seems simple … but I've tried various configurations and I don't know if it's something screwy with my network or what! Here's the setup:

    A. pfsense (WAN: 75.x.x.x, LAN: 10.16.0.2)
    ... of particular note: static route defined as 10.0.0.0/8 to gateway 10.16.0.1
    B. test server on same subnet (LAN: 10.16.0.3)
    C. destination server (LAN: 10.5.0.1)

    Basic setup:

    1. Open the firewall on WAN and LAN. Do this to log all traffic and remove firewall as a source of problem.
    2. Create a NAT rule on WAN (any interface)

    Tests:

    1. Edit the NAT rule on WAN (any interface) to forward port 22 to pfsense LAN
    ... it works!

    2. Edit the NAT rule on WAN (any interface) to forward port 22 to test server (B) on same subnet
    ... it fails! tcpdump on (B) shows no traffic at all

    3. Edit the NAT rule on WAN (any interface) to forward port 22 to destination server (C)
    ... it fails! tcpdump on (C) shows no traffic at all

    I've looked in the forums here and read that NAT is resolved before we hit the firewall. In all three test cases above, I see the firewall log an attempt from my IP to the NAT destination. As in test case (2) and (3) above, however, I don't see the traffic to hit it.

    So I think this is a routing problem, but at the same time, from pfsense I can ping both my test server (B) and my desired destination server (C). Is there something I'm missing? Thanks!



  • What exactly do you mean with static route defined as 10.0.0.0/8 to gateway 10.16.0.1?

    An how did you test that?
    The test server 10.16.0.3 is where?
    And where is the destination server 10.5.0.1 ?

    Directly connected on the same subnet?
    Then traffic would never go over the pfSense.



  • @GruensFroeschli:

    What exactly do you mean with static route defined as 10.0.0.0/8 to gateway 10.16.0.1?

    An how did you test that?
    The test server 10.16.0.3 is where?
    And where is the destination server 10.5.0.1 ?

    Directly connected on the same subnet?
    Then traffic would never go over the pfSense.

    This is the setup as defined by my hosting provider. As they provision servers for us, we may be on what looks like multiple subnets but really, we are our own VLAN. All of these servers have access to each other. Example: I can ping (or SSH, web, etc.) all of these internal IPs from each other (10.16.0.2 to 10.16.0.3, 10.16.0.2 to 10.5.0.1, 10.16.0.3 to 10.5.0.1, etc.). The static route that's defined on pfsense is the same static route that's defined on server (B) and server (C). That's just how the hosting provider does it.

    To answer specifically your follow-up: it's not something we test. test server (B) 10.16.0.3 might be in one server room, where destination server (C) 10.5.0.1 might be physically in another server room. But they're all connected together in the same VLAN.

    The traffic I'm trying to port forward comes in on the pfsense WAN and I want it to come out the pfsense LAN to my destination server (C). Since I can ping and connect (SSH) from my pfsense LAN to my destination server (C), I'm baffled as to why NAT port forward can't do it.



  • Ah now i see.

    Could it be something small, as that you've set the wrong subnet on the config-page on pfSense? (a /24 instead of a /8 ?)

    Can you verify that you have access from the pfSense to the server with a ping?
    (there is a ping in the diagnostics menu)
    Can you ping 10.16.0.1, as this seems to be the route to the rest of the (physical?) network?

    Can you verify (maybe with a tcpdump) that pings to your servers really go to 10.16.0.1?



  • @GruensFroeschli:

    Ah now i see.

    Could it be something small, as that you've set the wrong subnet on the config-page on pfSense? (a /24 instead of a /8 ?)

    Can you verify that you have access from the pfSense to the server with a ping?
    (there is a ping in the diagnostics menu)
    Can you ping 10.16.0.1, as this seems to be the route to the rest of the (physical?) network?

    Can you verify (maybe with a tcpdump) that pings to your servers really go to 10.16.0.1?

    Thanks for the suggestion! Checking all the small things … from the interface page, I've verified I have the correct network settings for this to work. My particular LAN interface is configured as 10.16.0.2/26, with a static route defined for 10.0.0.0/8. This is configured correctly, according to my hosting provider.

    I can also ping and better yet, connect via SSH from pfsense both to test server (B) and to destination server (C). I can also ping 10.16.0.1, the gateway, as the route to the rest of the network. I don't think I need to tcpdump during these tests.

    When I do attempt to access via the NAT the same thing (SSH to pfsense WAN) and have tcpdump running on destination server (C), I do not see ANY packets arrive. The NAT port forward is configured as above, in this case, and the firewall log shows the incoming packet. Since NAT resolves before firewall, I assume NAT is working, but that doesn't explain what happens after it leaves the firewall!

    Is there other data I can capture that would help, or another point I should be checking for this traffic?



  • New information!

    I'm getting in via a different network interface, and am able to run tcpdump both on pfsense (A) and on the destination server (C). I see packets leave the LAN IP of pfsense (10.16.0.2) but I don't see anything arrive on the LAN of my destination server (C, 10.5.0.1)

    So does it seem the routing rules of how NAT works is the culprit? Is there something in the OSI model that conflicts with my hosting provider's particular setup?



  • Well to be honest i find it a bit strange that you have a subnet of 10.0.0.0/8 on your LAN, and at the same time traffic destined for 10.0.0.0/8 should be sent to a gateway.

    To me this seems a bit conflicting.

    I mean if something is in the same subnet than the interface itself this means you shouldnt have to send it to a gateway because it's directly reachable.


Log in to reply