Linksys WRT3200ACM router configured with four VLANs:
VLAN10 (Secure computers and a media server, plus secure WiFi)
VLAN20 (VOIP adapters)
VLAN30 (Media players)
VLAN40 (Various insecure devices that require internet access and access from internet)
Also using HP ProCurve 1810-24G managed switch for handling the VLANs. THE PROBLEM:
I have tried for weeks to figure out how to selectively route traffic between VLANs and failed. Yes, firewall zones are created for the four VLANs, yes I've tried creating rules to forward traffic between VLANs. For example, I want VLAN10 to have unrestricted access to the other VLANs, but I have not even managed to ping from VLAN10 to a laptop on any other VLAN even with a forwarding rule specifying ICMP.
QUESTION: Has ANYONE set their OpenWRT router up in a similar way and figured out how to selectively allow traffic between VLANs? If so, can you get me started by telling me how to allow ping from VLAN10 to my other thre VLANs (but not vice versa)? Thanks....
First, I'm assuming that the VLANs are all on distinct VLANssubnets (and yes, the later post shows them to be) and that your HP switch is either running L2, or L3 with routing disabled (not all managed switches operate in an "L3" or "router" mode, and you probably don't want this if it does).
This type of situation, in general, requires allowing the specific "set-up" packet, then "trusting" conntrack to allow the return.
In the case of ICMP echo, the ICMP types involved are:
I'm not sure what you mean by "...the VLANs are all on distinct VLANs..." but each of the four VLANs is on its own interface (eth0.10, eth0.20, etc.) and the HP is a L2 VLAN switch. All four VLANs are tagged going out of the Linksys switch port 1, the other 3 switch ports on the Linksys are not used (so port #1 is effectively a trunking port). What so I need to do with the ICMP type info you provided?
You have zone forwardings from LAN and Eth0_X to WAN only. Which is fine to provide internet, but you don't allow any other interzone communication. On the other hand, all your zones have the same ACCEPT permissions, so if you want it like this it would make more sense to add all the Eth0_X interfaces to LAN zone.
I need all four VLANs to have internet access, DHCP, DNS, and I need VLAN10 and VLAN40 to have access FROM the internet (I will use port forwarding and/or Wireguard). But I need VLAN10 to have access to all the other three VLANs (VLAN20, 30, 40) but VLAN20, 30, 40 should not have access to any other VLAN. So what rules should I make and do I make them in the GUI or CLI?
So all zones can go to WAN and that's all.
Add more forwardings from vlan10 to all the others and that should do it.
You can either do it from CLI or Luci, whatever you prefer.
I'm still missing something, some key concept just hasn't clicked in my confused head. So I again not only enabled zone forwarding from VLAN10 to VLAN40 and from VLAN40 to VLAN in the Firewall - Zone Settings GUI, but I also built 2 rules under the Firewall-Traffic Rules GUI to allow any kind of traffic back and forth between these two zones (VLANs) as a test. I even reordered those two rules so they are at the very top of the firewall rules - See below.
Now I can remote desktop from VLAN10 to VLAN40 but I CAN'T remote desktop from VLAN40 to VLAN10. Why??? I also CAN'T ping from VLAN10 to VLAN40 or vice versa. Again, why???
User "Jeff" posted a reply to my original message stating "This type of situation, in general, requires allowing the specific "set-up" packet, then "trusting" conntrack to allow the return." I would love to know what that means, and get some guidance on how to implement these set-up packets with trusting conntrack. I looked up "conntrack" and I now know the definition, kind of....
(You can get someone's attention by mentioning them like @k9bm in your post. That usually sends an email to them and lights up their icon on the site.)
I use a different firewall tool on Linux, so I can't give specific examples, more of a general understanding.
conntrack is the Linux "process" that remembers which connections are active. Very often, a firewall rule set will have early on a rule that allows "related" packets to a connection that was successfully established. This "dynamic rule" lets "likely known-good" packets to skip the rest of the rules, both speeding performance, as well as letting "inside" clients access outside hosts without manually setting up the rule for return packets each and every time. The clearest of these is perhaps TCP with its handshake. By "watching" the packets, conntrack can tell when the connection is "established" and, if gracefully terminated, when it is disconnected (otherwise it times-out the record of the connection). Connections are typically based on (source host, source port, destination host, destination port, protocol details).
If, for example, you want to allow hosts in Zone A to connect to hosts in Zone B, but not the reverse, you might have a rule set that logically does something like
Kill "bad" packets
Allow established packets
...
Allow TCP setup ("state new") from Zone A to Zone B and record in conntrack (often implicit to record)
...
Kill everything else
So now if Zone A tries to connect to Zone B, it can do so and the return packets will flow by virtue of conntrack "remembering" the "valid" connection and letting them pass with the "allow established packets" rule
However, if Zone B tries to set up a connection to Zone A, it will fall through to the "kill everything else" rule and be denied.
There are similar rules for UDP (which is time-based, as UDP is "connectionless"). For ICMPv4 ping, the "connection" is created with an ICMPv4 Echo (request) packet, and conntrack considers a returned ICMPv4 packet to be "related" to that connection.
"Trusting" as, just because the packet matches the conntrack (or any other dynamic-rule system) parameters, doesn't mean that it is "100% certain" that it is truly associated with a valid stream, or "safe". Firewall "hole punching" with a STUN server for peer-to-peer connectivity is one example of what is technically a weakness of dynamic firewall rules.
Thanks @jeff, that makes sense to me. In fact, I think you are describing one of the facets of a stateful firewall. Now I can only hope someone can offer specific command examples in OpenWRT that will show me how to implement this. Equally important though, I still want to know what the purpose of the OpenWRT zone forwarding is when in fact it (apparently) doesn't allow me to ping and remote desktop between zones that are forwarded to each other, when those zones are VLAN interfaces....
a permissive directional policy is not the entirety of a ruleset / chain.
there is a simple interpretation of that statement and then there is reality. what a "zone" is and what an "interface" is, can entail multiple levels of abstraction and iteration. when you clarify these details, you'll have your answer.
i'd advise you to be subtractive rather than additive here initially...
A zone is a firewall construct which, among other things, makes writing and understanding rule sets easier.
A VLAN is a networking construct, that often has an interface presence on the running system.
A VLAN-enabled interface can be assigned to a zone, but they are all different things.
One thing to be careful with is that OpenWrt config often uses the same "character string" to refer to multiple things. OpenWrt also "helpfully" renames interfaces, especially things like bridges. I have found that being explicit in specifying names in my config helps me keep track of if, for example, I'm referring to an interface, bridge, or firewall zone.
OK, but in fact my (I thought) simple goal up front is to allow specifically VLAN10 access to VLAN20, VLAN30, and VLAN40 using any protocol (including ICMP), but those other three VLANs shoujld not have access to VLAN10 (VLAN10 is my "secure" VLAN). All four VLANs have separate and distinct subnets.
I get the feeling I'm dancing around a kernel of truth in all of this, and that truth may be that no one here has actually done this? It doesn't seem that it should be an exotic configuration goal, but maybe in fact it is. Or maybe it involves concepts and techniques way too advanced for a non-IT networking professional...?
I am trying to do exactly that. As can be seen from my firewall listings, I am only trying to get from VLAN10 to VLAN40, and right now I'd be delighted if I could just get a returned ping from VLAN10 to VLAN40. Sooner or later maybe one of the developers will wander this way with some clues....
One more clue: From either VLAN10 or VLAN40 I can ping the IPv4 address of either VLAN, i.e. from VLAN10 I can ping 10.0.10.1 and 10.0.40.1. But I cannot ping a device on VLAN40, for example 10.0.40.233. Is this meaningful?
The problem was that all the laptops I was using in my test bed are Windows machines, and by default they will not respond to ICMP requests from a different subnet. Simply adding a firewall rule in each Windows machine, per the thread posted above, fixed the problem. I'm posting this in the hope that it may save someone else the weeks of frustration I have gone through trying to figure out why zone forwarding in OpenWRT was not working as expected. It WAS working.
Thanks to all who tried to help, thread closed....
