So far i tried marking connections to a route mark but i believe i am making a mistake somewhere because as soon as i am selecting route mark on route list client’s connection to Internet is failing.
I have CRS125-24G-1S routerboard.
with firmware 6.41.4
with bootloader 3.33 for ar9344
I have 2 public IPs available from the ISP (which they work as solo)
I have divided switch’s ports to 2 segments:
2 Bridges as LAN1, LAN2
WAN1 is on Port 0
Physical ports from 1 to 13 is for LAN1
WAN2 is on Port 23
Physical ports from 14 to 23 is for LAN2
As you can see LAN1 clients currently connects to internet through NAT without route mark and it works OK. But I want clients go through their own WAN addresses
Rather place the full export here, there might be rules in firewall filter, etc that can also cause issues. Use export hide-sensitive in terminal window
Then also confirm if both WAN addresses are the same as I see you marked them the same in previous output, i.e. FFFFFFF
if two addresses you want to obfuscate differ, use different replacement patterns for them, otherwise information is lost
if the IP addresses of WAN 1 and WAN 2 are actualy from the same subnet and thus they really do use a common gateway IP, two routes with the same IP address as ****
gateway
will not cause any difference because both will use the same physical interface. If this is the case, you don’t need two routing tables (so no routing marks) and WAN interfaces; instead, you have to assign packet marks rather than route marks using
yes, I was waiting for confirmation also on the WAN gateway addresses.
To add, since there is so many topics re route marking, i just tested in a lab environment and found no issues, I used RoS 6.42.1 on all devices in the below config and got results I expected everytime without fail.
Reboot is definitely not necessary after any change. The effect of changes may become visible later (as an example, if an ssh session is already established and you add a rule preventing new ones from being established, the already established one doesn’t break but once you terminate it, a new one cannot be established).
So re-insert the configuration line which normally breaks it for the group of clients but with ****
disabled=yes
so that it wouldn’t break the clients, and post another export of the configuration with hide-sensitive but with distinctive patterns replacing the public addresses so that there is no ambiguity.
When you deal with several cases like this one every day, the context disappears from your head very quickly
In your case in particular, when sessions have established via one WAN and then you activate routing via another one, all those sessions break because the remote end does not accept packets for existing session to start arriving from another address all of a sudden. So until the clients start new sessions, you cannot say whether it works or not.
piton@debian:~$ ping 192.168.2.1 -I eth1
PING 192.168.2.1 (192.168.2.1) from 192.168.2.250 eth1: 56(84) bytes of data.
^C
--- 192.168.2.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2050ms
piton@debian:~$ ping 192.168.2.1 -I eth0
PING 192.168.2.1 (192.168.2.1) from 192.168.1.57 eth0: 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.673 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.428 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.399 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.521 ms
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.399/0.505/0.673/0.108 ms
piton@debian:~$
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e2:37:9c:2d:45:a6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.57/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::e037:9cff:fe2d:45a6/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether fa:6b:c4:5c:8d:6e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.250/24 brd 192.168.2.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::f86b:c4ff:fe5c:8d6e/64 scope link
valid_lft forever preferred_lft forever
I tested how ping will work and the result is confusing
Setup is like this
Linux Box with two NICs
eth0 is connected to LAN1
eth1 is connected to LAN2
both configured to get options from DHCP server
192.168.2.1 can not be pinged from eth1 interface (which its IP address is 192.168.2.250)
192.168.2.1 can be pinged from eth0 interface (which its IP address is 192.168.1.57)
Weird is at first place to test the two LANs using two network cards of same machine because in such case the issues of response routing on the remote end complicate the situation even more, but that’s another point and is not relevant here.
What happens here is that if you use routing marks to choose a routing table, you affect also routing between local subnets. As soon as a routing mark is assigned, only routes with that routing mark are taken into account for that packet. So if you have three routing tables as below,
So basically changing mangle rules to not use src-address but instead in-interface is sufficient to accomplish what i want to do, i am not certain but i may tried that out before.
C:\Users\Administrator>tracert google.com
Tracing route to google.com [216.58.212.46]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.2.1
2 1 ms <1 ms <1 ms XX . XX . XX . XX static.ttnet.com.tr [XX. XX XX XX]
3 <1 ms <1 ms <1 ms 10.11.0.1
4 5 ms 2 ms 3 ms 88.255.41.254.static.ttnet.com.tr [88.255.41.254]
5 1 ms <1 ms <1 ms 212.175.136.1.static.ttnet.com.tr [212.175.136.1]
6 9 ms 8 ms 9 ms 195.175.170.13.06-incesu-t2-2.26-tepebasi-t3-1.statik.turktelekom.com.tr [195.175.170.13]
7 31 ms 31 ms 31 ms 212.156.104.110.static.turktelekom.com.tr [212.156.104.110]
8 26 ms 26 ms 26 ms 74.125.52.6
9 32 ms 32 ms 32 ms 108.170.250.161
10 26 ms 26 ms 26 ms 216.239.54.5
11 26 ms 26 ms 26 ms sof02s18-in-f46.1e100.net [216.58.212.46]
Trace complete.
C:\Users\Administrator>
I quickly tested it and LAN2 client still can not ping 192.168.2.1 but can connect to Internet.
No, you haven’t got the point. It doesn’t matter what is the basis for assigning the routing mark, the trouble with local traffic is that there is nothing what would automatically route it properly despite the routing mark. So when we talk about traffic between LAN 1 and LAN 2, you must either prevent it from being route marked (and you cannot use out-interface for that because at the time of route marking, routing has not yet been done so the out-interface is not yet known, so you must use dst-address), or add routes for local traffic into the respective routing tables.
If you don’t mind that traffic between the LANs doesn’t pass through, you may do nothing at all, but then don’t be surprised that pings work in an unexpected way.
So connect the Windows PC to LAN1, the debian PC to LAN2, or vice versa, use route marking based on individual addresses of these two PCs as src-address in the marking rules so that you wouldn’t disturb the other customers’ work, and debug your route marking and routing tables on these two machines. Once it starts working the way you need, change the dst-address values in the route marking rules to subnet addresses and the new connections of customers’ PCs will work with route marking too.
