Port Forwarding Not Working
-
@datacare Did you go through each entry on the NAT troubleshooting list that was linked for you? In all the years I've been on this forum, I've never EVER seen a case where a NAT issue wasn't one of the items in the list. That's why Netgate made that list.
-
I have used the Netgate NAT Troubleshooting guide.
In example the pfsense gateway at WAN IP 24.149.91.10 is configure to forward port 8080 TCP to the pbx server on local IP 10.1.15.2. Testing access to this from 50.224.130.62 fails.As for hte firewall logs they show no listing of any NAT traffic related to this traffic.
There are no active states indicating port 8080 attempting to be forwarded.
Packet Capture shows traffic from the source IP arriving on the WAN interface but shows no related traffic on the LAN interface. Indicating to me that the gateway is receiving the traffic on it's WAN interface but not forwarding it.
The NAT and Firewall rules have been triple checked and reentered.
The pbx server at 10.1.15.2 is listening on port 8080 and is accessible on the internal network and from another lan as well. The pbx server has access to the internet through he gateway.
I created a similar gateway with same hardware in the lab. If I restore teh same config to it it also fails. However when a fresh install of pfsense and manually configured with the same rules exactly and works. But on the test system I used the default configured wan port igb0 where as on the production system we have reassigned the wan to port ix0 so it uses the available fiber interface. Although I have checked the gateway assignment in interfaces and routing, I believe somewhere in the wan port binding to the physical interface is likely where hte problem is.
-
@datacare said in Port Forwarding Not Working:
I believe somewhere in the wan port binding to the physical interface is likely where hte problem is
As much as this does not make sense at least to me I have to wonder..
I actually have a similar setup here where my interfaces use the same drivers and my primary WAN is now a fiber connection from a switch. I doubt I would see the same issue but may try just because I can..
I wonder if your config has something that is redirecting the traffic before it even gets to your port forward? Maybe @stephenw10 is watching and can chime in!?!
I am curious about your actual setup though.. what kind of equipment are you running pfSense on? Mine is in my sig line.
-
One thing I would check in the config, before blaming ix0 itself, is whether the NAT rule destination is still set to the old WAN address/interface somewhere. If the rule says WAN address it should follow the assigned WAN, but if it was restored with a specific VIP/address or an old interface group it can look correct at a glance and still never match.
A quick test is to add a temporary pass rule on WAN for that port with logging enabled, above any other WAN rules, then try from outside and see whether it logs as pass or never matches. If the packet capture sees SYNs on ix0 but there is no firewall log and no state, that points more to rule matching/destination than to the server side.
-
If you can reproduce it from one outside IP, I’d add logging to the generated WAN pass rule and also check Firewall > NAT > Port Forward that Destination is still WAN address, not a literal old IP/VIP from the restored config. Then look at Diagnostics > States filtered for 50.224.130.62:8080 right after a test. If tcpdump sees the SYN on ix0 but there is no log line and no state, the rule is simply not matching; comparing the NAT/rule section of the restored config with the clean lab config usually shows the stale interface/address reference.
-
Here is the faulty port forwarding config, with secure elements removed of course. faulty-port-forwarding-config.txt
-
Do you have any other port forwards that do work there?
If you see incoming traffic in a pcap but it never opens a state and never appears as blocked there are a few things that could be happening.
You might have a block rule that doesn't log. The default block rule does log but that can also be disabled.
You might have an IPSec instance that is grabbing the traffic.
You might have a captive portal instance inadvertently enabled on WAN.
I've seen all of those things.
Edit: Oh I see you posted the full config. CHecking....
-
Hmm, doesn't look like any of those things.
What I do see though is that at some point it looks like that config was manually edited to rename the internal interface IDs.
wan1andwan2would never be seen on a config generated entirely using the gui. That should be fin but it's not something that is ever tested. Is that possible? -
Yes you are correct. I believe when that gateway was originally deployed years ago I did edit the interface names manually to try to get them to display in a certain order in the GUI and I believe I changed the order they are listed in the config when I was working in that. That’s probably it! Well I will go out to the site and just reload the gateway from scratch this week.
Thanks to everyone for all your help!!!!
Rob
-
Mmm, that would be good to know. It does make me wonder what what it does with those config rules if they are not created as expected.
If you're able to it would be good to check the actual running ruleset with
pfctl -srandpfctl -sn.
