Isolated VLAN and ACLs
Today I am testing switch-based inter-VLAN routing and have encountered a problem with an isolated VLAN. With a gateway ACL, I can override the isolation and permit communication with another VLAN. Now, if the isolated VLAN is switch routed to another VLAN (and not being routed through the gateway), switch ACLs are not overriding the isolation setting. Is this normal?
If so, I can always de-isolate the VLAN and create additional ACLs. If it is not normal, then there may be a problem in the latest firmware releases.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @jra11500
Thanks for posting here.
Yes, ACL takes precedence over isolated VLAN. I don't agree this is a problem. Normally, if you've decided to isolate a VLAN, there's no need to configure ACLs to allow communication with other VLANs/IP groups. If you have such requirements, I would advise against checking the "isolated VLAN" option.
- Copy Link
- Report Inappropriate Content
Hi @jra11500
Thanks for posting here.
Yes, ACL takes precedence over isolated VLAN. I don't agree this is a problem. Normally, if you've decided to isolate a VLAN, there's no need to configure ACLs to allow communication with other VLANs/IP groups. If you have such requirements, I would advise against checking the "isolated VLAN" option.
- Copy Link
- Report Inappropriate Content
Yep, this is normal - Switch routing doesnt touch the gateway so the the isolation setting doesnt effect it, you need switch rules to isolate it
VLAN Isolation is gateway only, basically
- Copy Link
- Report Inappropriate Content
Thanks for responding. I agree with you in that VLAN isolation is a gateway setting and it should not affect switch routing. But it does!
I have set up some VLANs with switch routing using your article as a guide. Things are somewhat working and I'll mention the problem I've run into in a moment. Back to the isolation matter... On one of the switch routed VLANs, I have connected a Windows laptop. It gets its IP address OK through the DHCP relay and the gateway IP shows up as the SVI of the core switch. When I do a tracert to another device on another switch routed VLAN, I can see that the packets are going to the SVI and being forwarded directly to the other device. If I isolate the laptop's VLAN on the gateway, the tracert returns the famous * * * after the SVI entry. It would appear that the gateway is somehow telling the switch to isolate the VLAN. That's the problem.
Back to the problem I have after setting up some VLANs for inter-VLAN routing. I have set up a Transit VLAN between the core switch and the gateway. The default route for the switch has the gateway's Transit VLAN interface as the next hop. Likewise, there is a return route to the switch with the next hop being the Transit SVI. The problem is that no traffic is passing through the Transit VLAN. It appears the traffic is continuing to use the subnet interfaces of the switch and gateway. For example, doing a tracert to a web site shows the SVI (in this case, 192.168.30.2) as the first hop and the gateway (192.168.30.1) as the next hop. Any ideas on what I may be doing wrong?
- Copy Link
- Report Inappropriate Content
I feel that I must disagree with you on this one. Many networks tend to have their IoT VLAN isolated. In my case, a smart TV on the IoT VLAN needs to have access to a media server on a different VLAN. Therefore I override the isolation with a gateway ACL allowing the IoT network to access the media VLAN. It is simple and very straightforward. The only devices on the media VLAN are the gateway and a NAS which hosts the media server. The NAS has its own firewall for limiting access to the rest of its ports.
On the ACL priority issue, my testing shows that a switch ACL is not overriding an isolation setting as the gateway ACLs do.
- Copy Link
- Report Inappropriate Content
OK, ill tackle your second question first
Traceroute will show the Gateway IPs as part of the hops - this is because the gateway has interfaces for them so internally it attaches them back to that interface because when a packet is going through it it is aware that [this packet=[this IP header==[must be this interface] - but - the interface is NOT actually being used. for packet transit. The Switch SVI and the Gateway are what responds to the ICMP request of the tracertoue and give you that feedback, it doesnt really reflect what is actually going on. You can confirm this by looking at the network traffic data counters on the gateway, you will see all traffic is going over the transit network, and only little bits (DHCP, DNS, some broadcast stuff etc) is going over the actual gateway interfaces per VLAN. Another way you can confirm this is split the links from switch to gateway - put the transit on its own untagged port on the switch, and match a port PVID to that on the gateway, and remove the transit from the other port. You will see all the activity over the transit link.
As to the first part with the *** response on isolated vlan, i dont see that on my config when tracing from one vlan to another via the switch on a gateway isolated vlan
- Copy Link
- Report Inappropriate Content
Thank-you for the quick response. I think I will try the split links idea and see how it goes. My surprise this morning (after leaving things alone overnight) was to find the data counter for the Transit VLAN at 0. I will let you know the results.
- Copy Link
- Report Inappropriate Content
If the data counter was at 0 it isnt being used.
Some things to check
- Make sure the switch SVIs are set in Gateway DHCP settings as the client gateway (dont leave it on "Auto")
- On the switch you are using for routing, edit the management interface SVI and remove the default gateway entirely
- Make sure the switch static route is 0.0.0.0/0 > Gateway Transit vlan IP
- Make sure the Gateway static route has all the destination networks > Switch Transit vlan SVI IP
- Make sure the Gateway static route doesnt have any spaces, dashes, underscores or special characters in the name
- Sometimes you have to reboot everything to make it work the first time, dont know why, after that it will always work
This should be all you need to do to route traffic over that vlan
- Copy Link
- Report Inappropriate Content
Again, thanks! The only thing I did not do before was to eliminate the management VLAN default gateway from the SVI. After doing so, I never noticed any difference.
After streaming video on the laptop and also on a TV connected to another switch-based VLAN, the Transit VLAN data counter was still pretty low. Still not sure why. The inter-VLAN routing was working OK despite the problems with ping and traceroute. Another problem surfaced... The wife's PC on a gateway routed VLAN started to have DNS related problems and could not resolve any domain names. The PC is downstream from the core switch but no settings were changed in that VLAN and the VLAN has connectivity to the gateway. For a lack of time, and to keep the wife happy, I decided to do this on another day. I have reverted back to my previous "router on a stick" configuration and everything is OK.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 59
Replies: 8
Voters 0
No one has voted for it yet.