why was this access not blocked?

[RobLatour]

I had a failed log-on attempt to Home Assistant reported to me last night:

https://ibb.co/xXHLrBt

However, I have this alias and set of rules in place which I thought would prevent it:

https://ibb.co/7KjWgTt

https://ibb.co/6FvXLkk

The rules are associated with the WAN interface.

What am I doing wrong?

Of note: the Home Assistant device works within my LAN and is assigned an IP address within that (LAN) interface - but I figured access to it needs to go thru the WAN - so I associated the rules to the WAN interface - is this the problem?  Should I have associated them within the LAN interface?

[Demusman]

Rules are applied to the traffic coming into the interface.
So if you want to allow a LAN device access to another interface, the rule goes on the LAN interface.
Sounds like you're trying to block someone on the internet from accessing your LAN, is that the case?
If so, with no rules on an interface, everything is blocked.
You wouldn't need any of those 4 rules ( the 2 with the destination set aren't doing anything at all ) unless you have an open port to your HA. Do you?
If so, why???
Use a VPN.

[RobLatour]

@Demusman:

Thank you, regarding your questions ...

Sounds like you're trying to block someone on the internet from accessing your LAN, is that the case?

Yes, that is correct.

... unless you have an open port to your HA. Do you?  If so, why???

I've set up remote access to Home Assistant via a CloudFlare tunnel, as described here:
https://www.youtube.com/watch?v=xXAwT9N-7Hw

The reason for this is I want to control my home automation, via Home Assistant, remotely.

So you are suggesting I move the two rules with the source identified to the LAN interface rules, and the other two rules with the destination set I can just remove. ... is that correct?

[Demusman]

No, that wouldn't work since the IP's you're trying to block aren't on your LAN.
You can delete the two I said though, they do nothing.
The other two don't seem to be working either so you need to figure out how access is being gained.
Do you have other open ports on your WAN?

Why not just use your own VPN? opnsense uses Wireguard and OpenVPN natively, either would work.

[RobLatour]

@Demusman:

Thanks again.  Regarding your questions, ...

Do you have other open ports on your WAN?

I actually have OpenVPN setup on OPNsense, so the ports needed to support that are open; here is the core doc I followed to do that: https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/

Why not just use your own VPN?

To access Home Assistant via OpenVPN, I first have to connect via the VPN. I am using OpenVPN for Android on my cell phone to do that and it takes over a minute and a half to establish the connection.

To access Home Assistant via the Cloudflare tunnel, the connection is made in about 2 seconds.

So, clearly, connecting via the Cloudflare method is my preferred way to go.


Regardless, the issue I am trying to overcome is that I want to be able to use OPNsense to block the IP address that Home Assistant says tried to connect.  This isn't the first time I've seen it, or other addresses, try to connect in; so finding a way to block them is really my goal.

[meyergru]

Before trying something like that, one should understand what is going on:

Using a Cloudflare tunnel means that there are 5 IP adresses involved:

1. A clients IP from which an HTTP request originates (this is what your are interested in).
2. Cloudflares external IP which receives an HTTP request as a proxy
3. Cloudflares IP in which the Argo tunnel connects to your firewall's IP, coming from a range of Cloudflare IPs
4. Your external IP that Cloudflare connects to and which is mostly irrelevant, because it is being handled within the Argo tunnel.
5. Your internal IP (the one that HomeAssistant uses within your LAN). This is probably the terminating end of the Argo tunnel.

When a tunnel like Cloudflare gets a client request and decides is is not an attacker (e.g. DDOS bot or generally from a baddie), it can either directly connect via TCP to your Argo endpoint through your external IP or, if it terminates the TLS connection, build up a second TLS connection to your external IP.

Either way, what your firewall sees as originating IP, is only the IP from 3 above, which is always from Cloudflare. With Argo, I think it does not see a connection at all, because this is handled within a permanent outgoing connection of the tunnel which does not even give away an incoming connection to your firewall.

The only way you would get to know the originating IP is when a tunnel does introspection (i.e. terminates the external TLS traffic) and tells you about it in an HTTP header when they connect to your site. This is usually invisble to your firewall, at least you cannot reference that IP in any of your OpnSense rules - other than to block Cloudflare IPs, which is probably not what you intended.

While it may be the case that you observe different IPs contacting you, most of these should be from the tunnel provider and even if they are regionally different and tell you a bit about the originator, this may change at any time when they are being reallocated. With Cloudflare Argo, there should be no incoming connections at all, as the Argo tunnel only calls out. Thus, those IPs are only used for outgoing, not incoming connections.


Other than that, if you are not behing CG-NAT, which is probably why you are using Cloudflare tunnel in the first place, there may also be contacts from other (i.e. non-Cloudflare) IPs which you can block, but in that case, I would rather use a firewall rule to whitelist the Cloudflare tunnel AS with an OpnSense AS alias. That way, you can effectively lock out anybody else from your open port.

However, keep in mind that Cloudflare, being a free (as in free lunch) service, it also can and will be used by baddies themselves. So, when you allow connections over Cloudflare, you can be connected anyway.


Having sorted that out:

If you want to block connections for a specific interface, you must know that OpnSense has a priority which puts interfaces LAST, see "Processing Order" here: https://docs.opnsense.org/manual/firewall.html

Also, see the warning on that page:

NAT rules are always processed before filter rules! So for example, if you define a NAT : port forwarding rules without a associated rule, i.e. Filter rule association set to Pass, this has the consequence, that no other rules will apply!

[Demusman]

To access Home Assistant via OpenVPN, I first have to connect via the VPN. I am using OpenVPN for Android on my cell phone to do that and it takes over a minute and a half to establish the connection.

To access Home Assistant via the Cloudflare tunnel, the connection is made in about 2 seconds.

Regardless, the issue I am trying to overcome is that I want to be able to use OPNsense to block the IP address that Home Assistant says tried to connect.  This isn't the first time I've seen it, or other addresses, try to connect in; so finding a way to block them is really my goal.

You have an existing vpn connection and you aren't using it??
Just set the openvpn as the "always on" vpn on your phone and it is always connected.
No need for cloudflare at all and only 1 port open on your WAN.

Android - Settings / internet / vpn

[RobLatour]

@Demusman,

Thank you for the advice, but I would rather use the Cloudflare connection - I don't want to be using my cell phone bandwidth for an always-on connection.

[Demusman]

You aren't using any more bandwidth than the cloudflare. It only gets used when you access something on the vpn. Same as when you use cloudflare.
But that's your call. Won't have to deal with anyone else accessing your network over your own vpn is the reason I suggested it.

[RobLatour]

ok - thanks very much for your help Demusman - it is appreciated!

I'm not exactly sure why OPNsense can't block this, but I suspect it is because there is a direct tunnel through to my Home Assistant device and perhaps as such OPNsense isn't actually seeing the IP address itself.

In any case, I've opened up a feature request with the folks behind the Home Assistant Cloudflare addon to see if there is a way they can do the blocking
https://github.com/brenner-tobias/addon-cloudflared/discussions/331

However in the mean time I will give the always-on OpenVPN option a try and see how it works.

Again, with thanks

[meyergru]

I'm not exactly sure why OPNsense can't block this, but I suspect it is because there is a direct tunnel through to my Home Assistant device and perhaps as such OPNsense isn't actually seeing the IP address itself.

I explained why OpnSense cannot block such tunnel connections in detail above.

Yes, there is a tunnel - it is called Cloudflare Argo tunnel and you opened it! What you effectively did was to punch a hole in your firewall and handed over the keys to Cloudflare.

Demusmas is correct: You would be better off to use a VPN that can only be accessed by yourself.

[RobLatour]

@Meyergru
Thank you as well. 

Somehow I missed your first post, which is very helpful in explaining things.

For now, I have disabled the Cloudflare access and will see how it goes with the VPN approach.

Again thank you (@Demusman and @Meyergru) both for your insights and advice.

[TheAutomationGuy]

To access Home Assistant via OpenVPN, I first have to connect via the VPN. I am using OpenVPN for Android on my cell phone to do that and it takes over a minute and a half to establish the connection.

To access Home Assistant via the Cloudflare tunnel, the connection is made in about 2 seconds.

If connecting to your self hosted VPN takes 90 seconds, there is something wrong with your setup.  It should only take about 1-2 seconds normally to make that connection (about the same speed as your Cloudflare connection).

[RobLatour]

@TheAutomationGuy

Thanks, I have started to look into it.

My log on the client side says

3:26 p.m. TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

3:26 p.m. TLS Error: TLS handshake failed

but after that (which is taking up most of the connection time) there are a bunch of other entries ending with "Initalization Sequence Complete" and the vpn is then established.

[RobLatour]

@TheAutomationGuy

Thanks again, I found the problem. 

The client-side app I was using couldn't support the server-side Encryption algorithm and Auth Digest Algorithm I had specified. 

So I change the client side app to be 'OpenVPN Connect' and the  Encryption algorithm and Auth Digest Algorithm to ones that do work with it and Bob's your Uncle I can now connect via the VPN in a second or two.  So cool.  Thanks, again