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

    Connections from outside palo alto works from inside fail

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 2 Posters 456 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.
    • D Offline
      dlb
      last edited by

      Hi all, we are a community college that have a group of vm's that need to be accessible from outside the college firewall.

      The College uses a Palo Alto system and have give my program a /27 group of addresses in a DMZ that is accessible from the outside and from on campus. I have a Linux box with SSH enabled sitting behind pfsense using 172.16.8.2/16. In pfsense I setup a NAT rule to redirect 64.x.y.z/27 (one of the DMZ addresses) to 172.16.8.2/16 (the protected Linux box) on port 22.

      From off campus at my home, I can open putty on 64.x.y.z and get a logon and connect with no problem to the school Linux box. When I am at my desktop at school and try to connect to 64.x.y.z/27 putty times out. When I look in the Status/System  Log/Firewall/Normal View and I see this at the time of the failed attempt.

      x Jun 15 7:15:55 WAN 172.17.28.104:60089 172.16.8.2:22 TCPS

      172.17.28.104 is the address of my work desktop. I don't get it.

      To add to the confusion, if I move this Linux VM behind a Smoothwall system with the same External 64.x.y.z address forwarded to the Linux box, it works from both inside and outside the school network. Why does it work with Smoothwall but internal breaks with pfsense? Any ideas?

      Thanks
      Don

      1 Reply Last reply Reply Quote 0
      • johnpozJ Offline
        johnpoz LAYER 8 Global Moderator
        last edited by

        Well you need nat reflection to work..  did you setup your forward with nat reflection.  Do you have the default rule on your wan to block rfc1918.. Since in your scenario your coming from rfc1918 so yeah that rule would block your traffic.

        Why are you not just going directly to 172.16.8.2 when your sitting on the same network… Why would you hit the public 64 address?

        Do you not have dns setup, and just setup split dns so when your outside your resolve something.something.tld to your 64 address, and when your inside your network you resolve something.something.tld to your 172 address.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 25.07.1 | Lab VMs 2.8, 25.07.1

        1 Reply Last reply Reply Quote 0
        • D Offline
          dlb
          last edited by

          "Why are you not just going directly to 172.16.8.2 when your sitting on the same network… Why would you hit the public 64 address?

          Do you not have dns setup, and just setup split dns so when your outside your resolve something.something.tld to your 64 address, and when your inside your network you resolve something.something.tld to your 172 address."

          Alas, these are just a few of the battles we have been fighting with a new IT department head for several years. We (my department) have pretty much tired of talking to a brick wall when asking for these types of setups and given up. For example, we can't even get them to give us entries in DNS for our stuff. Very frustrating. Until there is a shift in power, it will be as it is. Thanks for your help.

          Don

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