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

    New pfSense 2.3.2-Release (32bit) NAT Question

    Scheduled Pinned Locked Moved NAT
    3 Posts 2 Posters 2.8k 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.
    • H
      HaOsLsE
      last edited by

      Lost my previous post >< So I'll try to make this short.

      Having issues with NAT on a 386 (32 bit machine).  We have built several (at least 50) in the past since before 1.2.3.  We still had a 1.2.3 installer, so we just used that and upgraded to the latest right away.  However it seems we have problems accessing anything behind the firewall.  It gets a public IP and assigns it to the WAN just fine and internet and everything seems to work.  However we cannot access anything remotely, including web gui and SSH.

      We noticed when using canyouseeme that any ports we try to add into NAT does not seem to work.  On other known working boxes, we emulated the settings for NAT/Firewall/Networking etc…and everything looks the same as far as the configs.  This new box is the only one having issues when trying to NAT and check the ports to see if they're open.  On any other box we can add the NAT/Rule and it work right away.

      Our questions are:
      1. Anyone experiencing NAT issues with 2.3.2-Release (32bit)?
      2. Anyone face issues with COX cable blocking/filtering ports? (we have used several different ISPs and this is the first of this issue)

      We also tried OpenVPN and it seems to try to connect but times out.  Of course VPN on our other boxes are configured the same way and work fine.  So we're not sure if it's the latest build on the 32 bit box, or something with COX cable.

      (removed IP)

      Sun Aug 07 20:55:25 2016 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
      Sun Aug 07 20:55:25 2016 Windows version 6.1 (Windows 7) 64bit
      Sun Aug 07 20:55:25 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
      Sun Aug 07 20:55:30 2016 Control Channel Authentication: using 'pfsensefw-udp-34447-tls.key' as a OpenVPN static key file
      Sun Aug 07 20:55:30 2016 UDPv4 link local (bound): [undef]
      Sun Aug 07 20:55:30 2016 UDPv4 link remote: [AF_INET]xx.xxx.xx.xxx:34447
      Sun Aug 07 20:56:30 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
      Sun Aug 07 20:56:30 2016 TLS Error: TLS handshake failed
      Sun Aug 07 20:56:30 2016 SIGUSR1[soft,tls-error] received, process restarting

      Any help, advice, directions, or comments are appreciated.

      ~HaO

      I am Hole.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        If you suspect port filtering by the ISP packet capture on WAN and see if the traffic is arriving.

        You really should be running 64-bit if the hardware supports it, though there is nothing remotely close to problems like "NAT doesn't work on 32-bit." It's generally fairly rare kernel panics that happen on 32-bit and don't on 64-bit.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • H
          HaOsLsE
          last edited by

          Ok good to hear about nothing close to having NAT issues.  I'll try capturing on the WAN interface and see what happens.  I sure wanted to put it on a 64 bit system but…the current hardware is so old lol...that's all it supported.  We haven't had any issues with it but have several of those machines left.  It's just hard at the moment with only being able to see what is going on via a remote webex session and the other end not being technical enough to assist.  I will try and see if I can get a capture of the WAN side tomorrow when we start another webex.

          I am Hole.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.