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

    Forwarded ports can't be accessed when using other ISP

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 2 Posters 1.0k Views 3 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.
    • R Offline
      rjabellax5
      last edited by rjabellax5

      Good day Everyone,

      I'm having this issue with my mail server behind my PFSense box. All ports are closed when I try to use online port scanner when connected to my backup ISP. My setup looks like this:
      Mail-Network.png
      The mail server is originally NATed 1:1 to a public IP address on ISP2 but when I simulate a ISP failure, the ports that I have forwarded in ISP1 cant be accessed from the internet even I have associated it with a firewall rule and gateway grouping is set to failover. All host behind the PFsense can access the internet through ISP1 and VPN Clients from other branch can connect to ISP1's public address on UDP ports defined in rules.
      Capture3233232t.PNG
      Untitleddsdsds.png
      Even if these mappings are disabled
      Capture111111.PNG
      This is my mail server's public zone
      Capture1111222.PNG
      Capture3233232tffggg.PNG
      This scan is a result when I enabled the PLDT Interface back
      Capturennmm.PNG
      What I dont understand is when i enabled back the ISP2's interface, the ports can now be accessed using the ISP1's IP.

      I'm using DNSMadeeasy as a failover for A records.

      Any help would be very much appreciated.
      Thank you.

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

        You have DCTECH and PLDTFIBER in your rules and ISP1/ISP2 in your description. Which is which?

        Describe, specifically, the connection that is and is not working preferably using IP addresses and ports and protocols.

        I do not see any rules on the PLDTFIBER interface passing any traffic to 10.50.12.17.

        Need more clarity to help.

        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
        • R Offline
          rjabellax5
          last edited by

          Hello Mr Derelict,

          Sorry I wasn't specific. ISP1=DCTECH and ISP2=PLDT
          the DCTECH is the one having problem when connecting from outside,
          heres the rule for PLDT interface
          Untitledvvvv.png
          dadasdasdfdfdfd.PNG

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

            It is probably something in the list of things to check here:

            https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

            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)

            R 1 Reply Last reply Reply Quote 0
            • R Offline
              rjabellax5
              last edited by

              This log is when i ran a port scan from the internet
              Captureccvvbbnn.PNG

              1 Reply Last reply Reply Quote 0
              • R Offline
                rjabellax5 @Derelict
                last edited by rjabellax5

                @Derelict said in Forwarded ports can't be accessed when using other ISP:

                It is probably something in the list of things to check here:

                https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

                Hello Mr Derelict,

                I have read the troubleshooting documentation and done some packet capture. When I ran a portscan from the internet, it comes in to DCTECH interface but theres no traffic coming back.
                States.PNG
                Capturedsdsds.PNG
                But when i change the interface for packet capture to LAN, i cant see any traffic leaving the LAN interface. The mail server also has an Default gateway configured
                ffggvvbb.PNG

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

                  Those are all logged passes, not blocks.

                  If that packet capture was taken on the inside interface, which is likely since NAT has already happened, those are the TCP SYNs going to the server. Your mission, should you choose to accept it, is to find out why the connection attempts go out and there is no response received.

                  The pfSense firewall is doing everything it is supposed to be doing. Look at the target server.

                  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
                  • R Offline
                    rjabellax5
                    last edited by

                    Solved my own problem by disabling the rule associated by my limiter.
                    Thanks Mr Derelict for the time.
                    disabled-limiter.PNG

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