Assume you have a Linux system with more than one network interface card (NIC) — say eth0 and eth1. By default, administrators can define a single, default route (on eth0). However, if you receive traffic (i.e., ICMP pings) on eth1, the return traffic will go out eth0 by default.
This can be a bit of a problem — especially when the two NICs share the same parent network and you’re trying to preserve sane traffic flows. In a nutshell, this post will explain how you can ensure traffic going into eth0 goes out only on eth0, as well as enforce all traffic going into eth1 goes out only on eth1.
You’ve found the one post that actually explains this issue; your googling has paid off. You wouldn’t believe how many advanced Linux routing websites out there explain how to route everything including your kitchen sink — yet fail to clearly explain something as simple as this.
As always, we’ll explain by example. Assume the following:
eth0 - 10.10.70.38 netmask 255.255.255.0eth0's gateway is: 10.10.70.254eth1 - 192.168.7.126 netmask 255.255.255.0eth1's gateway is: 192.168.7.1
First, you’ll need to make sure your Linux kernel has support for “policy routing” enabled. (As a reference, I’m using a v2.6.13-gentoo-r5 kernel.)
During the kernel compilation process, you’ll want to:
cd /usr/src/linux
make menuconfig
Select "Networking --->"
Select "Networking options --->"
[*] TCP/IP networking
[*] IP: advanced router
Choose IP: FIB lookup algorithm (FIB_HASH)
[*] IP: policy routing
[*] IP: use netfilter MARK value as routing key
Next, you’ll want to download, compile, and install the iproute2 [1] utilities. (Most Linux distributions have binary packages for this utility.) Once installed, typing ip route show should bring up your system’s routing table. Type man ip for more information about this utility, in general.
Speaking of which, assume the system’s initial route configuration looks like this:
# netstat -anr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.10.70.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.7.1 0.0.0.0 UG 0 0 0 eth1
So, basically, the system is using eth1 as the default route. If anyone pings 192.168.7.126, then the response packets will properly go out eth1 to the upstream gateway of 192.168.7.1. But what about pinging 10.10.70.38? Sure, the incoming ICMP packets will properly arrive on eth0, but the outgoing response packets will be sent out via eth1! That’s bad.
Here’s how to fix this issue. Borrowing the method from a really sketchy website [2], you’ll first need to create a new policy routing table entry within the /etc/iproute2/rt_tables. Let’s call it table #1, named “admin” (for routing administrative traffic onto eth0).
# echo "1 admin" >> /etc/iproute2/rt_tables
Next, we’re going to set a couple of new entries within this “admin” table. Specifically, we’ll provide information about eth0’s local class-C subnet, along with eth0’s default gateway.
ip route add 10.10.70.0/24 dev eth0 src 10.10.70.38 table admin
ip route add default via 10.10.70.254 dev eth0 table admin
At this point, you’ve created a new, isolated routing table named “admin” that really isn’t used by the OS just yet. Why? Because we still need to create a rule referencing how the OS should use this table. For starters, type ip rule show to see your current policy routing ruleset. Here’s what an empty ruleset looks like:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Without going into all the boring details, each rule entry is evaluated in ascending order. The main gist is that your normal main routing table appears as entry 32766 in this list. (This would be the normal route table you’d see when you type netstat -anr.)
We’re now going to create two new rule entries, that will be evaluated before the main rule entry.
ip rule add from 10.10.70.38/32 table admin
ip rule add to 10.10.70.38/32 table admin
Typing ip rule show now shows the following policy routing rulesets:
0: from all lookup local
32764: from all to 10.10.70.38 lookup admin
32765: from 10.10.70.38 lookup admin
32766: from all lookup main
32767: from all lookup default
Rule 32764 specifies that for all traffic going to eth0’s IP, make sure to use the “admin” routing table, instead of the “main” one. Likewise, rule 32765 indicates that for all traffic originating from eth0’s IP, make sure to use the “admin” routing table as well. For all other packets, use the “main” routing table. In order to commit these changes, it’s a good idea to type ip route flush cache.
Congratulations! You’re system should now properly route traffic to these two different default gateways. For more than 2 NICs, repeat the table/rule creation process as necessary.
Please provide comments, if you find any errors or have corrections to this post. I don’t claim that this method will work for everyone; this information is designed primarily to preserve my sanity, when configuring routing on future multi-NIC Linux systems.
References:
[1] http://www.policyrouting.org
[2] http://www.linuxhorizon.ro/iproute2.html
62 Comments
What a fantastic article, you’ve saved my butt, I had my 2 nic system configured ok, but every reboot would change it, and voila my listening servers would nose dive. this works perfectly
This is just exactly what I have been looking for, and you are right googling has paid off. I was looking for something that solved this issue, and went straight to the point. Many articles written out there tends to touch on the issue but never really explains what’s happening or maybe it seems to them so simplistic, they overlook the point all together. I don’t know if they ever think about the novices reading their articles…. This one sure did it for me, thank you very much.
Great article indeed… but I’m in a situation where I need to be able to fail over to a different “default” gateway in case of the primary default gateway is unreachable. Lets say I have three upstream routers 10.0.0.1, 10.0.0.2, 10.0.0.3/24. Is there a way for me to inject all 3 IPs into a routing table as my “default” routes on a Linux host?
RE: Failover Default Routes
Here are some articles that describe what you’re looking for:
http://www.uwsg.iu.edu/hypermail/linux/net/0009.1/0027.html
http://www.linux.com/articles/113988
http://mailman.ds9a.nl/pipermail/lartc/2002q1/002667.html
OpenBSD also has a daemon called “hoststated” that provides this type of capability:
http://www.openbsd.org/cgi-bin/man.cgi?query=hoststated&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
Thank you very much for the links…
gc_timeout did the trick for me as the default is 5 min which is too long for a route to fail over.
just wondering if there is a kernel value to control how long a “” arp entry may stay in the arp cache…
#arp -a
hosta (100.100.100.1) at on eth0
not sure why the word “incomplete” did not show up in my previous post…
RE: ARP Cache Timeout
Try this link, for information about how to control how long entries stay in the ARP cache:
http://www.ussg.indiana.edu/hypermail/linux/net/0012.2/0035.html
great article
thanks to all who rights this article
Great article
Thanks to all who Wright this article
Thanks for this article. It helped me get past a roadblock in a project.
i’m actually kind of curious – the most common, default situation is where eth0 is the interface that packets are routed through — heck, that’s noted in the first sentence — so i’m wondering why you constructed your example with the reverse configuration – with eth1 as the default? i found it kind of confusing, in an otherwise most excellent article….
Sorry about the confusion; in my example, the Linux distribution I used in my example (Gentoo) seemed to always specify eth1 as the default route — when both eth0 and eth1 were present and active (and when automatic configurations were used).
Let me ask you this, in your Linux distribution, when you have both an eth0 and an eth1 on the system with active links for both — does your distribution automatically select eth0 as the default route? I’m guessing it’s pretty much random, as the standard defaults are to use DHCP for both eth0 and eth1, in which case, whichever interface gets the DHCP lease (first? or last?) will ultimately decide which default route actually gets used by the system.
I hope this explains where I was coming from.
oh, okay, that makes sense. i’m always running servers with fixed IP’s, so DHCP never enters into the picture.
for what i’m attempting, i actually found that going with bonded interfaces worked best – using a bond0 device and making both interfaces capable of “believing” that they’re the server’s IP, and the only path out. thus if one interface goes offline, traffic can still pass.
I have a slightly different requirement.
I have internet access both over WLAN and over DSL. I use the DSL for VoIP setup and WLAN for internet. But sometimes the WLAN or the DSL goes out of service. In this caseI want to use both the services – Internet and my VoIP setup over the either WLAN or DSL whichever is active.
How could I do this?
Thanks,
Amit
kahnoie@gmail.com
Hi Amit,
See my earlier comment about “Failover Default Routes”:
http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/#comment-10
– Darien
Hi,
Thank you for this helpfull article.
Your exemples are related to 2 NICs : eth0 and eth1. But, what if instead of physical eth0 and eth1, we have a bonding logical one’s like this :
bond0 : eth0 + eth1
bond1 : eth3 + eth4.
That is we have 4 NICS or a quad card in a server.
In that case, what will be the configation.
Tahnks,
Bras
Hi Bras,
Actually the configuration would be almost identical with the example, but just replace eth0 with ‘bond0′ and eth1 with ‘bond1′.
Linux treats ‘bond0′ and ‘bond1′ as physical NICs, so the rest of the networking subsystem will simply think that these are physical devices.
Hope that helps,
– Darien
Hi,
Many thanks for this wonderful Info !!!
how can I make this permanent, so that
when my server reboots, I will have the same ruling.
Where can table admin and IP ruling
mods be placed …
Thanks in advance…
Each Linux distribution is slightly different. Some distributions offer a way to save these configurations within a configuration file under /etc to be used upon reboot.
Other distributions require you to add the “echo” and “ip rule” commands into a script file that gets called as one of the last commands when the system boots up.
For example, on Ubuntu Linux, there is a script file called “/etc/rc.local” that you can add all the “echo” and “ip rule” commands into, that will apply these configurations upon complete server bootup.
However, please be aware that if you have other network services that require the multiple default routes to be set up BEFORE those services can successfully load (e.g., an automatic VPN/IPSec tunnel), then you’ll have to create an rc.d init script, similar to those found in the “/etc/init.d” directory.
The short answer:
- Try adding the commands to “/etc/rc.local”.
- If other services fail, then make a copy of a simple script in “/etc/init.d”; then edit that script to reflect the commands needed to be run at boot time; then register that script to be started upon bootup (“man update-rc.d”, for Ubuntu/Debian Linux).
Hope this helps,
– Darien
Hello,
This is a good article, but when you say : “However, if you receive traffic (i.e., ICMP pings) on eth1, the return traffic will go out eth0 by default.”, car you please explain or give examples where we will or can receive traffic on eth1 if we have eth0 as a gateway.
Thanks
Lasy
Sure,
Lasy, when you set a single default route, then that route is relevant for *all traffic outside your local subnet*.
Let’s say you have a public class-C subnet of 128.253.1.0/255.255.255.0 and eth0 is 128.253.1.1 while eth1 is 128.253.1.2 and your default route is through eth0.
Then, let’s say someone from a completely different subnet (from 128.5.1.1, for example) pings your ETH1 IP address (128.253.1.2). The ICMP request packets will arrive on eth1; however, when your system sends out the ICMP response packets, *because the destination is outside your local subnet*, these packets will go out on eth0, since that is your default route.
The point of the article is that if you have two or more network interfaces and have only one default *route* set on the OS, then *for all non-local-subnet traffic*, all outgoing packets will go out on the interface marked as the default route — unless you follow the steps listed in this article.
– Darien
I have a backup server that has 2 NIC’s. One NIC is on my Server VLAN 10.1.0.0/16 and the other is on my storage VLAN 10.240.1.0/24. What I would like to do is force the backup traffic coming in on the 10.1.0.0/16 NIC to then be routed out to the backup NAS on the 10.240.1.0/24 NIC. How cna this be done?
Thanks
Thanx 4 that! Everything now seems to work… NICE DONE!
Great article! Thank you very much for writing
)
At last! Thanks for writing this. While it didn’t save a me a lot of time I *already* wasted, it was the solution to my networking conundrum. You rock.
Thanks for this writeup! It saved me a lot of time!
That’s a very handy piece of writing, Darien ! Thanks for posting it.
I can’t find IP_ROUTE_FWMARK in the new kernel for marking the packets (I’m using 2.6.27) or by googling. Has it been removed ?
Any pointers would be great.
GB
Hi Ghostbuster,
Yes, IP_ROUTE_FWMARK was removed from linux v2.6.20 and later releases. See this link for details:
http://cateee.net/lkddb/web-lkddb/IP_ROUTE_FWMARK.html
Presumably, the feature still exists, but it’s probably named something else (or perhaps merged with some other feature).
Hope this helps,
– Darien
Hi Darien,
Thanks for that pointer.
I’m thinking it’s the MARK command in Netfilter these days.
http://www.linuxtopia.org/Linux_Firewall_iptables/x4368.html
I’ve done some qdisc stuff so hopefully it won’t be too alien.
GB
Okay, scrap that last comment
I’ll try this instead hoping the support is all handled by iproute2 these days:
http://www.physics.umd.edu/pnce/pcs-docs/Glue/linux-route-hack.html
GB
Kick-ass ! This fixed a problem I was having with an FTP server with two NICS. I could only get it to work with one default gateway at a time. Using what I found here, I created two additional entries, one for each NIC. Works perfectly now. I had to use a slight variation on the ip route statement (using CentOS) – it was: “ip route add 10.1.250.0/24 via 10.1.250.1 dev eth0 table inside” instead of dev eth0 src . Great article – thanks so much !!
This is a really good article that gets me 90% of where I need to go, I really appreciate it. I was wondering if you also know how to configure a system with 10 nics with addresses on the same subnet to send packets directly to the same gateway instead of passing them indirectly through the dfault route on the machine. So, for example, 10.0.0.2->10.0.0.1 and 10.0.0.3->10.0.0.1 instead of
10.0.0.2->10.0.0.1 and 10.0.0.3->10.0.0.2->10.0.0.1. (where 10.0.0.1 is the gateway for that subnet, and 10.0.0.2 is the address of the interface with the default local route.)
I see how your example works for addresses on different subnets, but not for my situation. I would appreciate any ideas!
Hi Howard,
Yes, I’m familiar with that problem. To be honest, this problem is solved at a different layer than routing. What you’re looking for is “Link Aggregation” (aka. making multiple NICs in your server act as one large NIC). There is an entire page dedicated to the concept, available here:
http://en.wikipedia.org/wiki/802.3ad
In order to get it to work, though, you’ll need to make sure your upstream switch/router supports the 802.3ad protocol (most recent managed switches do support it; however, if you have an unmanaged switch, probably not).
Hope this helps,
Darien
Hi,
Am a little lost. On which file do you put all those commands? Secondly, after you have done all the configurations as shown in your solution, what will be the output when you do netstat -rn. Your assistance is highly appreciated.
Hi Anderson,
There is no specific file, as all the commands I’ve listed are performed from the command line. If you’re looking to run these commands every time your OS boots, then you can put them all in /etc/rc.local (for Ubuntu Linux).
Second, ‘netstat -rn’ can’t show you “policy routes” properly. So even after you run the policy routing commands, it’s likely ‘netstat -rn’ will still show you the same thing before and after the policy routes are in place.
If you’re looking to verify that policy routes are working properly, run the “ip rule show” before and after setting up policy routes. If you want more detailed information, see the man pages for the “ip” command, by typing “man ip”.
– Darien
Hi Darien,
Thanks so much for your response. One more question. Should I include the respective gateways in each interface configuration files for my case ifcfcg-eth0 and ifcfcg-eth1? My OS is RedHat El5. My default gateway for eth0 I have defined it in /etc/sysconfig/network file. Where should I define the default gateway for eth1?
Hi Anderson,
You can define your eth1 gateway in the set of commands you enter into /etc/rc.local
The “ip rule” commands Listed in the article will properly configure your eth1 gateway, so you won’t need to define it within /etc/sysconfig/network
– Darien
What do you change if both NICs are on the same network segment, using the same gateway IP? I tried following the steps above but I was left with all traffic going out eth0 while some went in eth1.
Hi nobodyfamous,
If both NICs are on the same network segment, the policy routing isn’t going to help you. The problem has to do with Linux kernel’s TCP/IP stack employing short-circuit routing.
Specifically, this problem is solved at a different layer than routing. What you’re looking for is “Link Aggregation” (aka. making multiple NICs in your server act as one large NIC). There is an entire page dedicated to the concept, available here:
http://en.wikipedia.org/wiki/802.3ad
In order to get it to work, though, you’ll need to make sure your upstream switch/router supports the 802.3ad protocol (most recent managed switches do support it; however, if you have an unmanaged switch, probably not).
– Darien
Yeah, bonding was the initial goal, but we don’t have access to the switches in this case, so it had to be solved at the host level.
We were able to make it work following a modified form of your instructions, FWIW:
In this example, the gateway is 192.168.0.1 and the server’s IPs are 192.168.0.211 and 192.168.0.212 on eth0 and eth1 respectively:
printf “1\tuplink0\n” >> /etc/iproute2/rt_tables
printf “2\tuplink1\n” >> /etc/iproute2/rt_tables
ip route add 192.168.0.211/32 dev eth0 src 192.168.0.211 table uplink0
ip route add default via 192.168.0.1 dev eth0 table uplink0
ip rule add from 192.168.0.211/32 table uplink0
ip rule add to 192.168.0.211/32 table uplink0
ip route add 192.168.0.212/32 dev eth1 src 192.168.0.212 table uplink1
ip route add default via 192.168.0.1 dev eth1 table uplink1
ip rule add from 192.168.0.212/32 table uplink1
ip rule add to 192.168.0.212/32 table uplink1
By the way, in the second paragraph you say that the solution is applicable to cases where the two NICs are on the same network, that’s why I followed your lead on this.
This is extremely helpful. Thank you.
One question about routing in general, is there a way to have subnets share a common default gateway?
Hi Tekknogenius,
If we’re talking about two subnets sharing a common, physical gateway (such as a router), then yes, but that common gateway must have a valid IP address on each subnet. For example, assume you have two subnets:
192.168.0.0/24
192.168.1.0/24
You can then configure your router to have the IPs of:
192.168.0.254 and 192.168.1.254 for use by members of their respective subnets.
Bottom line is that the gateway must have an address in each subnet; otherwise, you would have to figure out some other way to reach the gateway’s IP address (e.g. static ARP entry if on the local LAN)
– Darien
Hi – i have another slightly different goal. My Linux box has an eth0 (connected via a default gw to the internet) and a on-demand ppp0 (gprs) connection. My goal is to programmatically create sockets via both interface at the same time. I think i am stuck setting up the correct routes for this – do you know how to handle this issue?
Hi Johnny,
See my earlier comment as I’ve already addressed this issue:
http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/#comment-10
– Darien
Thanks for your quick reply. I’m not sure failover routing is the correct issue here, as both routes should be up all the time. My app decides on various criteria which connection should be used. I had read som article, whiches in short says: What goes out on one device, should comme in on that again. Is this the right idea? And how can I realize that?
Hi Johnny,
Okay, thanks for the clarification. I had assumed when you mentioned ‘on-demand’, that you somehow wanted to switch from eth0 to ppp0 when eth0 failed. Instead, you want both eth0 and ppp0 alive all the time.
In that case, just replaced ‘eth1′ with ‘ppp0′ in the example and you can still use policy routing to accomplish what you’re looking for.
The real challenge, is if ppp0’s network configuration changes constantly. If the IP address, subnet, and route of ppp0 constantly changes, then you need to somehow have logic to detect when these changes occur and update your policy routes accordingly.
In that case, you’ll probably want to research DHCP notification code. Depending on your Linux distribution, there are scripts which execute when your network changes, which you could use to also update your corresponding policy routes.
– Darien
Great article. This is so simple, yet so hard to find the information. Thanks a lot
Hey,
Great article, helped me loads compared to the other sites were they just skimm abit on the top.
Thou, having problem adapting it to my setup.
I currently have 2 nic’s on my server that is acting as router/gateway.
1 of the physical nic’s has 5 virtuell interfaces (g1-5), g1 goes to the router itself as it also goes as a webserver. The rest are nated straight to nic2(which has no virtuell interfaces). As i have 4 computer, g2-5 are nated 1:1 towards the inside local ip:s 10.10.1.X.
I have a simple iptables rule to fix the NAT part, and i had it working “sortoff” since everything was working except that i could not reach the servers/pc’s from the outside, they could only talk from the inside->out (torrents etc works flawlessly thou).
Any hints? If you got a mail or something it would be great to get some advice..
Hi DevizioN,
It sounds like you have one-way NAT working and you want bi-directional NAT. From your post, it sounds like g1 goes to the router, as well as nic2 goes directly to the router … is that correct?
Regardless, it sounds like setting up multiple default routes correctly will NOT fix your NAT problem… I would recommend you try and fix your NAT problem first, and then setup the multiple default routes.
To be very specific, with your current NAT configuration, try configuring your server with only ONE upstream gateway and fix your NAT so that it’s working in both directions (insideout).
Once you get a single route working, then add your second upstream gateway. If your bi-directional NAT breaks and no longer works correctly, then let me know and we can troubleshoot further (as configuring multiple default routes may help you).
The general approach is: reduce the complexity of your configuration, verify each piece works first (e.g., NATing, virtual interfaces), and THEN verify the total configuration works. Otherwise, it can be a nightmare to troubleshoot multiple unknown pieces at the same time.
– Darien
Hi, if i have 2 or more subnets
example
10.10.70.0/24
10.10.71.0/24
ip rules add and from are with /32 or /24?
example
ip rule add from 10.10.70.38/32 table admin
ip rule add to 10.10.70.38/32 table admin
ip rule add from 10.10.71.38/32 table admin2
ip rule add to 10.10.71.38/32 table admin2
or
ip rule add from 10.10.70.38/24 table admin
ip rule add to 10.10.70.38/24 table admin
ip rule add from 10.10.71.38/24 table admin2
ip rule add to 10.10.71.38/24 table admin2
I don’t hunderstand why you use all 32 bits.
Thanks
Excellent Post!
I have followed the various bonding solutions available on Linux since I was doing load balancing work in the late 90’s but have never found anything that delivers on bonding two links to maximize bandwidth utilization.
I have a FIOS and Cable link that I’d been trying with bonding modes 5,6 on with various 3com 509’s and netgear 100mbit nics, after following your references here to Astro Shapes pages (also very informative). mii-tool seems to work fine with the nics.. but can’t get them to attach correctly for ifenslave
Given I’m interested in maximizing traffic on the links I wonder if anyone has rules that will monitor and direct traffic based on load on the individual nics?
Thanks
Thanks for writing a very useful article and subsequently answering so many questions. Here’s another
Supposing you have one or more aliases on the public interface (e.g., eth0:0) would you repeat all of the above steps, substituting eth0:0 for eth0?
Yes. Using eth0:0 should work.
Thanks for a great article. This looks like kinda what I need. However, my situation is a bit different (aren’t they all
). Anyway, I am basically, trying to setup openVPN on my Ubuntu 8.10 server. I got 2 NICs in my server. eth0 and eth1. eth0 is the external NIC while eth1 is the internal one (the LAN. eth0 is the default route. VPN connects through eth0 and I can ping my server and I can ping eth1, however I can’t ping anything behind eth1 (which is my local LAN). From the server console itself I can ping my internal LAN. I think the problem lies with traffice coming via eth0 and since the default route is eth0 it only goes through eth0. So if I ping anything which is behind eth1 it is routed via eth0 and not eth1. Is it possible to route all VPN traffic meant for eth1 through eth1 even though it’s not the default route?
Does this make any sense or am I making you guys as confused as myself?
Thanks for your help in advance.
Hi Mazzer,
1) As a sanity check, are you able to ping your eth1 network if you TURN OFF your VPN? I just want to make sure that the problem isn’t more fundamental.
2) On your server, once you have your VPN setup, you actually have THREE different interfaces: eth0, eth1, and (probably something like vpn0 — check your ‘ifconfig -a’ for details). Essentially, you have a third ‘virtual’ interface, representing the effective IP address of your server, once connected on the *inside* of your VPN network.
Here’s what I need to know:
- The IP address and netmask of your eth1 network.
- The IP address and netmask of your *vpn0* network (see above for what I mean).
Specifically, I believe that perhaps your eth1 network and your vpn0 network may have conflicting IP addressing, which is causing you to lose connectivity to your eth1 network once a VPN is established. However, I need more information in order to accurately say that this is the problem.
– Darien
I used the same kinda configuring (but created two tables instead of one) one per interface. This makes sure i get the response to through the right interface.
# Assign IP address on the interfaces eth0 and eth1
ip route add 10.1.0.0 dev eth0 src 10.1.0.250
ip route add 10.0.0.0 dev eth1 src 10.0.0.250
# IP route and default gateway for eth0 in the table 100
ip route add 10.1.0.0 dev eth0 src 10.1.0.250 table 100
ip route add default via 10.1.0.1 table 100
# IP route and default gateway for eth1 in the table 101
ip route add 10.0.0.0 dev eth1 src 10.0.0.250 table 101
ip route add default via 10.0.0.1 table 101
# Assign the rule to corresponding particular table
ip rule add from 10.1.0.250 table 100
ip rule add from 10.0.0.250 table 101
ip route flush cache
Now, i can ping the box to the corresponding box from behind the
gateway. Everything works fine according to my requirement.
Now if i use the ping utility (from the box) with a destination address not in 10.1.X.X or in 10.0.X.X network using both the interfaces (or the
ip-address) it works
ping -I eth0 some-address (works)
ping -I eth1 some-address (works)
ping some-address (not working) with “network is unreachable” as the error
Now this force me to use the default route on the main table which i
thought was not neccessary using below command
ip route add default via 10.1.0.1.
Since with out any interface or ip-address explicity given, ping
should have chosen the source ip-address as either 10.1.0.250 or
10.0.0.250. If so , rule should have hit in routing table 100 or table
101. But just wondering why it is hiting the main routing table. This
forces me to have a two gateway programming option for each interface
and another default gateway to select among two. Not sure why..
Also how do we use the same concept in the DHCP enabled network. DHCP client running on both the interfaces. DHCP clients always deals with the main routing table (instead of the custom created routing table).
Hi Darien,
Thank you for your quick reply. I was away from my computer for a while so couldn’t reply.
As per your questions, I’ll answer the ones I can right now.
1) I can ping eth1.
2) I know what you mean about the 3rd virtual interface. Sorry for not providing more information. I do have one and it’s a tun interface (tun0). I’m using routing and not bridging.
The IP address of eth1 is 10.10.2.102, netmask is 255.255.255.0 so thats the 10.10.2.0 subnet.
The details about tun0 I’ll get for you when I go home tonight.
I think the problem lies between the virtual Interface and eth1. From the VPN server I can ping both eth1 and eth0 and everything behind those interface. I can ping everything behind the eth1 subnet (internal network) and I can ping everyhting behind the eth0 subnet (the internet). When I’m connect via VPN to the server. I can ping both eth0 and eth1 but can’t ping anything behind eth1. Once connected via VPN, I can SSH into the VPN server (through the VPN connection) and one connected to the server console. I can ping everything behind eth1. I guess thats no surprise as I’m am then doing the pinging from the console. So as I said, I think the problem lies with the virtual interface having the default route of eth0 and so the pings arte going through eth0 even though they meant for eth1.
Phew, I can’t believe I wrote all that down
. Thanks for your help though.
Also Just so you know, I’m using OpenVPN as my VPN server and I’ve setup the redirect gateway option as well.
Got the details for the tun0 interface.
IP Address: 10.30.2.6
Subnet Mask: 255.255.255.252
Default Gateway: 10.30.2.5
DHCP Server: 10.30.2.5
DNS Servers: 10.10.2.11
The 10.10.2.0 subnet is the internal eth1 network so looks like the VPN server is pushing the DNS server to the client correctly.
When she goes to check on her, Batwoman reveals that she now obeys Darkseid as well, and starts to recite the Equation. ,
3 Trackbacks/Pingbacks
[...] Tästä ohjeesta soveltaen väänsin sitten iproute.sh nimisen scriptin joka sisältää seuraavaa. #!/bin/sh [...]
[...] Configuring Multiple Default Routes in Linux « Darien Kindlund’s Blog (tags: linux network networking routing gateway howto IP iptables policy) [...]
[...] [...]