Score:0

Multiple Network Interface Not Working Properly

us flag

I have two network interfaces on my Linux CentOS. When I tried to access the web server from outside network via eth0 it works properly. But when I tried to access via eth1 it gives me time out.

Here is the route:

[root@fe fe]# ip route list
default via 192.168.10.1 dev eth0 proto dhcp metric 101
default via 192.168.18.1 dev eth1 proto dhcp metric 102
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.237 metric 101
192.168.18.0/24 dev eth1 proto kernel scope link src 192.168.18.14 metric 102

Here is the weird thing: When I change the metric for eth1 to 100, eth1 is working, but eth0 is timeout.

This is the ip a command produce

[fe@fe ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d2:ce:a3:6d:a2:f4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.237/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 416sec preferred_lft 416sec
    inet6 fe80::d0ce:a3ff:fe6d:a2f4/64 scope link noprefixroute
       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 8a:be:5d:40:8b:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.14/24 brd 192.168.18.255 scope global dynamic noprefixroute eth1
       valid_lft 3584sec preferred_lft 3584sec
    inet6 fe80::88be:5dff:fe40:8b34/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

I can confirm the ETH1 receive the request using tcpdump.

[root@fe fe]# tcpdump -i eth1 port 80
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:04:57.763317 IP 43.224.168.199.50770 > fe.lan.http: Flags [S], seq 2609591301, win 64240, options [mss 1412,nop,wscale 8,nop,nop,sackOK], length 0
22:04:57.764527 IP 43.224.168.199.50771 > fe.lan.http: Flags [S], seq 821872254, win 64240, options [mss 1412,nop,wscale 8,nop,nop,sackOK], length 0
22:04:58.021494 IP 43.224.168.199.50772 > fe.lan.http: Flags [S], seq 3220097528, win 64240, options [mss 1412,nop,wscale 8,nop,nop,sackOK], length 0
vidarlo avatar
ar flag
Why do you want two default routes?
in flag
This is multihoming and requires some special handling in regards to which way traffic should go out. You need to add IP rules and have different tables based on the source address.
us flag
Because both IP produced from different router. What should I do? Should I add the third router?
us flag
@NiKiZe ah, I see. I just don't know how to config the tables you mention. Btw, I only need to access eth0 from IP 192.168.3.0/24.
Score:0
us flag

The reason the packets are not forwarded correctly is because the server sends the response packets via other interface than they arrive from.

If you only need to use the other interface for one subnet, you should configure only that subnet traffic to be forwarded via eth0.

Steps you need to take:

  • Disable DHCP on eth0
  • Assign static IP address on eth0
  • Add route to 192.168.3.0/24 via 192.168.10.1

After these steps, your routing table should look something like this:

[root@fe fe]# ip route list
default via 192.168.18.1 dev eth1 proto dhcp metric 102
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.237 metric 101
192.168.18.0/24 dev eth1 proto kernel scope link src 192.168.18.14 metric 102
192.168.3.0/24 via 192.168.10.1 dev eth0 metric 101
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.