Port forwarding ports 70-75 for UDP

axiomcs · Apr 8, 2019, 8:41 PM

An RMM tool I use requires ports 70-75 to be opened for UDP.
Here are two of my port forward rules:
🔒 Log in to view

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?

Grimson · Apr 8, 2019, 8:44 PM

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

KOM · Apr 8, 2019, 8:51 PM

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.

axiomcs · Apr 8, 2019, 9:10 PM

Please see this screenshot:
🔒 Log in to view

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:
🔒 Log in to view

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.
🔒 Log in to view

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.

Derelict · Apr 8, 2019, 11:22 PM

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.

axiomcs · Apr 9, 2019, 2:25 PM

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".

KOM · Apr 9, 2019, 2:28 PM

@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.

axiomcs · Apr 9, 2019, 3:18 PM

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?

KOM · Apr 9, 2019, 3:17 PM

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.

axiomcs · Apr 9, 2019, 3:20 PM

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?

KOM · Apr 9, 2019, 3:26 PM

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.

Derelict · Apr 9, 2019, 3:47 PM

@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?

axiomcs · Apr 9, 2019, 3:50 PM

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.

Derelict · Apr 9, 2019, 3:50 PM

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

axiomcs · Apr 9, 2019, 4:18 PM

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?

Derelict · Apr 9, 2019, 4:22 PM

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.

KOM · Apr 9, 2019, 4:26 PM

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