I have 2 VLANs (example):
- VLAN1 - 192.168.1.1/24
- VLAN2 = 192.168.2.1/24
In VLAN2, I have a firewall rule that explicitely blocks all traffic (inbound), however, if I say RDP from devices in these VLANS from VLAN1 to VLAN2, I am able to make the connection, even through in my VLAN2 firewall rules I explicitely deny all traffic.
Looking at the firewall traffic, I have a floating rule that allows the traffic labeled "let out anything from firewall host itself" - I assume thus that because both of these VLANS have their gateways in the firewall, the inter-connection between VLAN's is allowed through their gateways?
How do I fix this? We definately want to restrict inter VLAN connections but also dont want to fiddle with built in firewall rules that can block unexpected traffic.
QuoteIn VLAN2, I have a firewall rule that explicitely blocks all traffic (inbound), however, if I say RDP from devices in these VLANS from VLAN1 to VLAN2, I am able to make the connection, even through in my VLAN2 firewall rules I explicitely deny all traffic.
You want to make the rule on VLAN1, direction IN, destination VLAN2 and block.
Thank you for the answer, I am however curious, seeing that we have a number of VLAN's, what is the solution to block this kind of behaviour on all of them? So effectively have a mechanism that when a new VLAN is created, we can simply create a single rule as appose to updating each interface?
Create an interface group named e.g. "Restricted" with all the VLANs in it. Create an alias named "Net_Local" containing all your networks.
Create rules like so:
Interface: Restricted
Source: Restricted net
Destination: This Firewall
Protocol: TCP/UDP
Destination port: DNS
Action: allow
Interface: Restricted
Source: Restricted net
Destination: !Restricted net (destination invert)
Protocol: any
Destination port: any
Action: allow
This allows DNS and Internet access but no cross VLAN traffic.
When you add a new VLAN
- add network to "Net_Local" alias
- add interface to "Restricted" group
Done.
QuoteIn VLAN2, I have a firewall rule that explicitely blocks all traffic (inbound), however, if I say RDP from devices in these VLANS from VLAN1 to VLAN2, I am able to make the connection, even through in my VLAN2 firewall rules I explicitely deny all traffic.
inbound (ingress) is from the view of the router "facing" the interface in question. For VLAN2 ingress is traffic that is coming from the VLAN2.
If you want VLAN1 to prevent access to VLAN2 you create the rule in VLAN1 with the destination set to VLAN2.
Quote from: mauzilla on February 28, 2025, 07:22:17 AMThank you for the answer, I am however curious, seeing that we have a number of VLAN's, what is the solution to block this kind of behaviour on all of them? So effectively have a mechanism that when a new VLAN is created, we can simply create a single rule as appose to updating each interface?
Set the destination in a VLAN to !RFC1918 and it would per default block all access to internal networks, as the last rule. Then create rules above to allow access to whatever you want.
Quote from: patient0 on February 28, 2025, 08:21:37 AMSet the destination in a VLAN to !RFC1918
I am always a tiny bit triggered by these recommendations because nowhere is it written that internal networks are necessarily using RFC 1918 addresses. And for IPv6 there is no such thing at all.
That's why I always recommend creating a "local networks" alias.
Quote from: Patrick M. Hausen on February 28, 2025, 08:39:39 AMQuote from: patient0 on February 28, 2025, 08:21:37 AMSet the destination in a VLAN to !RFC1918
I am always a tiny bit triggered by these recommendations because nowhere is it written that internal networks are necessarily using RFC 1918 addresses. And for IPv6 there is no such thing at all.
That's why I always recommend creating a "local networks" alias.
That is fair enough, and you are right it won't work in all cases and you approach is more refined and will work in all cases.
But that does mean more maintaining of aliases. And then in what context OT is in. If he/she is in a home setting my approach will work just fine, in a business maybe not so much.