Hello,
I wanted to setup routing certain traffic (http/s) out via a second (faster) interface, like described in the following docs (may not post urls):
linux-ip.net /html/adv-multi-internet.html
thegeekstuff.com /2014/08/add-route-ip-command/
I already had this working years ago on another server, but now it wont work correctly.
I have a second routing-table with a default route to the second interface.
I fwmark the http(s) traffic and set a rule that this traffic should use the special routing table.
And indeed the http traffic goes out via eth2 with the right src and destination, as I can see with tcpdump. A syn package [S]goes out - and a reply [S.] comes back in, to the right src ip / port. The firewall is completely open for input over the interface.
BUT, my host does not react to the incoming package [S.]. It does not continue with [.] (what would complete the three-way-handshake I guess, like I can see on other connections over the main interface). Instead after 1s it retries syn [S]and the remote host multiple times repeats its [S.] packages.
So what in all the world is going on? Why does the host's networking not react to the [S.] reply from the target? It's coming in, but not processed..
So strange!? Any relevant changes in Linux (Ubuntu 12.4 LTS) networking since I had such a setup running 5-8 years ago?
[The setup DOES work for traffic coming from outside over that interface, see from rule below!]
Thanks for any help / ideas!
-----------
root@mail:~# ip route show table backupline
default via 192.168.11.1 dev eth2
192.168.11.0/24 dev eth2 scope link src 192.168.11.2
root@mail:~# ip rule show
0: from all lookup local
32764: from 192.168.11.0/24 lookup backupline
32765: from all fwmark 0x2 lookup backupline
32766: from all lookup main
32767: from all lookup default
FW:
Chain INPUT (policy DROP 2275 packets, 156K bytes)
pkts bytes target prot opt in out source destination
57194 8286K ACCEPT all -- eth2 any anywhere anywhere
tcpdump:
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
16:39:17.804014 IP 192.168.11.2.55082 > matar.ispgateway.de.http: Flags , seq 272158038, win 14600, options [mss 1460,sackOK,TS val 3849200035 ecr 0,nop,wscale 7], length 0
16:39:17.823292 IP matar.ispgateway.de.http > 192.168.11.2.55082: Flags [S.], seq 1589811596, ack 272158039, win 5792, options [mss 1460,sackOK,TS val 3505823144 ecr 3849200035,nop,wscale 7], length 0
16:39:18.802418 IP 192.168.11.2.55082 > matar.ispgateway.de.http: Flags , seq 272158038, win 14600, options [mss 1460,sackOK,TS val 3849200285 ecr 0,nop,wscale 7], length 0
16:39:18.818238 IP matar.ispgateway.de.http > 192.168.11.2.55082: Flags [S.], seq 1589811596, ack 272158039, win 5792, options [mss 1460,sackOK,TS val 3505823243 ecr 3849200035,nop,wscale 7], length 0
16:39:20.806390 IP 192.168.11.2.55082 > matar.ispgateway.de.http: Flags , seq 272158038, win 14600, options [mss 1460,sackOK,TS val 3849200786 ecr 0,nop,wscale 7], length 0
16:39:20.823308 IP matar.ispgateway.de.http > 192.168.11.2.55082: Flags [S.], seq 1589811596, ack 272158039, win 5792, options [mss 1460,sackOK,TS val 3505823444 ecr 3849200035,nop,wscale 7], length 0
16:39:21.428241 IP matar.ispgateway.de.http > 192.168.11.2.55082: Flags [S.], seq 1589811596, ack 272158039, win 5792, options [mss 1460,sackOK,TS val 3505823505 ecr 3849200035,nop,wscale 7], length 0