Port Forward does not work..
-
@Bob-Dig Oops forgot about the order
-
@Bob-Dig said in Port Forward does not work..:
For testing do something with TCP.
Because it is more easy I have to add.
For instance, while it is showing as stealth because there is no service running on that port, I still see that the rule was triggered.
-
@johnpoz said in Port Forward does not work..:
@root1ng I don't see any hits on either of those rules that allow for your port forwards to port 9987 and 30033
First step in troubleshooting a port forward or any wan side firewall rule is validate the traffic actually gets to pfsense, go to like can you see me . org and send some traffic. Be it you allow it or forward it or not.. You should see that traffic in your packet capture.
For example just sent some traffic to port 9987 like your forward, as you can see from packet capture on my wan pfsense actually sees this traffic.
If pfsense never sees the traffic no amount of firewall rules or forwards would ever work.
30033 TCP seems to work, 9987 UDP doesn't and I don't understand why, all ports are open from ISP
-
@root1ng
The port checker might only be able to do TCP checks. -
-
@Bob-Dig said in Port Forward does not work..:
That does look good
Yes, but the main one is 9987 .. and for now it still doesn't work.
-
@root1ng said in Port Forward does not work..:
Yes, but the main one is 9987 .. and for now it still doesn't work.
Maybe your proxmox Firewall is blocking UDP?
-
@Bob-Dig said in Port Forward does not work..:
Maybe your proxmox Firewall is blocking UDP?
All firewalls are disabled.. tell me where to check and I'll come back
-
@root1ng said in Port Forward does not work..:
Yes, but the main one is 9987 .. and for now it still doesn't work.
As long as there is no service listening on this port at TCP, the access won't succeed naturally.
Your backend is listening at UDP 9987 and UDP probably cannot be probed with the port checker. -
@viragomann said in Port Forward does not work..:
As long as there is no service listening on this port at TCP, the access won't succeed naturally.
Your backend is listening at UDP 9987 and UDP probably cannot be probed with the port checker.I changed from UDP to TCP and I still can't access it with the port checker, I still get a timeout.
-
@root1ng
On the backend? And does it work from inside with TCP? -
@viragomann said in Port Forward does not work..:
@root1ng
On the backend? And does it work from inside with TCP?Not working ..
-
@root1ng
So I don“t expect it to work from outside. -
@viragomann said in Port Forward does not work..:
The port checker might only be able to do TCP checks.
Yeah can you see me can only do TCP.. you would have to use something that can send udp..
Here is one..
https://www.ipvoid.com/udp-port-scan/
But if when testing and tcp gets there via packet capture - its a good sign that udp is open as well. But yeah its never bad idea to actually validate
My bad for not noticing 9987 was setup for udp..
-
@johnpoz said in Port Forward does not work..:
@viragomann said in Port Forward does not work..:
The port checker might only be able to do TCP checks.
Yeah can you see me can only do TCP.. you would have to use something that can send udp..
Here is one..
https://www.ipvoid.com/udp-port-scan/
But if when testing and tcp gets there via packet capture - its a good sign that udp is open as well. But yeah its never bad idea to actually validate
My bad for not noticing 9987 was setup for udp..
In the packet capture log, only 30033 appears with the public ip, 9987 appears open on the last tool provided by you but does not appear in the log, I don't understand why it doesn't work
-
It seems that it finally appears, but I still can't connect to the teamspeak server using the public ip
-
@root1ng
Sniffing the traffic is the way to investigate this and to nail down the issue.
Run a capture on the WAN. If you can see the expected packets there, run a capture on the LAN side.However, it's required to know, which packets this service requires to work before.
-
@root1ng where did you sniff that - on the lan side interface of pfsense I have to assume because its already been forwarded to the 172.16 address. So pfsense did its thing.
Why your 172.16 doesn't answer could be lot of things, its not actually listening on that port, it has a firewall running not allowing it. Your sending to the wrong IP completely.
That device is not using pfsense as its gateway. But if your seeing traffic sent on from pfsense to the IP you want, and the port then its not pfsense issue.. Look to your device, or something else downstream in your network that could prevent that device from seeing the traffic.
Users all the time forget about host firewalls.. The only job pfsense has in this is sending it on to where you say to send it on too, if that device doesn't answer that is not a pfsense problem..
-
@viragomann said in Port Forward does not work..:
Sniffing the traffic is the way to investigate this and to nail down the issue.
Run a capture on the WAN. If you can see the expected packets there, run a capture on the LAN side.However, it's required to know, which packets this service requires to work before.
I came back with the log for WAN and LAN, I see that it responds to both, is it ok?
WAN:
LAN:
-
@root1ng where do you see 172.16.1.6 respond with traffic to its 9987 port?
I don't see a response to 192.241.153.165 port 53781 in what you posted.
