• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Nat & ssh problem

Scheduled Pinned Locked Moved NAT
40 Posts 5 Posters 20.5k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    spazio
    last edited by Mar 16, 2010, 8:26 PM

    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 192.168.0.10
    I followed http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F

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

    FIREWALL RULE
    TCP  *  *  192.168.0.10  22 (SSH)  *

    And since it didn't work when on to

    http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
    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 192.168.0.10 from another pc
    Externaly on the wan side I get
    server#ssh: connect to host ip.dydns.com  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 91.124.173.106:32511 72.0.201.191:20692 UDP
    pass Mar 16 16:02:05 NG0 74.33.67.91:39415 192.168.0.10:22 TCP:S
    block Mar 16 16:02:04 NG0 81.67.164.10:63621 72.0.201.191:63490 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
    spazio

    1 Reply Last reply Reply Quote 0
    • D
      danswartz
      last edited by Mar 16, 2010, 8:28 PM

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

      1 Reply Last reply Reply Quote 0
      • S
        spazio
        last edited by Mar 16, 2010, 9:11 PM

        Yes, the lan config is 192.168.0.1/24

        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
        192.168.0.0    *              255.255.255.0  U    0      0        0 eth0
        default        pfsense.box    0.0.0.0        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.

        1 Reply Last reply Reply Quote 0
        • D
          danswartz
          last edited by Mar 17, 2010, 1:05 AM

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

          1 Reply Last reply Reply Quote 0
          • S
            spazio
            last edited by Mar 17, 2010, 12:44 PM

            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 192.168.0.1 / 24
            FTP Helper enable

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

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

            Rules:LAN
            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.

            1 Reply Last reply Reply Quote 0
            • D
              danswartz
              last edited by Mar 17, 2010, 1:07 PM

              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?

              1 Reply Last reply Reply Quote 0
              • S
                spazio
                last edited by Mar 17, 2010, 1:26 PM

                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) 72.55.39.133.38982 > 74.10.205.142.22: 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>

                1 Reply Last reply Reply Quote 0
                • D
                  danswartz
                  last edited by Mar 17, 2010, 2:26 PM

                  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.

                  1 Reply Last reply Reply Quote 0
                  • S
                    spazio
                    last edited by Mar 17, 2010, 2:36 PM

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

                    1 Reply Last reply Reply Quote 0
                    • D
                      danswartz
                      last edited by Mar 17, 2010, 2:37 PM

                      it shouldn't have blocked it then :(

                      1 Reply Last reply Reply Quote 0
                      • T
                        thafener
                        last edited by Mar 23, 2010, 7:04 AM

                        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

                        1 Reply Last reply Reply Quote 0
                        • S
                          spazio
                          last edited by Mar 23, 2010, 2:48 PM

                          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?

                          1 Reply Last reply Reply Quote 0
                          • D
                            danswartz
                            last edited by Mar 23, 2010, 2:55 PM

                            can you post your /tmp/rules.debug?

                            1 Reply Last reply Reply Quote 0
                            • T
                              thafener
                              last edited by Mar 23, 2010, 3:23 PM

                              hi danswartz

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

                              Thx thafener

                              rules.txt

                              1 Reply Last reply Reply Quote 0
                              • D
                                danswartz
                                last edited by Mar 23, 2010, 3:45 PM

                                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 192.168.0.10, but the rules are referencing 192.168.1.2 - 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?

                                1 Reply Last reply Reply Quote 0
                                • T
                                  thafener
                                  last edited by Mar 23, 2010, 3:49 PM

                                  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 192.168.1.2 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

                                  1 Reply Last reply Reply Quote 0
                                  • D
                                    danswartz
                                    last edited by Mar 23, 2010, 3:58 PM

                                    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?

                                    1 Reply Last reply Reply Quote 0
                                    • T
                                      thafener
                                      last edited by Mar 23, 2010, 4:56 PM

                                      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

                                      1 Reply Last reply Reply Quote 0
                                      • T
                                        thafener
                                        last edited by Mar 24, 2010, 7:15 AM

                                        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 217.71.243.136.1651 > 83.79.5.14.22: tcp 0
                                        08:09:11.726431 IP 217.71.243.136.1651 > 83.79.5.14.22: tcp 0
                                        08:09:17.742044 IP 217.71.243.136.1651 > 83.79.5.14.22: tcp 0
                                        

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

                                        fwlog1.jpg
                                        fwlog1.jpg_thumb
                                        fwrule1.jpg
                                        fwrule1.jpg_thumb

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          danswartz
                                          last edited by Mar 24, 2010, 1:02 PM

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

                                          1 Reply Last reply Reply Quote 0
                                          20 out of 40
                                          • First post
                                            20/40
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                            This community forum collects and processes your personal information.
                                            consent.not_received