All Port Forwards Fail. No Changes. Has Been Working.
-
As the title states, last night all of my services became inaccessible from the outside (through the WAN interface). All of these services are accessible locally; and nothing has changed on the pfsense box. I updated to the latest version today AFTER the problem began as a last ditch effort to resolve this phantom issue (I've been troubleshooting this since last night). I can run a capture from the pfsense interface and see my external client hitting my WAN interface; but the port forward never occurs. It's like pfsense just suddenly decided to start dropping all packets that are configured to be forwarded. Has anyone seen this before? I am tearing my hair out and cannot figure out why this is happening. I confirmed with my ISP that they haven't enabled any new blocking that would prevent me from hosting these services from my IP. Thanks to all who reply!
P.S, I apologize if this isn't the best section for this question.
-
So you state you see the traffic hitting your pfsense wan.. But your saying your not seeing it sent out the interface your forwarding on? Do a sniff there as well.
Post your rules and your sniffs showing this.. And what exact version are you running. Are you running a 2.4 beta or do mean you just now updated to 2.3.3p1 ?
-
Something changed. No, port forwards don't just stop working.
Look at the firewall states in Diagnostics > States. Attempt a connection from the outside and filter on that outside source address.
You will see two states. One on WAN with the NAT translation and one on the inside interface for reply traffic without it.
WAN tcp 192.0.134.218:33888 -> 192.168.224.17:443 (198.51.81.11:443) ESTABLISHED:ESTABLISHED 6 / 5 743 B / 3 KiB
DMZ tcp 192.0.134.218:33888 -> 192.168.224.17:443 ESTABLISHED:ESTABLISHED 6 / 5 743 B / 3 KiBOriginal Destination Address
Translated Destination Address
Source Addresshttps://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
Something changed. No, port forwards don't just stop working.
Look at the firewall states in Diagnostics > States. Attempt a connection from the outside and filter on that outside source address.
You will see two states. One on WAN with the NAT translation and one on the inside interface for reply traffic without it.
WAN tcp 192.0.134.218:33888 -> 192.168.224.17:443 (198.51.81.11:443) ESTABLISHED:ESTABLISHED 6 / 5 743 B / 3 KiB
DMZ tcp 192.0.134.218:33888 -> 192.168.224.17:443 ESTABLISHED:ESTABLISHED 6 / 5 743 B / 3 KiBOriginal Destination Address
Translated Destination Address
Source Addresshttps://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
Thanks for your reply. The states screen shows the SYN sent; but then the connection is closed. Packet captures only show SYNs and no ACK, RST, FIN in return.
 -
So you state you see the traffic hitting your pfsense wan.. But your saying your not seeing it sent out the interface your forwarding on? Do a sniff there as well.
Post your rules and your sniffs showing this.. And what exact version are you running. Are you running a 2.4 beta or do mean you just now updated to 2.3.3p1 ?
Here is a screen cap of the LAN capture interface it is forwarding on. Also, I am on version 2.3.3-RELEASE-p1; upgraded yesterday from the minor version just prior to that one.
Thank you all for your replies!
 -
Well if pfsense is sending on the SYN.. Then your issue is with 192.168.1.67 –- why would you hide the port??
It could have stopped listening on that port? It could have a firewall that is blocking it. It could be using a different gateway and sending its ack back a different way? It might not even be the same box as before. etc..
But pfsense is clearly send on the forward.. So the problem is not with pfsense but something else on your network so that syn is not getting to the box, or the box itself.
-
192.168.1.67 is not responding, or its response is going someplace besides back to pfSense.
Your problem is not pfSense.
List of things to check here. Really check them. Don't just read the list and think, "I have already done all that." Really look again because the fault is 99.99% going to be listed there.
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
Well if pfsense is sending on the SYN.. Then your issue is with 192.168.1.67 –- why would you hide the port??
It could have stopped listening on that port? It could have a firewall that is blocking it. It could be using a different gateway and sending its ack back a different way? It might not even be the same box as before. etc..
But pfsense is clearly send on the forward.. So the problem is not with pfsense but something else on your network so that syn is not getting to the box, or the box itself.
I am in InfoSec and always try to keep as much about my network private as I can for business reasons (obscurity may not be excellent security; but it is one layer among many). The issue is not with x.x.1.67 because this is happening with numerous services running on multiple machines behind the firewall. None of the end machines receive the SYN when sniffing. This is why I thought it may have been the pfsense box. Thank you for your response.
-
"None of the end machines receive the SYN when sniffing. "
But clearly pfsense is sending them.. So its elsewhere else that is for sure.
You work in infosec and thought that hiding the port would hide some sort of info?? Dude really??? Come on!! If you said your new to networking and didn't know any better - ok then. But that you work in field.. Someones tinfoil hat seems a bit too tight..
-
"None of the end machines receive the SYN when sniffing. "
But clearly pfsense is sending them.. So its elsewhere else that is for sure.
You work in infosec and thought that hiding the port would hide some sort of info?? Dude really??? Come on!! If you said your new to networking and didn't know any better - ok then. But that you work in field.. Someones tinfoil hat seems a bit too tight..
Yeah, cant argue with the tinfoil hat comment. Funny thing is that when trying to scan my wan ip from outside i wasn't seeing any of my ports open. That's what confirmed for me it was a pfsense issue…well I thought anyway. There was a host networking problem and all the virtual infrastructure was being impacted. Got that resolved and now I'm back up and running. Thanks everyone! Still not sure why I had no listening ports from the external scan.
-
well they wouldn't be open on the external scan if the device it was being forwarded to didn't answer.. Port is only "open" if something answers with the ack.. Be blocked or forwarded is no different really if machine doesn't answer ;)
-
well they wouldn't be open on the external scan if the device it was being forwarded to didn't answer.. Port is only "open" if something answers with the ack.. Be blocked or forwarded is no different really if machine doesn't answer ;)
Good point. Sorry, my brain is fried. Got new littles ones and haven't slept more than a couple hours a night in over a month. Thanks so much for your help. You both have been a great help in a time when I desperately need it! :)
-
What we are here for ;) Glad you got it sorted.. The actual exchange of info is normally the hard part.. Always a piece of the puzzle missing it seems.. To be honest I don't recall an issue with port forwarding that was not actually pebkac..
Not saying there hasn't been any.. But I have been around these forums for a bit, lots of versions of pfsense - lots of posts.. And do not recall a port forwarding issue that was not peback related.. Common issue is traffic isn't even getting to pfsense wan - so how and the F could it forward anything ;) The hard part is getting the info needed to figure out what the user is missing..
