1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

VLAN problem with Asus RT-N16

Discussion in 'Tomato Firmware' started by bronzegeek, Mar 4, 2013.

  1. bronzegeek

    bronzegeek Serious Server Member

    I'm trying to set up some VLANs with an Asus RT-N16 & am seeing some odd behavior that does not occur on my E3000. My goal is simple - use the RT-N16 to replace a combo of a Cisco switch & access point. My current setup has the Cisco switch with 2 VLANs (1 & 10) & a VLAN trunk back to an HP Procurve switch, with an older stock Belkin access point connected on VLAN 1 on the Cisco switch. I just need the N16 to act as an access point & switch, I do not need any routing, NAT, etc (WAN port is not even connected) - I have a separate firewall to perform any needed routing & NAT.

    The odd behavior is that on the N16 I see VLAN 1 traffic on a non-trunk port (LAN 3) that is assigned only to VLAN 10. I do not see this with the same config & version on an E3000. I basically created br1 & then created VLAN 10 with LAN port 3 & 4 assigned to it (with 4 tagged on both VLANs). Port 4 is connected to a trunk port on the HP switch (which has both VLAN 1 & 10). Both boxes are running shibby v1.28.0000 MIPSR2-105 K26 USB Big-VPN (also tried AIO on the N16).

    As far as I can tell, the ports are set up the same for the VLANs on both boxes (I assigned WAN port to VLAN 14 just to satisfy the VLAN GUI, the WAN port is not being used):

    n16:
    trunk_vlan_so=1
    vlan1ports=1t 3 4 8*
    vlan10ports=1t 2 8
    vlan14ports=0t 8

    e3000:
    trunk_vlan_so=1
    vlan1ports=1t 3 4 8*
    vlan10ports=1t 2 8
    vlan14ports=0t 8

    (when I refer to LAN port numbers I mean the way they are labeled on the devices & the GUI).

    Since I do not need any routing performed by these boxes (just want them to act as layer 2 switch), I assigned a dummy IP to br1 on both boxes (10.255.255.253/31 on N16 & 10.255.255.241/31 on E3000, br0 IPs are 192.168.219.247/24 & 192.168.219.246/24, respectively). The traffic on VLAN 1 uses 192.168.219.0/24 & VLAN 10 is my Internet connection (VLAN 10 is used for the external interface on my firewall). Running tcpdump on a laptop connected to LAN port 3 (assigned to VLAN 10) on the N16 I was surprised to see VLAN 1 (192.168.219.x) traffic, in addition to the expected VLAN 10 external traffic. I set up the same thing on the E3000 & as expected, only see external traffic on that port 3. In both cases I connected LAN port 4 to the same trunk port on the HP switch. with a 192.168.219.x machine connected to port 1.

    I tried to uncheck the br0-to-br1 rule on the LAN Access page, but it still shows up as checked after a save. As a sanity check I flushed the iptables FORWARD rul so that no traffic was permitted between br0 & br1 (i.e., no rules exist for FORWARD). I also cleared nvram on N16 using 30-30-30 method with WPS button & set it up again from scratch but still saw the same issue.

    Am I missing something obvious (&/or not so obvious) here?

    --
    Terry
     
  2. bronzegeek

    bronzegeek Serious Server Member

    Should this type of question have been posted in a different forum (e.g., Tomato forum or instead at tomatousb.org)? Just wondering, since no replies after 2 days.
     
  3. Toxic

    Toxic Administrator Staff Member

    - moved to tomato forum.
     
  4. cohen

    cohen Serious Server Member

    Hi Broonz!
    If your router is forwarding packets by default, then the systems again will be able to ping each other and you have to manually deny the layer3 traffic by iptables. If they aren't able to ping each other, then your system denies the forwarding by default and you don't need to take any further actions.
    -cohen-
     
  5. bronzegeek

    bronzegeek Serious Server Member

    I don't think this is an iptables issue. It works as expected on the E3000 without any iptables changes.

    As I mentioned before, on the N16 there are currently no forward rules. As a sanity check I flushed that chain.

    N16 iptables:
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    982K 146M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    5 248 shlimit tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW
    19 1273 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    183K 13M ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- br1 * 0.0.0.0/0 0.0.0.0/0

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination

    Chain OUTPUT (policy ACCEPT 17 packets, 8560 bytes)
    pkts bytes target prot opt in out source destination

    Chain L (0 references)
    pkts bytes target prot opt in out source destination

    Chain shlimit (1 references)
    pkts bytes target prot opt in out source destination
    5 248 all -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: shlimit side: source
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source

    I see VLAN 1 traffic from the other side of the VLAN trunk. For example, when sniffing on N16 port 3 (VLAN 10, untagged) I see traffic from VLAN 1 from 192.168.219.11 - this is a machine connected to an untagged VLAN 1 port on the remote HP switch. In my scenario I would not expect to see VLAN 1 traffic from a device on the remote switch when connected to an VLAN 10 port on the N16.

    N16:
    vlan1ports=1t 3 4 8*
    vlan10ports=1t 2 8
    vlan14ports=0t 8

    Also, if I sniff on the N16 trunk port 4, I see the outbound N16 VLAN 1 traffic being tagged as VLAN1. Similarly, if I connect a machine to port 3 (VLAN 10) then I see the outbound traffic being tagged as VLAN 10 on the N16 trunk port.

    To me it just looks like the VLAN bridging is not working properly on the N16 (but appears to work fine on E3000 with same config), so I wanted to see what I might be overlooking.

    --
    Terry
     
  6. bronzegeek

    bronzegeek Serious Server Member

    For what it's worth...

    I've done quite a bit more testing with multiple resets & firmware installs, & I'm now convinced there is a problem with my N16. I even tried to go back to square one & do a default reset & then install the stock Asus firmware. After doing so, I cannot get it to even consistently maintain a wireless connection with a basic config as access point with the stock firmware. I've probably spent more time on this device than the previous half-dozen ones I've used combined (using stock firmware, dd-wrt, openwrt, & tomato). It took me about 15 min to get the E3000 to do what I needed using the same Shibby build.

    Perhaps I got a lemon, any suggestions as to what else I can try before I box it up & send it back?

    --
    Terry
     

Share This Page