Posted: Sat Jun 29, 2019 22:55 Post subject: Help with VLAN tagging
All —
I’ve been spending a fair amount of time researching how to put together a home network with an Untangle UTM as my gateway / router with a Netgear R8500 DDWRT setup. I’vs been able to setup my DDWRT as my main gateway and router no problem. I get into problems when I want to take advantage of Untangle UTM and place it before my DDWRT.
See network diagram attached. I can get untagged traffic into Port 2 and tagged traffic into Port 1 from DDWRT to Untangle - separately. But the moment hook em up both and do both simultaneously, the systems degrades quickly. I separated tagged and untagged traffic through different ethernet ports to troubleshoot.
On my VLAN setup, here’s what I start after making the updates in DDWRT GUI before modifying NVRAM:
I've been trying the same with 2 APs, behind UTM, unfortunately, I have yet to find a fully working and stable build for RT-AC5300. Recently I've had success with RT-AC68U on kongac 6/19/2019 build.
I'm a bod, but what I've noticed you do away without the "t" for tagging as the UI VLAN+Networking tab configuration on most of the latest builds works fine. If you don't mind me asking, why you have an untagged and tagged (2 wires connecting) or is it just a visualization? because the whole point of trunking is, so you just have to run one wire. The other thing is I try to stay away from the 15-22 range (even if port 16-21 are mainly used by Broadcom). So choose some other vlan Ids that aren't used/close by of the vendor's IDs. e.g. I used VLAN ID 3 (vlan3) as tag and assigned x.x.30.x to the bridge.
3 things:
1. Which build/version of DDWRT are you using?
2. Keep/save the existing settings (Even before you start making changes in GUI).
. As in Required Manual NVRAM Changes section of Switched Ports article tells, you use the value as it exists in NVRAM not the IFNAME.
So, as the senior member asked/suggested, try
Code:
nvram set vlan10hwname=et2
nvram set vlan15hwname=et2
nvram commit
So even before you make changes you need to see the output of your
nvram show| grep port.*vlans | sort
So you know what were all the values for port.*vlans and then change the vlan assignment ports.
Re: the vlanhwnames, I took the switch guide literally when they said to name it "et0" not realizing that I may need to stick with what my hardware is showing. I'll definitely try that out and report back.
To confirm, because my R8500 has 6 ethernet ports and a CPU code of 8, I need to make a number of updates to my portvlans - adding ports 7 and 8 and changing CPU port from 5 to 8.
To to bkaskar''s questions - I actually did use two separate cables for tagged and untagged traffic. Just for troubleshooting - ideal just use one line when both are working separately.
Per my diagram, I'm using Kong's latest build as of 6/8/19.
And yes, I did check settings before any GUI updates. It looked the same as what I've posted except that all the portXvlans just had a VLAN code without additional port attributes (e.g. 18 19 21).
Oh and bkaskar, I used higher VLAN ids > 8 (greater than my ethernet port count) because I found some erratic behaviors if my port numbers and VLAN IDs were similar.
Oh and bkaskar, I used higher VLAN ids > 8 (greater than my ethernet port count) because I found some erratic behaviors if my port numbers and VLAN IDs were similar.
Hi jocara, using higher vlan IDs is fine, you can use even [16-21] but then when you list vlan.*ports vs port.*vlans and compare; you have to pay attention and be careful looking at every entry That's why I avoid the range.
Again, I'm splitting tagged and untagged traffic thru different ports for trouble shooting.
Problems seem to happen when I want to send untagged + tagged traffic through the same port, or VLAN 10 + VLAN 15 tags thru the same port. Sending untagged or a single VLAN tag seems to work fine.
I've tried many versions of using or omitting "t" tags in vlanXports but it doesn't make a difference.
I've included an image of my bridge / VLAN settings in DDWRT. That parts seems to be OK.
Your networking setup looks OK, but are you assigning the IP to bridge (or unbridged WLAN) that you get from tagged 10 and 15?
try changing this to
nvram set port1vlans="1 10 15"
(firmware should automagically pic auto neg and other options i.e. 16 18 19 21)
or even
nvram set port1vlans="1 10 15 16 18 19 21" wouldn't hurt.
vlan0 is internally used by the SoC but I've noticed it is better to put vlan1 on the trunk.
Quote:
The moment I send both untagged and tagged traffic OR multiple VLAN tags to the same ethernet port, everything goes haywire.
You can put whatever on the trunk from UTM but technically only packets marked with 802.1q headers will be shifted to ports/bridges you define.
Also sometimes of you have 2 connections without aggregation/LAGG you can create loops.
Thus having one trunk makes the most sense.
I am having similar issues with my RT-AC5300. I have tried many scenarios but the moment I start defining VLANs router becomes unresponsive.
It works fine as Gateway but not as Router/AP... for my box I see now the CPU port is even not 8 - now its 7
bkaskar, My UTM is assigning the IPs to the bridges setup - br1 and br2.
I leave the bridge IP and subnet mask fields empty and disable multicast fwd, masqu / NAT, etc .. I have assumed thats OK because UTM DHCP is handling...
Am pretty sure I've tried your other suggestions but will try again in the coming days when I have time after work.
Just realized my last post got posted incomplete, but I think you got the jist.
I'm just wondering how your DHCPD is doing that on UTM, as on the DD-WRT side both br1 and br2 get the same MAC ID. I could be wrong but I had the impression one mac can only be assigned in one vlan to have IP assigned from that subnet. I've yet to try and see if I can use the same mac on 2 vlans to lease out IPs from 2 different subnets.
Joined: 13 Aug 2013 Posts: 6872 Location: Romerike, Norway
Posted: Tue Jul 02, 2019 16:50 Post subject:
jocara wrote:
I leave the bridge IP and subnet mask fields empty and disable multicast fwd, masqu / NAT, etc .. I have assumed thats OK because UTM DHCP is handling...
The router needs static IPs on it's LAN interfaces/bridges.