Port Forwarding Not Working. Is it because of my WAN failover or LAN bridge?
-
Dashboard View
-
@djmaxx007 said in Port Forwarding Not Working. Is it because of my WAN failover or LAN bridge?:
The packet capture didn't even register the incoming request at the desired port.
If you captured on WAN and the connection attempt never showed up, there is your answer. It was blocked upstream somewhere (modem, ISP, etc).
Otherwise, run through all of the items here: https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html
-
Still no success. I went through everything on the list for troubleshooting port forwards. There are two things different than the simple way I typically set these pfsense boxes up.
One is that there is a LAN bridge present as opposed to when I typically use a switch and just one of the LAN ports on the pfsense box. I'm not sure if I'm getting a rule incorrect. In this case, the LAN bridge is an interface and the firewall rule under that interface is set to let traffic from all sources, all destinations, and all ports pass. To recap, I'm using a 4-port intel NIC using the 1st port as WAN1, 2nd port as WAN2, and ports 3 and 4 in a LAN bridge. Port 3 is going to a switch with several devices and port 4 is going to an extra device. All devices are reachable/pingable and the device in question (DVR) is accessible from any other device in the network.
The second thing different is that there are two WANs. Under System-Routing-Gateway Groups I have WAN1 (Comcast coax) set up as Tier1 and WAN2 (4G) set up as Tier2. This is for failover. In 2.4.4, there is no longer an "Enable default gateway switching" option in System-Advanced-Miscellaneous so I hope it is enabled by default.
Anyway, this router is fully accessible from outside. I am remoted into it right now at port @1776, the port I designated for remote access for now. I can ping the IP just fine from my machine at home and the dyndns domain name is resolving to the same IP just fine (shown below). To clarify further, the ISP-provided modem is a modem/router and is set to bridge mode, so there is no routing, blocking, etc. being done there. The pfsense is getting the WAN IP and not a local IP so the issue is not a double-NAT/firewall issue.
Also below is the firewall log and the packet capture results.
For reference, my WAN IP ends in .201 and the remote system ends in 160.
So I'm wondering...if I can connect to the network remotely just fine, including the router itself using my desired port and a NAT rule, why aren't any of the other port forwards working? What am I missing???
-
Any ideas guys? I really need this to work. I don't understand how the firewall log says it's allowing the traffic, yet I still cannot connect to the DVR. Also the fact that I can remotely connect to the router in the first place but nothing else is another strange thing. Please let me know if you have anything! I'm willing to contribute financially to your Newegg fund for a useful answer!
-
Looks like the server is not responding. Check there.
That packet capture appears to be on the inside interface. The firewall logs show the traffic being passed and the pcap shows the SYN being sent yet there is no response. The firewall's job is done there.
Check (really actually check) everything here:
https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html
-
I went through every number on the troubleshooting page already, but I definitely am going to do it again just to be sure. Probably two more times in fact.
As far as the server not responding, it's a DVR and is responding fine from any other device within the network. I'm remoted into the pfsense (from the .201 address) to get these packet capture screenshots and my requests are showing up just fine. I just don't know where it's stopping. Maybe the DVR is responding but not able to go outbound?? Because I do agree with you that the firewall part seems ok. Perhaps the firewall rule for the LAN bridge out to the WAN? Can anyone post a standard example rule for a LAN bridge Interface going out to the WAN? Do I need a floating rule? Thanks in advance!
-
@djmaxx007 said in Port Forwarding Not Working. Is it because of my WAN failover or LAN bridge?:
it's a xxxDVR and is responding fine from any other device within the network.
The DVR has it's gateway set ?
-
Does your DVR gateway actually point to pfsense? A device can not answer a remote IP if it has no default gateway or route pointing to gateway for that source IP.
This is a common problem with some iot devices that are meant to only be used local, etc. Way to solve that is with a source nat of the traffic so it looks like it comes from pfsense IP in the same network as the device.
From 5 in the guide
If it is leaving the interface, and no traffic is coming back from the destination machine, the target system’s default gateway may be missing or incorrect
-
I have the DVR statically mapped by the pfSense's DHCP server so it's always getting the same IP along with the rest of the network info, including the gateway. When I look at the DVR's network info, everything looks correct. For clarification, the DVR is set to DHCP.
-
You can set the dhcpd to tell the device use this gateway... Doesn't mean it actually is using it.. Can you not look on the device for its network settings?
Sniff the dhcp info when dvr asks, did it actually ask for router? If not just because you tell dhcp to hand out the info doesn't mean your client is actually going to use it.
-
It's the universe trying to tell you not to port forward to a DVR.
Or the DVR has a built-in firewall or otherwise refuses to respond outside of its subnet. That seems more advanced than most other DVRs though, it comes too close to resembling actual security.
-
BTW, before this round of fiddling with this, I disabled the 2nd WAN interface and the 2nd WAN gateway, just to make sure it's not interfering with anything. Now I just have one WAN interface, 1 WAN gateway (which is the default), and 1 LAN bridge consisting of 2 NIC ports. Now the only difference between this setup and every other setup that works just fine is the presence of the LAN bridge. I'm really thinking that I have the rule wrong from the LAN bridge to the WAN because the pfsense itself doen't use that rule and I can reach it just fine. Anyone have a sample rule for a LAN bridge to the WAN?
-
And AGAIN... If you see the SYN go to the device and NO answer it has ZERO to do with pfsense.. ZERO!!!
You sure your sending to the correct IP? If PFSENSE sends on the SYN and you don't get back syn,ack then its something between pfsense and the device, or the device.. Or just the device not even listening on the port your sending too, or your not sending to the correct IP, etc. etc..
Pfsense sent the SYN... There is nothing psfense can do if there is no syn,ack back.
-
@jimp
These are the only security settings on the DVR (pics below). As far as DVR complexity and security goes, it's pretty standard. There are no firewalls or blocked ports.@johnpoz
Just to be sure, I'll set the IP info on the DVR manually to ensure that it gets the proper gateway. Also, it seems fine from the device to the pfsense because I can access it from any other computer on the LAN. I posted the NAT rule above showing port 85 being forwarded to the internal IP of 192.168.2.9 at port 85. Same as I've done many times. Let me change the IP info manually and I'll update this thread... -
Testing from the same subnet wouldn't tell you much because that doesn't involve the gateway or routing, it's all local on the switch/L2 and doesn't hit the firewall.
You'd need to test from another different local subnet for a proper local test.
-
@jimp
I've actually been remote the entire time. I only test periodically from within the subnet just to ensure that the DVR's local network settings are correct and that the DVR is reachable from, well, outside the DVR. To clarify, I can in fact reach the DVR from any other computer on the LAN. I just don't know what'b blocking access from the outside.I just deleted the bridge interface group from Interfaces -> Assignments and recreated it. I included OPT1, OPT2, and the bridge interface itself. Then made a firewall rule for that bridge group. Just wanted to make sure I'm doing this part right. Pics below...
JUST IN
Holy crap I got it. I had a floating rule I set up for some reason when I originally set this up and just deleted it and it works! Well damn... Going to test to be sure. -
And what was this floating rule? Since clearly if you were putting syn on the wire and not getting a response I hard pressed to come up with a floating rule that would case you a problem.
-
@johnpoz
It was a floating rule to allow traffic from the LAN bridge interface to the WAN interface. Not sure why it was there. I don't remember setting that up (could have been one of my guys, but either way the responsibility is on me). I matched all rules with a known working setup very similar to this one and noticed this extra floating rule that isn't in the working system. The second I deleted it and refreshed the DVR web gui, it worked. Problem solved! I suppose just laying out my problem here helped me to be more thorough. I'll definitely look out for stupid rules next time. Thanks for all of your responses! -
Your sniff was where exactly? You showed no response on your sniff.. Was this not taken on the interface where your DVR was actually connected? So your DVR was answering - but you were blocking it from getting to where you were doing the sniff?
-
@johnpoz
The sniff was done on the WAN interface. The floating rule must have been incorrect as it was not allowing all traffic out from the LAN bridge to the WAN (besides http/s), but was letting traffic in and to the DVR. Since the pfsense web configurator port itself is not part of the LAN bridge, it seems that's why it was accessible from the outside but nothing else was. I will recreate the rule tomorrow to show that it was the cause and post results. Either way, that rule was the only difference between a very similar working setup and this setup. I tested (refreshed) between each configuration change and nothing worked until I deleted the floating rule, which was the last change to make so that this setup matched the working setup. Sorry for the noob problem, but each new solved problem is a new learning experience and one that will not be repeated again.
