Greetings all.

How does this work. BI server on 192.168.1.240 will not allow a connection from 10.10.10.x network even though I have set it as an allowed network address. BI refuses the connection. It thinks 10.10.10.0 is a WAN address and states that only LAN connections may be made.
The user account has LAN Only selected. Deselecting LAN Only does allow the connection.

If 10.10.10.0 is a non-routable IP, then why would BI not see this as a LAN IP ?
My understanding is that deselecting the LAN Only would widen the attack plane.

In order to get to the bottom of it, let's clarify your observations. Walk through the steps you are taking with some screen shots to recreate what you're seeing. If you aren't sure how to post screenshots say so and we'll walk you through it.
If I'm honest, I don't know what that means.

Thanks for the response. As I mentioned in the post I do have this working. What I seek is understanding of the User settings LAN Only. I wonder if this is by design. I would have thought a private IP would be classified as LAN even if it is a different subnet.

As noted earlier it does work by de-selecting the LAN Only setting. It then authorizes the connection.

BI Server is on 192.168.1.240
A VPN connection is made and observed on 10.10.10.2 as noted in this clip of the log file:

10 3/5/2022 12:55:27.989 PM Server [::ffff:10.10.10.2]: Connected
10 3/5/2022 12:55:28.096 PM Server [::ffff:10.10.10.2]: AuthFailed {"auth-exempt":false,"reason":"LAN access only"}

Here is the User account setting:
Web Server Advanced Settings note the 10.10.10.2 specifically allowed: And the result on the Android App:

Gotcha. Daaamn fine observation there my friend... I think of it like progressive filtering...

First, a VPN by definition isn't (or better fkn not be) part of your LAN, as you have just experienced. LAN only filters outside from inside - nothing remote allowed. With LAN only enabled or disabled, you can further limit access by client ip. Disabling LAN only means you can specify any specific IP allowed access, regardless of whether its remote or local.

Unsure how BlueIris uses X-Forwarded-For headers, but try unselecting that and trying again. I'm going to make a number of assumptions about how BI5 handles that checkbox ahead -

X-Forwarded-For is used (from a network security perspective, usually by inexperienced developers) to identify known and/or trusted IP ranges for Access and/or Authorization. X-Forwarded-For is your device IP PRIOR to the VPN connection (eg on the WLAN or CGNAT you're using for connectivity). This means if you're using a VPN to hide your identity, X-Forwarded-For headers leaks your private details but that's a whole other topic for another dissertation.

Browse to http://ifconfig.me while connected to your VPN - if you want to keep using X-Forwarded-For and you only have a static range when you're connected to your VPN (eg another home or small business network and you're 100% positive you'll never need telephony providers and other IP ranges) then add the private IP range to the allowed list.

I'm not being snotty, but why bother with all of that? All you have to do is uncheck LAN Only and limit access to the specific VPN IP. If you want to prevent that IP, you could delete it from the list or, check LAN Only.

What do you mean by the "VPN IP"? The VPN IP on a small network is usually on teh same subnet but on larger networks, often on a different subnet. I'll do a rudimentary deep-dive that misses massive design aspects but it should help you understand and it'll be a bit longer.

In most networks like a home or small business that's on a single subnet is just like you say - why bother? You're right.

But as network requirements grow (eg for businesses), multiple subnets are often needed for whatever reason (security, broadcast storm limits, geographical locations, business or network layout choices, many many reasons) then you may want to limit access to BI5. I'll run a scenario past you:

Company has 150 staff, estimated 350 devices with growth projections at a maximum of 200 IP requirements per site (so a /23 is a wise choice, providing 510 usable addresses), has 3 offices in separate geographical locations: A, B and C. Company is rapidly growing and requires full connectivity between offices. The private range of 10.0.0.0/8 offers 16 million addresses so that range is often chosen over 192.168.* networks.

The network is layer-3 routed between offices as follows:

Office A: 10.0.64.0/23
Office B: 10.0.66.0/23
Office C: 10.0.68.0/23

Furthermore, it has a number of server LANs, they can be hosted at any of the offices or elsewhere.
For this example, I'll put the BI5 device on 10.0.0.10 on the 10.0.0.0/24 LAN. There could be a single LAN to allow VPNs in, one for core networking with only SSH available to selected IPs, a DMZ, the list of roles and the routing and IP rules between them is endless.

The above are different LANs at layer 2 (MAC layer) but thanks to routing, the same LAN at layer 3 (IP layer).

An example is the X-Forwarded-For headers can be used for LAN only to only allow Office B to access the BI5 server and deny Office A and C.

As I said in the prior post, this is a terrible configuration but it is done and I've seen examples in production that I scratch my head at. These permissions should be controlled before the packet is even on the wire in the secured subnet.

Having it as an option extends flexibility, especially as a company is growing but I personally prefer to never need X-Forwarded-For for anything.

Totally appreciate the reply. I know exactly what you're saying and don't disagree. But why bother? Hear me out. There is a mechanism to include and exclude any IP. End of story. Doesn't seem to me to be practical to spend development time to handle a VPN IP as a part of the LAN. Where do you get that you couldn't get before?

Not poo-pooing the idea, just looking at it from a Form Follows Function (Frank Lloyd Wright) perspective. I've seen a lot of people, and I'm not saying you're one of them, but a lot of people come up with their solution and try to get BI to behave using their strategy. I try break it down to, what does it look like when I get what I want - instead of this is the way I want to get there.

Read that on a bumper sticker...

I agree to make things as simple as possible, most home users shouldn't have a need for that feature. If anything, I'm surprised there's so much configurability in the BI5 application for networking. I tried to conjure up with a scenario above where the X-Forwarded-For could be relevant but just as you see it, it's not optimal and can be improved.

If we're configuring layer 3 permissions, why aren't we using the built in Windows Defender Advanced Firewall? It's quite excellent at its task and can also block or grant edge traversal but to my knowledge, can't replicate X-Forwarded-For because that's a tag added by many browsers and I'm guessing in this instance, the BI5 Android/Iphone app.

If used for Access and Authorization, X-Forwarded-For is similar in security strength like MAC filtering on a WEP wifi network - keeps honest people out but very easily bypassed using open source and free tools.

I've been using BI since v3 (2013) - robust rich features that satisfy a wide range of applications. In the space they are in, BI is best in class in my opinion.