Bypass routing for specific destination IP - question

[SriramScorp]

I would like to route all outgoing traffic to a specific cloud server via a single interface which is not the default gateway. As per this example, if eth0 is my default gateway and I want to route all traffic from and to 4.3.2.1 via eth1, how to tweak the routing?

[matttbe]

Hi,

I'm not sure to understand your question: do you have a schema or similar?

If you "just" need a specific route to 4.3.2.1 via eth1 instead of eth0, you can add a specific rule:

ip route add 4.3.2.1/32 via dev eth1

(but that's not linked to MPTCP)

[SriramScorp]

Adding such a route seem to work only when there is no policy routing table per WAN. Once MPTCP routing is created, the added route results in connectivity failure for the specific IP as no packets are sent through the selected interface. When I ping a remote IP (say 8.8.8.8), no ICMP packets are sent via either the selected interface (usb2) or default gateway (usb1).

root@raspi-mptcp:~# 
root@raspi-mptcp:~# ip -br a
usb1             UNKNOWN        192.168.42.140/24 fe80::e510:3e0:399a:6966/64 
usb2             UNKNOWN        192.168.42.193/24 fe80::10d9:7f16:1f4e:f466/64
root@raspi-mptcp:~# 
root@raspi-mptcp:~# ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.42.193 icmp_seq=1 Destination Host Unreachable
From 192.168.42.193 icmp_seq=2 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 39ms                                                   
pipe 2

root@raspi-mptcp:~# 
root@raspi-mptcp:~# tcpdump -i usb2 dst 8.8.8.8                                                           
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                                                  
listening on usb2, link-type EN10MB (Ethernet), capture size 262144 bytes                                                   
19:51:01.174656 ARP, Request who-has dns.google tell 192.168.42.193, length 28                                           
19:51:02.246330 ARP, Request who-has dns.google tell 192.168.42.193, length 28                                           
19:51:03.286315 ARP, Request who-has dns.google tell 192.168.42.193, length 28                                           
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@raspi-mptcp:~# 
root@raspi-mptcp:~# 

[matttbe]

I really don't know what you try to achieve with which setup.

You need to configure the routing with MPTCP because you need to make sure packets send from a specific IP are sent to the interface having this IP. In a normal setup, you have one IP and everything go through the same interface. With MPTCP, it is different so we need to add an IP rule (ip rule add from <second IP> table <X>) and an IP route (ip route add default via <next hop for second interface> dev <second iface> table <X>)

[SriramScorp]

While using glorytun for link aggregation, I'm trying to bypass the traffic to a specific IP to not flow through the glorytun server. OpenMPTCProuter seem to have a similar feature called omr-bypass. But the last time I checked, they use ipsets to manage routing. I'm trying to achieve the same without ipset.

[SriramScorp]

@matttbe Any idea if this is possible with policy routing alone?

[matttbe]

It is hard to tell without access to the setup. I guess you can probably mark packet that should/should not go through the tunnel and use this mark for the policy routing but I cannot tell. But it doesn't look like an MPTCP problem. Probably best to ask this question to network configuration specialist.