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

    Port forwarding ports 70-75 for UDP

    Firewalling
    4
    17
    1.1k
    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.
    • 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.