The port forwarding is one of my favorite features of the pfSense firewall. It works great when you want to allow external users to specific services inside the network, be it a local area network or DMZ. We have covered how you can create pfSense port forwarding in our previous article, and if you follow that guide step-by-step, you should be good to go, and I am sure that it will work fine in your environment too. I have personally followed the steps and tested them in my network.
In the previous article, we covered only HTTP, HTTPS, and RDP. And if you may be interested in trying the other services, all you have to do is change the port number to the one you will use, and it will work fine.
Why pfSense port forwarding not working?
Sometimes things may not work the way you anticipated, and you may be scratching your head to find out why the pfSense port forwarding is not working and how you can fix it?
The port forwarding may not be working for several reasons, and you cannot pinpoint a specific reason and say this is why it is not working. To troubleshoot the issue, you will have to take a step-by-step approach from the source to the destination. Sometimes the problem could be on the source side, or it may be on the destination side as well, but you never know until you start digging and troubleshoot further.
Based on my experience with pfsense port forwarding, there are few possible scenarios in which the pfSense port forwarding may not work well. Let’s look at some of them below. Hopefully, by following this, you should be able to figure out what’s going on and fix the issue.
Check the internet status.
It is the first step to verify. I am not joking; I also have faced this issue in the past 😊
After performing all the troubleshooting, I found out that the source machine doesn’t have internet reachability. So it is best to start pinging the external public IP addresses other than the one you are trying to allow on your WAN side and make sure the user can reach the internet.
For example, In our lab topology, we have enabled port forwarding on the WAN interface of the Firewall. It has the IP address of 18.104.22.168, so instead of pinging the IP 22.214.171.124, we can try to ping the DNS server IP address on the internet, such as 126.96.36.199 or 188.8.131.52, from the source machine.
If it is not working, you know the internet connectivity is down and you have to fix the internet connecitivity issue.
If it is responding to the PING, then the problem could be something else.
We mentioned the internet issue on the source side, and everything may be fine on the source side, the problem could be on the destination too. So, just like we tested the internet access on the source side, you may test it on the destination side as well. If the destination unable to access the internet, there is no way the port forwarding will work fine.
When you have dual ISP setup, you may have the ISP with which you configured the port forwarding might have gone down as well, so check the Status>Gateway, The ISP gateway should show as online.
Ensure the services are working locally.
When I started the lab in my previous blog, the first step I performed was to validate whether the services worked locally or not. If the services are not responding locally, you know that the issue could be on the local servers. You may check the following on the local servers.
- Check the services are running or not?
- Validate the port number. You might have changed the port number, and you may not remember it. Like we did in our previous setup, you can validate the port number using the telnet command. telnet <server IP> <port number>, if it is web server access the web page locally.
- Has the IP address on the local server changed?
The chances of IP address gets changed on the local server is very narrow. However, it is best to validate that as well. You never know where the problem lies when it comes to troubleshooting.
Check the firewall WAN hit count.
Your firewall WAN side should receive the packet when someone external tries to access the server configured for the port forwarding. After you made sure the services are up and running internally, you can now start looking at the firewall WAN side to see if you are getting any hits.
By default, the logs for the port forwarding will be disabled, and in our setup, we have enabled traffic logging on the WAN side rule. You can enable the logging by going into, Firewall->Rules->WAN->In the port forwarding rule, click on Edit logs and enable logging.
After enabling the logging, you could go to status, system logs->Firewall>And use the filter on top to filter out the specific source IP you are looking for and Apply filter.
If you do not see the hits on the logs, the issue could be on the source IP unable to talk to your WAN side IP. You have to check why the source IP unable to speak to your WAN side IP.
If you see the hits from the source IP, you can confirm that the connection from the source to the Firewall is good, and now you need to focus on the firewall port forwarding configuration to see if you have allowed the right source IP for the communication.
Is the pfSense firewall behind NAT?
Sometimes during the deployment, you might have kept the pfSense Firewall behind another router. The pfSense firewall might have private IP addresses, so if you enable the port forwarding on pfSense, it will not work because the pfSense firewall is behind the NAT, and you have not allowed the port on the WAN side of your local router. So, the fix should be to either replace your router with the pfSense firewall or every time you enable the port forwarding on the pfSense firewall, you will have to mirror the configuration on the edge router as well.
Has the DNS set up correctly?
For a webserver port forwarding, you most likely would have used a DNS entry for the same, so instead of using the IP address, the source user might be trying with the FQDN, and complaining that it is not working.
You can request them to try with the IP addresses instead of the FQDNS or domain name. If that is working, it is very evident that the problem is with the DNS record. You may validate the DNS record by using the NSLOOKUP and check if it is working correctly or not. Also, try different websites and see if it is responding. The problem could be our first statement as well. The internet might be down on the source machine end.