Port Forwarding Not Working. Is it because of my WAN failover or LAN bridge?
-
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.
