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

    Port forwarding ports 70-75 for UDP

    Scheduled Pinned Locked Moved Firewalling
    17 Posts 4 Posters 1.4k 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.
    • A
      axiomcs
      last edited by

      An RMM tool I use requires ports 70-75 to be opened for UDP.
      Here are two of my port forward rules:
      4239e0ba-8938-456c-a00e-805b21d65eee-image.png

      When I verify port 70 for tcp, it is showing open.
      When I verify port 70 for udp, it is showing open.
      When I verify ports 71, 72, 73, 74, 75 for udp, they are showing closed.

      The app is listening (more accurately displaying status as "Allowed, not restricted") on all those ports as referenced in Resource Monitor->Listening Ports.

      I have used a number of port checking sites and all say ports 71-75 are closed.
      I have even created single rules for each port from 70 thru 75 with protocol udp, but it does not make a difference and it has the same result.

      I am using pfSense Community Edition version:
      2.4.4-RELEASE-p1 (amd64)
      built on Mon Nov 26 11:40:26 EST 2018
      FreeBSD 11.2-RELEASE-p4

      How can I get ports 71-75 with protocol UDP to become open?

      1 Reply Last reply Reply Quote 0
      • GrimsonG
        Grimson Banned
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • KOMK
          KOM
          last edited by

          How exactly are you testing? Check the document that Grimson linked to. It's usually one of a small number of issues and that doc covers them all.

          1 Reply Last reply Reply Quote 0
          • A
            axiomcs
            last edited by

            Please see this screenshot:
            32a47d78-e740-43d7-9f69-870d5e13db0b-image.png

            Several other similar sites show this port as closed (as well as, 71-74).

            Firewall enabled on client machine
            No Firewall enabled on receiving machine.

            Client machine is not using pfSense as its default gateway
            pfSense is default gw.

            Client machine not actually listening on the port being forwarded
            Client machine:
            d9f7a086-9d86-44b3-aa75-ab599f4dd278-image.png

            ISP or something upstream of pfSense is blocking the port being forwarded
            ISP not blocking.

            Trying to test from inside the local network, need to test from an outside machine
            Using outside port checking site.

            Incorrect or missing Virtual IP configuration for additional public IP addresses
            Not virtual.

            The pfSense router is not the border router. If there is something else between pfSense and the ISP, the port forwards and associated rules must be replicated there.
            pfSense is border router.

            Forwarding ports to a server behind a Captive Portal. An IP bypass must be added both to and from the server’s IP in order for a port forward to work behind a Captive Portal.
            Not using a captive portal.

            If this is on a WAN that is not the default gateway, make sure there is a gateway chosen on this WAN interface, or the firewall rules for the port forward would not reply back via the correct gateway.
            pfSense is the default gw.

            If this is on a WAN that is not the default gateway, ensure the traffic for the port forward is NOT passed in via Floating Rules or an Interface Group. Only rules present on the WAN’s interface tab under Firewall Rules will have the reply-to keyword to ensure the traffic responds properly via the expected gateway.
            See above.

            If this is on a WAN that is not the default gateway, make sure the firewall rule(s) allowing the traffic in do not have the box checked to disable reply-to.
            See above.

            If this is on a WAN that is not the default gateway, make sure the master reply-to disable switch is not checked under System > Advanced, on the Firewall/NAT tab.
            See above.

            WAN rules should NOT have a gateway set, so make sure that the rules for the port forward do NOT have a gateway configured on the actual rule.
            d6ce467c-0598-4f29-907a-9397eb6a9511-image.png

            If the traffic appears to be forwarding in to an unexpected device, it may be happening due to UPnP. Check Status > UPnP to see if an internal service has configured a port forward unexpectedly. If so, disable UPnP on either that device or on the firewall.
            UPnP is disabled.

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

              No real way to test UDP unless there is an expected response that is or is not received, like an answer to a DNS server query.

              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
              • A
                axiomcs
                last edited by

                So a site like this is not providing any data that is useful for a UDP scan?
                https://portscanner.standingtech.com/

                Even tho it says that UDP on port 75 is closed?
                What about when it says that UDP on port 70 is open?
                (These two rules, for port 70 and for port 75, are identical.)

                Is it possible that the receiving program is actually returning a response for port 70 and not for port 75? Altho in the list for listening ports it shows port 75 for UDP is "Allowed, not restricted".

                DerelictD 1 Reply Last reply Reply Quote 0
                • KOMK
                  KOM
                  last edited by

                  @axiomcs said in Port forwarding ports 70-75 for UDP:

                  Is it possible that the receiving program is actually returning a response for port 70 and not for port 75?

                  Check it and see for yourself. Diagnostics - Packet Capture. Run a capture while doing your tests and see exactly what pfSense sees. Capture on WAN to see what your client is sending to pfSense, and then capture on LAN to see what pfSense is redirecting to your LAN server. That will definitively tell you what's going on.

                  1 Reply Last reply Reply Quote 0
                  • A
                    axiomcs
                    last edited by axiomcs

                    Port 75 UDP packet capture on wan:
                    10:56:45.428039 IP 5.79.68.210.63921 > 71.xxx.xxx.xx.75: UDP, length 0
                    10:56:46.422908 IP 5.79.68.210.63922 > 71.xxx.xxx.xx.75: UDP, length 0

                    Port 75 UDP packet capture on lan:
                    10:58:53.634415 IP 5.79.68.210.41698 > 10.3.2.66.75: UDP, length 0
                    10:58:54.642094 IP 5.79.68.210.41699 > 10.3.2.66.75: UDP, length 0

                    Used this site: ipfingerprints portscan.php
                    Port 75 for UDP is showing as being open/filtered by this site: "75/udp open|filtered priv-dial"

                    The packet is getting to the right internal ip address, but don't know about it being length 0.

                    Your thoughts?

                    1 Reply Last reply Reply Quote 0
                    • KOMK
                      KOM
                      last edited by

                      I don't know about the zero length, but you now have confirmation that the NAT is working as expected and the testing site is giving you invalid results.

                      1 Reply Last reply Reply Quote 0
                      • A
                        axiomcs
                        last edited by

                        I misspoke and edited my response after you replied, sorry.

                        That site is actually showing that port 75 for UDP as being "75/udp open|filtered priv-dial".

                        So, apparently UDP can be tested with this site?

                        1 Reply Last reply Reply Quote 0
                        • KOMK
                          KOM
                          last edited by

                          Like Derelict said, it's very hard to test UDP because by design UDP is a blackhole. It doesn't require connection handshaking like TCP does. You just send data via UDP to an address and it will either reply or not. There is no error-checking. There is no rejecting or accepting the packets that the initiating client is aware of, so it's hard to detect if a port is open versus closed.

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

                            @axiomcs said in Port forwarding ports 70-75 for UDP:

                            So a site like this is not providing any data that is useful for a UDP scan?
                            https://portscanner.standingtech.com/

                            Even tho it says that UDP on port 75 is closed?
                            What about when it says that UDP on port 70 is open?
                            (These two rules, for port 70 and for port 75, are identical.)

                            Is it possible that the receiving program is actually returning a response for port 70 and not for port 75? Altho in the list for listening ports it shows port 75 for UDP is "Allowed, not restricted".

                            Yes. Snake oil. UDP 1194 is open here. Shows closed because there is no response. It shows 8.8.8.8/53 as open because they are probably looking for a DNS response.

                            Packet capture on your WAN for the UDP port and test. Does the traffic arrive?

                            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
                            • A
                              axiomcs
                              last edited by axiomcs

                              Yes, traffic arrives on the wan:
                              11:22:47.180223 IP 5.79.68.210.56897 > 71.xxx.xxx.xx.70: UDP, length 0
                              11:22:48.071388 IP 5.79.68.210.56898 > 71.xxx.xxx.xx.70: UDP, length 0

                              And packet capture for the lan:
                              11:23:39.045792 IP 5.79.68.210.51497 > 10.3.2.66.70: UDP, length 0
                              11:23:40.052512 IP 5.79.68.210.51498 > 10.3.2.66.70: UDP, length 0

                              Which is the correct internal ip.

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

                                OK then the server is ignoring it. Look there. The port forward is doing everything it needs to do.

                                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
                                • A
                                  axiomcs
                                  last edited by

                                  Is it possible that the packet provided by the site is not what the server is looking for? In other words, UDP's packets are specific to whatever the program wants to use, both on the sending side and on the receiving side? And therefore, any site that sends a UDP packet just doesn't know what the receiver is looking for and will say that the port is closed?

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

                                    No idea and the port forward doesn't care about contents. Look at the server. The port forward is doing everything it needs to do.

                                    TCP can be tested because if the port is open the test site sends a SYN and the server sends a SYN/ACK.

                                    Nothing like that exists in UDP.

                                    Not sure why you're still wrapped around the axle about the test site. The packet capture tells you all you need to know. The port forward is working.

                                    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
                                    • KOMK
                                      KOM
                                      last edited by

                                      We already went through this and established that everything was working an hour ago. You're just going around in circles now.

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