Only Some of my Port Forwards work ?
-
Starting to define the definition of insanity.
I have a phone system just installed and was given a list of ports that need forwarded to the phone system. However only half of them work ? I have deleted them, re-entered them, and they are identical to the working ones.
List of ports needed :
9300 - 9300 to 10.10.1.25 Closed
24493 to 2728 to 10.10.1.25 Open
16000 -16511 to 10.10.1.16 Closed
44443 to 443 to 10.10.1.25 OpenThe conversion ports for whatever reason work, but the port to port do not ?
PFSense 2.5.1 (Just upgraded it and made no difference.
Where to go from here ?
-
-
This one is not working.
-
Are you providing a VOIP server locally?
If the phone is local and the VOIP server remote you shouldn't need any sort of port forwards, I have a VOIP phone local and don't have any port forwards.
-
@nogbadthebad From my understanding the phone server is on site (Some Panasonic System) and the phone is off site (Cell Phone). Backwards in my opinion, but I believe they want to have a business phone in another location. I would use a server off site, not sure what he was sold or why.
This port forward is squeezing my brain though.
-
@cire3 Try killing the firewall states.
Diagnostics -> States -> Reset States
-
@nogbadthebad Yea, just tried that a little bit ago. Same issue.
-
Those rules aren't disabled are they, there is a mini square in the tick box ?
I don't use that colour scheme.
-
My 9300 rule that auto populated when setting up NAT Port Forward
-
@cire3 I'd start doing a packet capture on the WAN interface to see if the packets are hitting the WAN interface, maybe the ISP is blocking some of the ports.
Also I was talking about the NAT rule with the mini square not the firewall rule.
-
@nogbadthebad said in Only Some of my Port Forwards work ?:
packet capture on the WAN
Sorry, thought you wanted rule, as I already posted the NAT Forward rules. My bad. However I double checked.
I'm connected over VPN, and know enough to be dangerous...lol Any way I can packet capture on the WAN remote ? Never had to do this.
-
@cire3 yup have a look at the diagnostics section.
You can download the packet capture from the page and view in wireshark.
-
@nogbadthebad Just seen it after I asked the question. Way cool. Downloading now after trying to check port.
-
@cire3 Host address being my Static WAN ? And should I use a port or just capture?
-
And this from PFSense :
15:25:00.282522 IP 198.199.98.246.50719 > 198.0.115.21.9300: tcp 0
15:25:01.278833 IP 198.199.98.246.50719 > 198.0.115.21.9300: tcp 0
15:25:01.283582 IP 198.199.98.246.50724 > 198.0.115.21.9300: tcp 0
15:25:02.282636 IP 198.199.98.246.50724 > 198.0.115.21.9300: tcp 0
15:25:02.284759 IP 198.199.98.246.50731 > 198.0.115.21.9300: tcp 0
15:25:03.282818 IP 198.199.98.246.50731 > 198.0.115.21.9300: tcp 0
15:25:56.035819 IP 198.199.98.246.50880 > 198.0.115.21.9300: tcp 0
15:25:57.034127 IP 198.199.98.246.50880 > 198.0.115.21.9300: tcp 0
15:25:57.036750 IP 198.199.98.246.50883 > 198.0.115.21.9300: tcp 0
15:25:58.034059 IP 198.199.98.246.50883 > 198.0.115.21.9300: tcp 0
15:25:58.038290 IP 198.199.98.246.50889 > 198.0.115.21.9300: tcp 0
15:25:59.038237 IP 198.199.98.246.50889 > 198.0.115.21.9300: tcp 0
15:26:00.276783 IP 198.199.98.246.50895 > 198.0.115.21.9300: tcp 0
15:26:01.274091 IP 198.199.98.246.50895 > 198.0.115.21.9300: tcp 0
15:26:01.277837 IP 198.199.98.246.50897 > 198.0.115.21.9300: tcp 0
15:26:02.273897 IP 198.199.98.246.50897 > 198.0.115.21.9300: tcp 0
15:26:02.278893 IP 198.199.98.246.50899 > 198.0.115.21.9300: tcp 0
15:26:03.277951 IP 198.199.98.246.50899 > 198.0.115.21.9300: tcp 0 -
@cire3 OK so it looks like 9300 is hitting the WAN interface.
-
@nogbadthebad Yea, It would have been great to blame Comcast. Not today I guess...lol
-
Figured I would post in case something didn't look right
-
This is what's back in states
-
@cire3 Rules are read from the top down, I suggest you have a read:-
https://docs.netgate.com/pfsense/en/latest/firewall/rule-list-intro.html
Everything TCP will hit the 3rd rule down.
-
@nogbadthebad Reset States again, waiting for it to boot back up and VPN in
-
@nogbadthebad UDP to TCP/UDP to TCP. No change
-
@cire3 If you still have that 3rd rule you need to delete it, it won't hit your NAT rule.
Its very dangerous what you've done with that rule and if you havent noticed all your TCP traffic is hitting it.
-
@nogbadthebad Oh dam, corrected :)
Any other thoughts ? Hate to rebuild the box.
Only thing I notice is the port conversions forward, but the port to port match don't. Or it's just a fluke.
-
@cire3 I'd check with the supplier again, you've got to and - in your first post, is that a range or is it convert one port to another.
A packet capture using the phones IP address would show you whats hiting the firewall.
-
This was the direction I was given. Some ports convert, while one is a range
Ports Working :
44443 Convert to 443 Forward to 10.10.1.25 Status: : Open
24493 Convert to 2728 Forward to 10.10.1.25 Status : OpenPort Not Working :
16000 Through 16511 Forward to 10.10.1.26 Status : Closed
9300 Forward to 10.10.1.25 Status : Closed -
@cire3 Well your packet capture shows port 9300 TCP not UDP as per their info.
15:25:00.282522 IP 198.199.98.246.50719 > 198.0.115.21.9300: tcp 0
15:25:01.278833 IP 198.199.98.246.50719 > 198.0.115.21.9300: tcp 0
15:25:01.283582 IP 198.199.98.246.50724 > 198.0.115.21.9300: tcp 0
15:25:02.282636 IP 198.199.98.246.50724 > 198.0.115.21.9300: tcp 0
15:25:02.284759 IP 198.199.98.246.50731 > 198.0.115.21.9300: tcp 0
15:25:03.282818 IP 198.199.98.246.50731 > 198.0.115.21.9300: tcp 0
15:25:56.035819 IP 198.199.98.246.50880 > 198.0.115.21.9300: tcp 0
15:25:57.034127 IP 198.199.98.246.50880 > 198.0.115.21.9300: tcp 0
15:25:57.036750 IP 198.199.98.246.50883 > 198.0.115.21.9300: tcp 0
15:25:58.034059 IP 198.199.98.246.50883 > 198.0.115.21.9300: tcp 0
15:25:58.038290 IP 198.199.98.246.50889 > 198.0.115.21.9300: tcp 0
15:25:59.038237 IP 198.199.98.246.50889 > 198.0.115.21.9300: tcp 0
15:26:00.276783 IP 198.199.98.246.50895 > 198.0.115.21.9300: tcp 0
15:26:01.274091 IP 198.199.98.246.50895 > 198.0.115.21.9300: tcp 0
15:26:01.277837 IP 198.199.98.246.50897 > 198.0.115.21.9300: tcp 0
15:26:02.273897 IP 198.199.98.246.50897 > 198.0.115.21.9300: tcp 0
15:26:02.278893 IP 198.199.98.246.50899 > 198.0.115.21.9300: tcp 0
15:26:03.277951 IP 198.199.98.246.50899 > 198.0.115.21.9300: tcp 0 -
@nogbadthebad Just changed that a bit ago as I was testing both ways. Set to UDP per instructions. Just trying to find if the information I have is accurate.
Will it show open even if there is not a device on that IP ? Just a curious thing more than anything. Is PFSense rejecting it, or is the device not accepting it was my wonder
-
This is in States from me using portchecker.co
-
@cire3 Wait a second. Does portchecker.co use TCP ? If so, h
ow do I check UDP ? -
@cire3 Just used https://www.ipvoid.com/udp-port-scan/
-
UDP is pretty difficult to get clear picture of open or not, unless something actually answers.. It can fairly often show in accurate results.
If your sending UDP traffic - best to do is sniff on your pfsense wan while you send that traffic, etc.
-
@cire3 You have quite a few ports open, your pfSense GUI is open to the internet.
Nice purple background.
-
Yeah your top rule that says ping is ANY to tcp... Pretty bad rule!
This would be a proper rule to allow ping to your pfsense wan address
You would want to use the alias - in case your wan IP changes at some point in the future.
-
Rule removed, and thanks !
I believe I was trying to allow ping on WAN.
So do I have any way to determine my ports are working as they should ?
I have no clue if this device is even setup correct and I'm just beating my head against the wall for nothing ?
-
Well if the device uses 9300 UDP.. And you can send UDP on 9300 from outside your network.. Way to validate even if the device is not working on 9300 is sniff.
Sniff on your wan - do you see the 9300 UDP being send to pfsense. Good!
Sniff on the lan side interface where this IP your trying to forward sits.. Do you see the 9300 being sent on to this IP? If so good - pfsense is now out of the picture and doing what you told it to do.. If still not working something else going on, wrong IP your sending too, not listening on 9300 udp like you thought. Service not even running on this server, Firewall on this device, etc.
edit: example using that site linked too
Setup a port forward to one of my my machines 9300. Not listening on 9300 for anything.
But I can tell working because I see it sent on to my machine on 9300, even though the machine didn't answer
-
If you have a mac on the internet ncat might help:-
andy@mac-pro ~ % ncat -z -n -v -u 198.0.115.21 9300
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connected to 198.0.115.21:9300.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.00 seconds.
andy@mac-pro ~ % -
@nogbadthebad Sorry, no Mac on site to take over :(
Ok, so packet capture LAN and this is what I have
Port 9300 :
11:57:55.826423 IP 212.129.21.56.36032 > 10.10.1.25.9300: UDP, length 0
11:57:55.827646 IP 10.10.1.25.9300 > 212.129.21.56.36032: UDP, length 14
11:57:55.839031 IP 185.209.161.169.38480 > 10.10.1.25.9300: UDP, length 0I'm calling this good as it's hitting 10.10.1.25 Correct ?
Port : 24493 Coverts to 2728
12:01:32.723636 IP 88.119.179.10.43438 > 10.10.1.25.2728: tcp 0
12:01:32.736754 IP 185.86.77.126.58520 > 10.10.1.25.2728: tcp 0
12:01:32.738876 IP 185.83.213.25.55756 > 10.10.1.25.2728: tcp 0So I see it on LAN hitting 10.10.1.25
Port : 44443 Converts to 443 And works as it should (We can access GUI)
So all I have left is port range.
Port 16000 Through 16511 UDP
I used Port 16000 for testing
12:06:02.006380 IP 185.83.213.25.49331 > 10.10.1.26.16000: UDP, length 0
12:06:02.011625 IP 88.119.179.10.52783 > 10.10.1.26.16000: UDP, length 0
12:06:02.016003 IP 185.86.77.126.41816 > 10.10.1.26.16000: UDP, length 0
12:06:02.018484 IP 185.159.82.88.52425 > 10.10.1.26.16000: UDP, length 0Am I correct this is a win and PFSense is doing as it should ?
-
@cire3 Using this site as it allows more protocols
https://check-host.net/
-
@cire3 Quick question.
Any way to quickly put 10.10.1.25 and 10.10.1.26 in a DMZ for a quick test ?
All the DMZ I seen isolate and use different adapters as I understand why. Didn't know if there was a easy way just to test a device passing through the firewall?