Wired, Open, VLANs, No Communication between Subnets on RT-AC68U running Merlin 386.2_4

[nytwolf]

I am attempting to introduce a new VLAN (VLAN4, 192.168.4.0/24) to my ASUS RT-AC68U running Merlin 386.2_4. At the moment, I do not want to isolate or otherwise prevent any traffic between this new VLAN4 and the default VLAN1. Please note VLAN1 has the router's default DHCP configuration and in VLAN4, for the time being, I am manually setting IP addresses on the devices.

Everything I have read, including Merlin articles and forums as well as basic Linux kernel and iptables articles and forums, indicate that the kernel should automatically forward packets between interfaces as long as kernel IP forwarding is on. The Internet has commanded to me that if traffic is not making it from one interface to another, it is due to iptables or whatever firewall on the device preventing this from happening.

I've introduced VLAN4. Both VLAN1 and VLAN4 can access the Internet without problem. Originally VLAN1 and VLAN4 could not speak to each other. Based on what the Internet has commanded me, iptables must be the culprit. Sure enough, I spotted what I assume was the problem:

user@router:/tmp/home/root# iptables-save
--- redacted ---
*filter
--- redacted ---
-A INPUT -j DROP
--- redacted ---
-A FORWARD -j DROP
--- redacted ---

This was easily remedied by using the UI: Firewall > General > Enable Firewall > No. This removed the two lines above (among others of course). To keep complications out of this situation, I've kept the firewall off throughout the duration of these attempts.

Attempts
The most basic situation I can configure that gets any type of communication between the two VLANs is by using the following:

robocfg vlan 1 ports "1 2 3 8t"
robocfg vlan 4 ports "4 8t"
vconfig add eth0 4
ifconfig vlan4 192.168.4.1 netmask 255.255.255.0 up

In the most complicated situation, I attempted to duplicate the br0 and vlan1 interfaces with the following. As far as how this new device appears, it seems to be a mirror image of br0, vlan1--aside from a different IP and MAC address. I'm realizing as I type this post, these are doing the same thing as above, just with extra steps and a new interface br4.

ip link add link eth0 name vlan4 address <HW MAC + 1>  type vlan id 4
ip link set dev vlan4 up allmulticast on
brctl addbr br4
brctl addif br4 vlan4
ip addr add 192.168.4.1/24 dev br4
ip link set dev br4 up allmulticast on
robocfg vlan 1 ports "1 2 3 8t"
robocfg vlan 4 ports "4 8t"

Result
In both of the above situations, pings are making it through between the devices. Anything substantial is failing. Originally I was attempting to access file shares, but to simplify the situation I've installed Plex Media Server on a machine in VLAN4. It pops up a small web server on port 80, automatically makes adjustments to the local Windows Firewall (which I later disabled altogether), and can send a reasonable amount of traffic between the two clients.

I clearly connect to the web server, but after the very first request the connection drops. So I pulled out Wireshark. Rather than further explain, I've attached a screen shot.
192.168.1.117 is a device in the default VLAN1
192.168.4.11 is a device in new VLAN4

I suspect I'm missing something obvious that is glaring me in the face.

 

[Yota]

You do not need to turn off the firewall:
Just use the following command

iptables -I FORWARD -i br4 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o br4 -j ACCEPT

 

[nytwolf]

Understood. I've turned off the firewall for the sake of the testing. I was going to get to allowing traffic between the two subnets after the primary issue.

The primary issue is with that suggestion (the iptables rules along with the firewall turned on) or with the firewall turned off, traffic is still not moving between the subnets as documented in the screen shot above. Any suggestions?

 

[grifo]

The CPU port on the RT-AC68U should be 5 not 8, retry the basic config after changing 8t to 5t on the robocfg lines, if it still doesn't work post a robocfg show, you can hide the MAC addresses if you like.

 

[ColinTaylor]

The CPU port on the RT-AC68U should be 5 not 8, retry the basic config after changing 8t to 5t on the robocfg lines, if it still doesn't work post a robocfg show, you can hide the MAC addresses if you like.

FYI, on my router the CPU port is 8 when NAT acceleration is enabled and 5 when it is disabled (and the WAN interface changes from vlan2 to eth0).

   1: vlan1: 1 2 3 4 8t
   2: vlan2: 0 8t

   1: vlan1: 1 2 3 4 5t
   2: vlan2: 0 5

 

[grifo]

Yep, the CPU port number changes depending on the configuration, on my RT-AC87U it changes from 8 to 7 when PPPoE is enabled which turns off FA.

It's likely that this is the area that @nytwolf needs to look at, confirm the correct CPU port number with robocfg show, if it's correct try to turn off NAT acceleration, recheck and update the CPU port number and retest.

Otherwise his basic config should work, barring anything new introduced in the 386 firmware that would break it (I'm still running 384.19 on my RT-AC68U AP). There have been changes to the VLAN configuration in the 386 fw for AIMesh nodes guest WiFi support but that shouldn't conflict with this basic config.

 

[Hyacin]

Result
In both of the above situations, pings are making it through between the devices. Anything substantial is failing.

Did you get to the bottom of this? I'm having a similar issue and in all my searching your post was the closest I've found. I think it broke with the last major firmware update, but I'm not certain.

AX86U so the bridge stuff and VLAN stuff is a little different, but, I can create VLANs no problem, they can talk to each other no problem, I can ping the internet from attached clients no problem - I can even do little grabs like `wget www.google.com`, but if I try to do anything 'substantial', like download a large file or even an `apt update`, it just freezes in its tracks.

I was initially thinking MTU and barked up that tree for a while, but after reading your post here I thought 'what the hell, why not?' and tried disabling the firewall entirely, and voila - a download started ... but then froze right up again around 50%. Attempting to restart, again, just frozen in its tracks. Turned the firewall back on, no change.

Yet everything works perfectly fine from hosts on my main br0 network - just not the VLAN interfaces.

It's smelling a bit like a hardware forwarding issue to me, but I can't be sure. Strangest behaviour I've ever seen ... and I KNOW my VLAN clients were working fine once upon a time with either this AX86U or the prior AX88U. I wish I'd paid more attention to exactly what had changed when they stopped working.