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

    External pfSense access, with NAT and CARP?

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 2 Posters 687 Views 2 Watching
    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.
    • MrPeteM Offline
      MrPete
      last edited by

      I'm now on the road for three weeks... and discovering I have no access to my wonderful new HA pfSense. :( -- not direct SSH, not GUI webconfigurator.

      I can SSH to boxes on our LAN, and SSH from there to pfSense.

      But so far I have failed to find a way to talk directly to pfSense. tcpdump sees incoming packets, and that's it.

      I have tried some tweaks to /tmp/rules.debug, so far with zero success.

      My guess: this has something to do with NAT and CARP adjustments, but I don't really know what.

      ANY hints would be most welcome! If I could get direct SSH to work, I know how to use port tunneling in SSH... that would be a very good long term solution with better security than just opening to the world... but even SSH isn't working.

      THANKS,
      Pete


      I've got an alternate HTTPS port XYZZY on webconfigurator.

      I can see rules that:

      • Redirect incoming on WAN interface to primary LAN (...1.1)

      • Do internal NAT reflection from internal interfaces to the same

      • Two sets in a row of:

        • no nat on VLAN1 to 1.1 port XYZZY
        • nat on VLAN1 from 1.0/24 to 1.1 port XYZZY to 1.2 port 1024:65535 (CARP redirect?)
      • sshguard incoming block "GUI Lockout" (I tried disabling this line with no impact)

      • pass in quick on $WAN reply-to (WAN <gateway IP>) inet proto from any to 1.1 port XYZZY tracker nnnn flags S/SA keep state label "USER_RULE: NAT mypfSenseHost"

      S 1 Reply Last reply Reply Quote 0
      • S Offline
        SteveITS Rebel Alliance @MrPete
        last edited by

        @mrpete It shouldn't be too out of the ordinary. Post your NAT/fw rules?

        We have it via CARP to our data center routers, and just address each separately (allow from our office to an alias with both router IPs).

        We have it at a client who has a web server on 443 so we have for example publicip:50443 NATting to lanip:443.

        Just have to make sure you're connecting to the router you think you are, and it didn't fail over. I try to avoid the CARP IP.

        Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
        Upvote 👍 helpful posts!

        MrPeteM 2 Replies Last reply Reply Quote 0
        • MrPeteM Offline
          MrPete @SteveITS
          last edited by

          @steveits
          Thanks!

          I've made some progress at least:

          I worked out how to more directly access pfSense on LAN via an SSH tunnel through one of our internal servers. Thus a single SSH gets me to pfSense and a few other resources as well:

          In PuTTY, set up a tunnel in the SSH to the internal server...

          • From: port XYZZY
          • To: 192.168.1.1:XYZZY (ie pfSense LAN IP, port XYZZY)

          With this, going to https://localhost:XYZZY gets me to pfSense.

          I can do the same to one of my proxmox hosts (which host pfSense... I'm now VERY much appreciating that! I have remote console access to each HA pfSense! And accessing one proxmox gives me access to all. Proxmox is enterprise level VM cluster hosting. Accessing any copy gives 100% access to all. :) )

          Now to work on the firewall...

          1 Reply Last reply Reply Quote 0
          • MrPeteM Offline
            MrPete @SteveITS
            last edited by

            @steveits
            And.... SOLVED it.

            1. Without the GUI, it's almost impossible to see real issues.

            2. WITH the GUI, the problem quickly became visible:

            • Long ago, I created a final FW Rule on WAN allowing me to control logging of dropped packets.
            • New Port Forward configs create FW pass rules on WAN... and places them at the end. Which means the above block rule means none of the port forward pass rules do anything ;)

            Disabled my block, and all is well!

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