Trouble with firewall/NAT to allow remote Blue Iris access
Hi, still very much a noob. Not sure if this question/issue is more firewall rule, NAT, DHCP reservation, or something else.
I have Blue Iris (PC based video surveillance NVR) setup and working fine inside my private network. I'm trying to forward the port, open a firewall hole, and whatever other settings are needed to allow a Blue Iris mobile app to access the system and view video streams from outside my network. Blue Iris has a connection wizard that walks through some of the basic settings to accomplish that but so far I have failed.
My network architecture: celeron based network appliance with multiple Intel gigabit NICs. 192.168.1.x is the primary LAN for all home hardwired ethernet ports. The Blue Iris PC and all cameras are on a separate NIC and POE switch, on 192.168.7.x. I have created firewall rules that allow any address on the LAN interface to access the Blue Iris PC IP address, allow everything on the 192.168.7.x interface to talk to each other, and allow the Blue Iris PC IP to reach the internet. But I do not have the camera IPs exposed to the internet.
As I said, this is working internally, but I can not reach the Blue Iris PC from outside my network.
I've created a NAT rule that forwards any external IP/port combo with my WAN IP destination on port 81 to the Blue Iris PC IP on port 81, and auto created the firewall rule that allows that traffic. I'm wondering what else I may need to so?
I'm on C-spire fiber internet service. I just confirmed (I suppose) with their tech support that C-spire is not blocking anything from their side. However, in my troubleshooting I have also realized I can't ping my pfsense from outside my network either. I looked at a guide on how to create an echo type rule that allows that... can't confirm that I did it correctly since I don't get a ping return.
At a bit of a loss here. I'm sure I'm missing some important step, but not sure where.
Some extra info...
I did read through the NAT/port forwarding troubleshooting guide in the sticky, and tried to follow the NAT guide in the netgate documentation.
I also enabled UPnP and used the Blue Iris connection wizard to try and create the NAT/firewall rule that way. No change.
I enabled logging for the firewall rule created and just checked out the system logs. I'm trying to connect from a mobile client that currently has wifi disabled to forced it to go through cellular.
I can see in the system log entries when I try to connect that are apparently denied by the default deny IPv4 rule. The source is my cellphone momentary IP, the destination is the internal 192.168.7.100:81 address/port for the Blue Iris server.
The default deny rule would apply if there is no other rule allowing the traffic. The auto created rule should show on the interface for the server (presumably not LAN).
You can always create your own firewall rule also, though "auto" should work.
Screenshots of the NAT and firewall rule might help.
This is the NAT overview
This is the detail on the port forward
Overview of Firewall rules for WAN
Overview of Firewall rules for the Blue Iris interface
Detail on the WAN Firewall rule for the port forward
One more tidbit...
I can see the entries in the system logs each time I try to connect remotely, denied by the default deny IPv4 rule.
When I click the "Easy Rule: Pass this Traffic" option it creates a new rule that looks just like my existing firewall rule except for a single source IP address. If I try to connect, it still denies using the default deny rule. If I edit to make source "any" it is identical to my prior rule as far as I can tell, and of course still gets denied.
I... don't understand something obviously.
chpalmer last edited by
When I was running BlueIris I had no problem making this work.. I do not see any issue other than could it be looking for a UDP connection that you do not have allowed? I forget due to the amount of time that has passed since I did this.
The next thing to consider is that you need to remember that your machine running Blue Iris might have its own firewall that will by default consider everything outside of its own subnet as public and block it.. But since your 192.168.1.0/ subnet can successfully talk to it my bet is your already passed that.
Everything in the Blue Iris connection wizard referenced TCP but I guess that's worth a shot. I can create a UDP hole just to make sure.
Pretty sure I have defender disabled on the BI machine and the connection wizard seems to confirm that there is no local firewall running.
The pfsense system logs seem to suggest the request is being blocked by default deny rule instead of matching my forwarding firewall rules, but I just don't know why.
For a minute I thought maybe it's because of the multiple NICs/interfaces, but pfsense installs typically have 2 and that's all I'm really working with here.
Well, still at a loss. I changed to TCP/UDP with no difference.
I tried every combination of public/WAN IP address and internal Blue Iris server address I could think of in the NAT and firewall rules just in case I had misunderstood or overlooked something and of course no difference.
In system logs, I can see default deny rule block my connection attempts from the mobile Blue Iris app, and it seems to have appropriate destination address and port. Just don't know why my rules aren't passing the traffic.
I even did some reading on packet capture, and did a short run on the WAN interface while attempting to connect. I have no experience analyzing packets, but looking at what was captured in the WebGUI and Wireshark, it seems the destination address and port number are as expected so I'm back to... what is wrong with my rules that isn't passing this?
@rhosch since you know the source IP you could make an allow all rule to that server. Verifies it’s coming on that interface or whatever.
I tried that, I think. From the system log, I used the Easy Rule - pass this traffic option on one of the denied requests to create another firewall rule. That new rule looked just like my existing rule except that it had a specific source address. I tried to connect again immediately after creating that rule and the default deny still rejected it.
I just don't understand something obviously.
Oh wait... just read your post again and you said allow all. So, edit the destination and make it any? I'll try that.
OK, I used the Easy Rule: Pass this traffic option in the system logs/firewall page to create rules from the IP my mobile phone seems to be trying to connect to that allow traffic to any destination address, any port, any protocol.
I tried to connect using the Blue Iris mobile app, and default deny denied it. The source address listed in system log that came from my phone matches the rule source address I had just created.
I also tried to just connect to my WAN IP address on my phone, assuming it might take me to the pfsense login or page or something. I noticed in system logs that the source address reported for that attempt is different (because it is coming from my browser, not an app, and cellular company routes that differently maybe?), so I created a wide open rule for that too. Default denied. I checked the log and the source address in the denied connection matches the address in that new rule too.
So in all attempts, everything is just getting denied right up front. Is there some other global setting or something somewhere that I may have missed? Scratching my head. Usually that means it's something really simple I'm just not aware of!
OK, so after continued fumbling around I found the cause of the problem and a working solution, though I don't really "understand" the cause.
One of my firewall rules on the BlueIris interface (192.168.7.xx) was an IPv6 version of the IPv4 rule that was to allow the BlueIris server and only the BlueIris server on that interface to reach the internet. The IPv4 rule works fine and I can see that traffic from all the cameras on that interface attempting to reach the internet and do who knows what bad things is blocked. In my ignorance, I figured I may need that BlueIris server to also be able to reach out via IPv6 for whatever reason. So I found the IPv6 IP address of the server using ipconfig, copied the IPv4 rule and just changed it to IPv6 type with that address.
I couldn't see that anything was really wrong as everything worked internally, but in fumbling around and reading troubleshooting guides one mentioned that I should monitor the filter reload progress to make sure it actually completed. It didn't. The last line was an error loading that IPv6 rule. So I deleted that rule, and everything works fine.
What I don't really understand is what that rule had to do with preventing my NAT rule from working. Is it that perhaps that was the last rule I created before the NAT rule, and nothing created after was able to load properly? Otherwise, not sure I get the connection between that rule and forwarding along incoming connections.
For completeness, here's the error given in the filter load progress...
There were error(s) loading the rules: /tmp/rules.debug:197: rule expands to no valid combination - The line in question reads : pass in quick on $BLUEIRIS inet6 from fe80::ec6d:d1ad:cf93:1cf6%5 to any tracker 1603654490 keep state label "USER_RULE"
That would be my guess as well, that it aborted on that rule. Pretty sure the email notifications will alert on those types of things, as well as invalid aliases and the like (those I know appear in the GUI), so you might want to set that up in System/Advanced/Notifications in case it happens again.