Nat & ssh problem

  • config:
    PFsense is the border router that the modem is hook to.
    1 if wan dynamic ip
    1 if lan 192.x.x.x
    1 hub/switch  no vlan on the lan if

    I need to ssh one server on the lan side
    I followed

    Firewall: NAT: Port Forward
    WAN  TCP  22 (SSH)  (ext.: any) 22 (SSH) port forward ssh

    TCP  *  *  22 (SSH)  *

    And since it didn't work when on to
    And tested every point there but still not working
    also check and make shure that "Disable NAT Reflection" box is not check

    On the lan side i can log in ssh from another pc
    Externaly on the wan side I get
    server#ssh: connect to host  port 22: Connection timed out

    Here is the log from pfsense firewall log showing that the packet is going tru:

    block Mar 16 16:02:06 NG0 UDP
    pass Mar 16 16:02:05 NG0 TCP:S
    block Mar 16 16:02:04 NG0 UDP

    After that i capture the packet with ethereal on the lan side. Nothing is showing on the lan side, that packet is nowhere to be found.

    So the nat seem to work up until the pfsense router and stops there, I must be doing something wrong, any thoughts?

    thanks in advance

  • Is the LAN subnet  If not, this is more complicated.  If it is, are you sure the ssh server has a default route pointing at the pfsense?

  • Yes, the lan config is

    And yes the ssh server has a default route, here is the config:
    root@server:~# route
    Kernel IP routing table
    Destination    Gateway        Genmask        Flags Metric Ref    Use Iface    *      U    0      0        0 eth0
    default        UG    100    0        0 eth0

    I also tested it with 2 other ssh server i have on the lan segment and got the same time out from the external.

  • Hmmm, can you post interface info, nat and rules?

  • The wan
    pppoe with isp and is always connected
    FTP Helper        disable
    Block private networks enable
    Block bogon networks  enable

    The lan
    IP configuration
    Bridge with none
    IP address / 24
    FTP Helper enable

    If          Proto  Ext. port range  NAT IP  Int. port range  Description
    WAN  TCP  22 (SSH)                            ssh server
                                                  (ext.: interface ip) 22 (SSH)

    Proto  Source      Port  Destination  Port  Gateway  Schedule  Description
    *  RFC 1918 networks  *      *                  *      *      *  Block private
    *  Reserved            *      *            *        *      *  Block bogon
    TCP            *            *  22 (SSH)  *    *    ssh server

    Proto  Source  Port  Destination  Port  Gateway  Schedule  Description
    *      LAN net  *      *          *      *                  Default LAN -> any

    Everything is pretty much iso. There is nothing special about the network.

  • Odd, looks okay, as far as I can see.  Curious, if you change the port number (on the outside) to some non-standard port (a good idea anyway) like 2222, does it work?

  • This is weird, just tested with port 2500 and here is the raw firewall log entry:

    Mar 17 09:22:52 pf: 586569 rule 71/0(match): block in on ng0: (tos 0x0, ttl 59, id 2421, offset 0, flags [DF], proto TCP (6), length 60) > S, cksum 0x5057 (correct), 1651357223:1651357223(0) win 5840 <mss 2="" 3328663370="" 1366,sackok,timestamp="" 0,nop,wscale="">The default deny rule apply and the packet is rejected here it is:
    @71 block drop in log quick all label "Default deny rule"</mss>

  • did you change the rule too, or just the nat entry?  note that the rule applies to the post-nat, so that would stay port 22.

  • First i deleted the nat and rule on port 22 and then created a new nat on port 2500 that created automaticly the rule.

  • it shouldn't have blocked it then :(

  • Spazio,

    Did you find a solution for this meanwhile as I have the same problem with NAT over here.
    I have solved it once in a absolutely strange way. I have delted all FW and NAT rules, made
    a backup of the box and made a fresh install. Then I have created the rules manually again.
    Then I have made the rules created by NAT the first ones and it worked for some 10 days
    but it has stopped working again. :-[

    cheers thafener

  • Nop, still have the same problem and it gets worst. I took another machine, did a completly new install from dist cd and the same problem occurs. The default deny rule block everything. I can't even get the packet to go tru once in a while like my other network.

    Here is my understanding of the problem, the packet are discarded  on a first come first served. It like if the default deny rule is the first, the packet is discarted so the other added rule do not apply.

    This is weird, nat is usually pretty much strait forward, is there somebody that does technical incident call service?

  • can you post your /tmp/rules.debug?

  • hi danswartz

    here's mine as a example… renamed it to rules.txt

    Thx thafener


  • In a couple of places, you have rules saying {tcp udp} for a tcp service - get rid of the udp it just confuses things.  Also, your post refers to, but the rules are referencing - is this an error, or did you change the IPs and not post that?  Anyway, this all looks correct - the only thing I can see as a possible issue (that might explain the inbound SSH request not getting through and not being blocked by PF) is snort.  I have stopped using snort myself, due to false positives that resulted in good hosts being blacklisted.  Could that be it?

  • Hi danswartz

    Sorry I did not mean to confuse you, it was not the logfile of the threat starter but I have
    exactly the same problem, I cannot access in the LAN segment and found no lasting
    solution so far.
    Well I am not using snort but I will check the rest

    Thx thafener

  • Oh, sigh.  This is confusing.  I hadn't noticed I was dealing with two different posters :(  So, thafener, when you try to connect to ssh from outside, is it blocked by the default rule or it just goes nowhere?

  • Sorry for all that mess danswartz I do not think that the ssh packages are blocked by the default rule as I can see
    them pass in the firewall log but I cannot connect to the ssh host which is possible of course from the LAN side.
    It is really confusing that I already "solved" this by making the SSH NAT rule the first one and it has been working
    fine for a while but unfortunately the problem occured again.
    I have a second PFsense system running in a different location and here it is the same with natting FTP.
    I cannot access both boxes from here but I'' get back to this with a little more detailed log output tomorrow morning.

    cheers thafener

  • Ok here's some output and some screenshots of this phenomenon…first of
    all a packet capture of the WAN interface on Port 22...

    08:09:08.760774 IP > tcp 0
    08:09:11.726431 IP > tcp 0
    08:09:17.742044 IP > tcp 0

    Please find the screenshots of the NAT rule and the Log viewer attached

  • Are you absolutely 100% positive there is no trace of the connection on LAN side?  Can you run a capture there too?

  • I have made a captore in full detail but could not find packets on port 22 for host  :-\

  • Can you capture anything at all on the LAN side involving or port 22 (e.g. two captures.)

  • I have scanned but only the capture for produced output, sadly not for Port 22.
    There is no traffic on port 22 coming through the box though it should according to the setup…


  • If you try a connect (which hangs I assume, waiting for the SYN to be replied to), what shows up in the pfsense state table?

  • Yes there is something showing up in the state table, I was have used the host I am connecting from as a filter… see screenshot

  • Hmmm, this is odd.  Is it possible to do a capture on the ssh server itself?  I am not sure I trust the capture on the pfsense.

  • Well I used wireshark on the target host running Ubuntu and there were no SSH packages from the Pfsense box to the target host.

  • okay, thanks.  boy, is that weird.  question: i assume this doesn't work at all?  if correct, does a reboot of the pfsense bring it back?  also, do you have sshd enabled on the pfsense?  if so, does disabling it "fix" this (i am not recommending that as a fix, just trying to isolate things.)

  • Yes man that's weird. Two weeks ago I had exactly the same problem and after doing everything from the book
    and the troubleshooting guide I deleted all Firewall and NAT rules, made a backup without package info and reinstalled
    the box from the scratch.
    Then I reinstalled the packages (squid and lightsquid and the dashboard) and created the NAT rule for SSH first and
    all others after and it has been working for a little more that a week.
    I just noticed the high number of very similar NAT problems discussed in this Forum….really strange

  • Hi @ll

    Here we go again, re-installed the whole box from the scratch, re-created the Nat rule as the only
    existing one and I have exactly the same problems with the same outputs as before.
    Tried NATting VNC (5900) too but no joy…. would any one of you guys give 2.0 a chance or
    is there any other possible solution for this ?

    Thx thafener

  • No clue anyone ? Might this problem be hardware-related ? I am running PF on a
    Intel Atom 330 (D945GCLF2) using the onboard NIC (Realtek 8xxxx, might use much
    memory but Ok…) and a 3Com 3C905C as the second NIC. Next to this the system
    has 2 GByte RAM and a 160 GByte HDD.....

    Found nothing problematic about this hardware combination in the compatibility lists
    but maybe any one of you knows more....

  • Follow up:

    It seem that the whole problem happend if captive portal is enable, basically the nat just doesnt work. It looks like the captive portal doesn't undestand or just block the nat.

    If anybody found a solution or has details for nat with captive portal enable, please share?
    Next step, will try with a dmz.

  • Spazio,

    Thanks a lot for your reply… the cp is a hint, I did not consider having a look at this
    side so far.
    Does it mean you disabled the cp and it was working again ? Can you confirm this ?

    However if you make a new install from the scratch it works again as it is the same
    with a lot of PFSense issues from my side.
    Some functions stop working without reason or without prior configuration changes
    and it is impossible to find a logical reason.
    However it is good for us that the functions of PFSense allow a fast install and restore
    which can be done in some 20 minutes...

    Thx thafener

  • yep, by disabling captive portal everything comes back to normal and nat is working again. Tried it with a new install without cp and it work.

    For me the problem came from enabling captive portal.

    This is a deal breaker still. There must be a way to have nat and cp enable and working at the same time

  • Is the system with the SSH server logged into the captive portal or configured in the pass-through MAC or allowed IPs of the captive portal?  If not, it needs at least one of those.  There is currently no way to selectively let certain traffic through the captive portal block on certain ports.

  • The ssh server is allowed in the pass tru mac. I also tried with a port 80 web server and it's the same. I can see the firewall let the packet tru in the log but it stop there.

  • Good morning

    Exactly the same over here. The SSH server has a entry in the pass-through-list and well it
    worked fine for a while until it stoppe working suddenly without prior changes in the
    Like Spazio I can see the packets on Port 22 passing the firewall, but it seems they don't.

    cheers thafener

  • Hi @ll

    Done the following today :

    Deleted all FW Rules from the problematic box and made a backup without package info.

    Used the backup to set up a box with nearly the same hardware config (Atom 330 and
    so on) and just with a Linksys NIC instead of a 3Com.

    Re-created the NAT for SSH and it does not work no matter if the CP is enabled or not…

    cheers Thafener

  • Hi all,

    I have the exact same problem with my psSense. Just thought I'd drop in and say that disabling CP solved the problem with NAT for me as well. Thanks Spazio for that hint.
    And I agree that there must be a way to have both NAT and CP working at the same time. But in the end, right now I'd rather have NAT than CP…

    My symptoms are the same. NAT seems to be working and the firewall log says that the traffic is let through. Using tcpdump on the WAN interface I can see the packages. Using tcpdump on the LAN interface, nada. Using Wireshark on the SSH-server host, no packages there either. But, disabling CP all is fine.

  • Hi @ll

    I was able to reproduce this too meanwhile. I agree that both features should be working
    at the same time as the CP is a really brilliant feature
    Does anybody know if the developers are working on this ?

    cheers thafener

Log in to reply