Trying to block single host from internet only.

[PWCDC]

Hello,

I'm trying to block a single host from the internet only (still have access to local LAN resources). It simply isn't working.

I've tried applying the rule to "floating" as well as the relevant LAN interface, but neither works.
I am resetting states after activating the rule, but it doesn't make a difference.

The rule I'm using is as follows:

Action: Block
Direction: In
Source: (Single Host) The blocked hosts LAN IP
Destination: WAN
Port Range: Any to Any

All other options are default. The rule is at the top of the list (below the auto generated rules).

I've also played around with a variety of other options, but literally nothing works. I've tried to use an Alias as well. Has the "block" feature been fully implemented yet in OPNsense, or is it a placeholder? I've never gotten a block rule to work on OPNsense before.

As I said, I am resetting states following rule activation.

Is there anything else I can try, or is this a known issue?

Thanks,
PW

[PWCDC]

Okay. I think I am starting to understand. The problem is the following:

Destination: WAN

Counterintuitively, this doesn't work for blocking LAN clients access to the WAN. I'm guessing because the packets originating from the LAN get translated at the firewall (as part of the NAT process). My understanding was that NAT only changes the "source" part of the packet, so I'm still not sure why specifying WAN addresses as the destination wouldn't work.

I created an alias with all of the local LAN addresses:

Alias: LOCAL_LANS
Networks: 192.168.1.0/24; 192.168.2.0/24; etc

Then I did the following:

Action: Block
Direction: In
Source: (Single Host) The blocked hosts LAN IP
Destination: (!INVERT)LOCAL_LANS
Port Range: Any to Any

This appears to work, but it is counterintuitive. I can understand why there are so many threads asking how to block clients from the internet via the firewall.

I guess my question is:

Why doesn't using WAN addresses as a destination in the firewall rule work? What is "WAN Addreses" used for, if not for packets marked with a destination on the WAN address?

[tiermutter]

Why using FW rules? Can't you simply configure the host with a fake gateway adress?
This way I am blocking a smart TV from WAN but granting LAN access. Moreover there is no need for the firewall to process anything.

[PWCDC]

Why using FW rules? Can't you simply configure the host with a fake gateway adress?
This way I am blocking a smart TV from WAN but granting LAN access. Moreover there is no need for the firewall to process anything.

While I appreciate the suggestion, its a bit of a digression from my question. I am aware that spoofing the gateway on the host stops it from accessing the firewall.

My practical uses of the firewall notwithstanding, in this case I'm asking from a purely theoretical standpoint. I have been told by others in the industry that Opnsense's firewalls are not reliable, or fully implemented. I don't rely on rhetoric, so I am testing it for myself as time allows. I'm trying to understand how the firewall works and push it a bit. This is purely a lab installation.

The problem is, most of the threads on this topic either remain unresolved, or are people suggesting workarounds to the problem presented, instead of explaining the problem or why it exists or presenting a direct resolution. 

[Greelan]

I guess my question is:

Why doesn't using WAN addresses as a destination in the firewall rule work? What is "WAN Addreses" used for, if not for packets marked with a destination on the WAN address?

Because the destination of the packets is not actually the WAN IP - it is instead an IP somewhere out in the internet. The packet might be routed through the WAN interface (and indeed NATed outbound so that return packets can come back) but that doesn't change the actual destination.

The rule that you have configured that works is perfectly logical.

[jp0469]

Destination: WAN

Counterintuitively, this doesn't work for blocking LAN clients access to the WAN.

This is a very common misunderstanding due to the fact that the aliases "WAN address" and "WAN net" don't actually represent the entire internet. They represent the public IP that is assigned to you by your ISP and the subnet that it resides on respectively. Your solution is correct where you define the networks that you want to allow the host to communicate with and then use an inverse block rule. Just another point to note: There is no need to include the subnet that the host is on in that rule since that traffic is not evaluated by the firewall. In other words, if the host in question is 192.168.1.10, traffic destined for all of 192.168.1.0/24 will always arrive without restriction.

[thecodemonk]

Someone can correct me if I'm wrong, but wouldn't you do a rule where the source is the IP of the machine in question and destination is anything? It shouldn't affect lan to lan connections unless you are running multiple switches tied to multiple ports on the firewall hardware.

[Greelan]

That would possibly block packets to OPNsense itself and certainly wouldn't work if you were running multiple VLANs/subnets that you wanted access to

[thecodemonk]

That would possibly block packets to OPNsense itself and certainly wouldn't work if you were running multiple VLANs/subnets that you wanted access to

Got it. I didn't even think of that.

[packet loss]

I use the following rules on OpenBSD to prevent incoming and outgoing packets from a single IP on my LAN to the Internet. The rules should be very similar on OPNsense. These rules needed to be evaluated before network address translation rules otherwise it wouldn't work for me.

block quick on $WAN from any to 192.168.1.101
block quick on $WAN from 192.168.1.101 to any

Unfortunately at this time, I'm unable to test OPNsense to see if the rules would work.

[Patrick M. Hausen]

From: system in question
To: LAN_Net
Action: allow
Mode: quick

From: system in question
To: Any
Action: deny
Mode: quick

Doesn't work?

There are automatic rules in place that take care of things like DHCP and neighbour discovery, so permitting unicast to the LAN should be enough.

[nzkiwi68]

Let's make some assumptions;

• The IP address is 192.168.1.101
• This IP address is reachable on the LAN interface
• Make an alias called "rfc1918" (or any other name you like)
• Alias rfc1918 contains these networks:

• 10.0.0.0/8
• 172.12.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10
• 127.0.0.0/8

In that case, the easiest and best place for the rule in the LAN interface.
GUI> Firewall: Rules: LAN
Direction IN
Source: 192.168.1.101
Port: any
Destination: !rfc1918    (note the ! - Destination invert selected)
Port: any
Gateway: default

***** Make sure this firewall rule on the LAN interface is higher up, before, any other rule that allows LAN traffic out to the internet *****

The order of the firewall rules is very important, it goes from the top down....

This will block traffic entering the LAN interface from 192.168.1.101 going to any non private IP address, therefore blocking interface internet access.