WAN over VLAN

anav · May 9, 2021, 5:58pm

Working my way through the config I am confused on your two WAN inputs.
Can you confirm that they are fixed WANIPs that wont change so there is no dhcp client settings for example.
wan1 is 192.168.8.2
wan2 is 192.168.9.2

My main difficult is how to handle vlan100 and wan 2.
Its easy to accept it on etherport 5 of the switch and assign vlan100 to the incoming traffic and drop the vlan100 on the outgoing traffic.
Its easy to carry this traffic to etherport1 on the switch (the trunk port) and carry it along with vlans10(MGMT) and vlan20 (users) to the corresponding trunk port on the RB3011 etherport 10.

Here we have a bridge that all three vlans belong to
with vlan10=lan list memeber
with vlan20=lan list member and
with vlan100=WAN list member.

How do I get the RB3011 to accept Vlan100 as incoming wan traffic.
Is it enough to state its a WLAN list member.
What is the format of the IP address since I also have the questions above, for VLAN100??

frank333 · May 9, 2021, 6:45pm

@anav
Yes, the 2 WANs have fixed IPs
wan1 is 192.168.8.2
wan2 is 192.168.9.2

frank333 · May 10, 2021, 3:49am

I tried the script; I had to enter / interface bridge port add bridge = bridge interface = ether10 instead of / interface bridge port enable [find interface = ether10] .
From a client connected to the netgear I can’t reach the main page of the LTE router (192.168.9.1) and the ping doesn’t work,
from 3011 if I ping 192.168.9.1 it responds .

sindy · May 10, 2021, 5:05am

When you connect the same client to any of ether2..ether9 on the 3011 instead of 02..04 on the GS105E, do you get the same result?

Can you show me the export after applying my script?

frank333 · May 10, 2021, 5:54am

When connecting a computer to a bridge port on the 3011, I cannot ping 192.168.9.1.
Here is the configuration after the changes.
mod_vlan.rsc (13.1 KB)
I do not understand these settings

sindy · May 10, 2021, 8:44am

This interface list row is definitely an error - my script should have changed ether10 to wan2-100 on it. I’ve tested it on my lab CHR and it worked, interesting.

Nevertheless, this does not explain why you cannot ping the LTE IP. So once you fix that row, make the command line window as wide as your screen allows, run /tool sniffer quick ip-address=192.168.9.1 in it, and start pinging 192.168.9.1 from a PC connected to a bridge port of the 3011. If everything was OK, you would see the following:

etherX    ... <- ...       ip.of.the.pc    192.168.9.1  ...  ip:icmp
bridge    ... <- ...       ip.of.the.pc    192.168.9.1  ...  ip:icmp
wan2-100  ... -> ...        192.168.9.2    192.168.9.1  ...  ip:icmp
bridge    ... -> ...  100   192.168.9.2    192.168.9.1  ...  ip:icmp
ether10   ... -> ...  100   192.168.9.2    192.168.9.1  ...  ip:icmp
ether10   ... <- ...  100   192.168.9.1    192.168.9.2  ...  ip:icmp
bridge    ... <- ...  100   192.168.9.1    192.168.9.2  ...  ip:icmp
wan2-100  ... <- ...        192.168.9.1    192.168.9.2  ...  ip:icmp
bridge    ... -> ...        192.168.9.1   ip.of.the.pc  ...  ip:icmp
etherX    ... -> ...        192.168.9.1   ip.of.the.pc  ...  ip:icmp

But I assume you actually get

etherX    ... <- ...       ip.of.the.pc    192.168.9.1  ...  ip:icmp
bridge    ... <- ...       ip.of.the.pc    192.168.9.1  ...  ip:icmp
ether1    ... -> ...        192.168.8.2    192.168.9.1  ...  ip:icmp

In another words, this has nothing to do with moving the WAN 2 configuration from bare ether10 to wan2-100, it’s your PCC rules that causes this. When you ping from a PC, the PCC rule in mangle.forward may assign a connection-mark value WAN1_conn, which one of the subsequent rules translates to routing-mark value to_WAN1.

And since ICMP uses no ports, the result of the PCC evaluation only depends on source and destination addresses, so you get always the same result when pinging from the same PC.

You’ve fallen into the same rabbit hole like many others - the match condition dst-address-type=!local matches on any other destination address than one of the router’s own ones, so it does not prevent the rule assigning WAN1_conn from acting on packets towards 192.168.9.1.

So add all the connected subnets (192.168.8.0/24, 192.168.9.0/24, 172.16.10.0/24, 10.0.0.0/24) to an address-list called connected-subnets and replace dst-address-type=!local in the PCC rules by dst-address-list=!connected-subnets.

anav · May 10, 2021, 12:08pm

Bogged down in scripts…
Why not solve this cleanly first without scripts, then get fancy??

sindy · May 10, 2021, 12:25pm

@anav:
What scripts? Where?

If you mean the reconfiguration script a few posts above, a script is the most concise way of expressing the necessary configuration changes. I’m not going to create a presentation with screenshots of all the relevant windows before and after. But you can always translate a script into corresponding mouse clicks rather than copy-pasting it, the choice is yours.

frank333 · May 10, 2021, 12:30pm

I’ve tried changing the mangle as you told me, I can’t ping from any pc, either directly to the 3011 or from the netgear.
rule_mangle(1).rsc (2.58 KB)

sindy · May 10, 2021, 12:42pm

How does /ip firewall address-list export look like, and what does the sniffing as suggested above show?

frank333 · May 10, 2021, 12:52pm

I cannot add wan2-100 to the bridge, nor can I add it to the interface list, I can use wireshark on the port for sniffing.

sindy · May 10, 2021, 1:00pm

If you have in mind adding wan2-100 as a member port of a bridge, it’s correct that you cannot add it. wan2-100 is a VLAN interface whose tagged end is attached to the bridge, so making its tagless end a member port of the same bridge would create a loop, hence it is good it is not possible. Your previous configuration export shows that everything is correct in this regard.

Regarding making wan2-100 a member of an interface list instead of ether10 - if it is not possible to replace the interface on the row, just first add another row (list=WAN, interface=wan2-100) and then remove (or just disable) the one with (list=WAN, interface=ether10). But again, this has nothing to do with the pinging of 192.168.9.1.

Wireshark will only show the situation on a single interface, so you’ll see that ping requests are leaving the PC and nothing comes back; that’s clear even without Wireshark. Sniffing on the 3011 the way I’ve suggested above shows you the whole path of the packet through the router, which is what we need.

frank333 · May 10, 2021, 1:01pm

in the interface list I succeeded ,

eth10 remains in the bridge

sindy · May 10, 2021, 1:02pm

That’s correct.

frank333 · May 10, 2021, 1:13pm

sindy · May 10, 2021, 1:51pm

Ah, hw=yes strikes again…

Please set hardware acceleration to no under /interface bridge port for ether10 and for the port to which you connect the PC, and try again. When hw=yes, some packets do not get captured on the Ethernet interface. I keep forgetting about that.

In any case, your sniff only shows pings sent by the 3011 itself once every 30 s, nothing from the PC, so it seems the pings didn’t make it to the 3011… can the PC ping e.g. 8.8.8.8?

If yes, running Wireshark directly at the PC might help after all.

frank333 · May 10, 2021, 2:05pm

sindy · May 10, 2021, 2:15pm

OK, still the same - the 3011 pings the LTE from wan2-100 and gets a response every 30 s, except that now with hw=no you can see also the ping request to leave tagged via ether10, not just the response to come in through there. So everything is fine regarding the VLAN setup.

As the ping requests from the PC aren’t visible, it’s not the 3011 that doesn’t let them through or diverts them to a wrong out-interface, there must be something wrong already at the PC itself.

Could it be that the PC has multiple Ethernet or wireless ports, or that some VPN is running on it?

Can you ping 192.168.9.2 (the 3011’s own address in 192.168.9.0/24) from the PC?

frank333 · May 10, 2021, 2:25pm

yes,and pings at 8.8.8 also work
f@ff:~$ ping 192.168.9.2
PING 192.168.9.2 (192.168.9.2) 56(84) bytes of data.
64 bytes from 192.168.9.2: icmp_seq=1 ttl=64 time=0.217 ms
64 bytes from 192.168.9.2: icmp_seq=2 ttl=64 time=0.199 ms
64 bytes from 192.168.9.2: icmp_seq=3 ttl=64 time=0.168 ms
64 bytes from 192.168.9.2: icmp_seq=4 ttl=64 time=0.188 ms
^C
— 192.168.9.2 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3053ms
rtt min/avg/max/mdev = 0.168/0.193/0.217/0.017 ms

sindy · May 10, 2021, 2:33pm

OK, so please show me the output of /tool sniffer quick ip-protocol=icmp ip-address=192.168.9.2 while pinging 192.168.9.2 from the PC.

And then Wireshark on the PC while pinging 192.168.9.1. It starts being crazy.