Bug 146169 - ifup-ipsec doesn't set route with network-2-network config
ifup-ipsec doesn't set route with network-2-network config
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: 126907 (view as bug list)
Depends On:
Blocks: 156320 156322
  Show dependency treegraph
Reported: 2005-01-25 14:10 EST by Some One
Modified: 2014-03-16 22:52 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2005-607
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 11:46:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch against ifup-ipsec to add the correct route (881 bytes, patch)
2005-03-11 09:26 EST, Steve Hill
no flags Details | Diff
Patch for ifdown-ipsec (494 bytes, text/plain)
2005-03-11 09:28 EST, Steve Hill
no flags Details
Patch for ifdown-ipsec (494 bytes, patch)
2005-03-11 09:28 EST, Steve Hill
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:606 qe-ready SHIPPED_LIVE initscripts/hotplug bug fix update 2005-09-28 00:00:00 EDT
Red Hat Product Errata RHBA-2005:607 qe-ready SHIPPED_LIVE initscripts and hotplug bug fix update 2005-10-05 00:00:00 EDT

  None (edit)
Description Some One 2005-01-25 14:10:48 EST
Description of problem:
RTNETLINK error while ifup

Version-Release number of selected component (if applicable):
update 4

How reproducible:

Steps to Reproduce:
1. make ipsec device with redhat-config-network
2. run ifup ipsec0
3. route -n
4. you see no new routes
Actual results:
Network 2 Network VPN unusable

Expected results:
new route to remote network added to route -n list

Additional info:
similar to 140654, ifdown does propably fixin too
Comment 1 Bill Nottingham 2005-01-25 14:52:29 EST

*** This bug has been marked as a duplicate of 140654 ***
Comment 2 Bill Nottingham 2005-01-25 14:52:59 EST
Whoops, fat fingered it. Sorry.
Comment 3 Steven Whitehouse 2005-03-08 06:27:27 EST
It would appear that the problem here (which I've just come across) is
due to the route trying to use the DST as the nexthop. DST is the
remote ipsec gateway in this case and so this only works if it happens
to be on a locally connected network. Otherwise you get the error as

I've found the bug in FC3 and RHEL4 too. The route ought to look like
the following I think:

ip r a ${DSTNET} via ${NEXTHOP} src ${LOCALSRC}

Now I've also been reading the online RHEL4 docs which didn't appear
to match the initscripts and having filed a bug on that I wonder if
perhaps the docs are right and the scripts are what needs correcting?

The NEXTHOP could be generated automatically by running iproute2 to
discover the nexthop towards $DST I think. Caveats for dynamic routing
would apply though (not a problem in my case). As for the LOCALSRC,
thats more tricky and probably does need to be specified in the
config file to avoid confusion in the case of multiple addresses per
device I guess.
Comment 4 Steve Hill 2005-03-10 05:41:56 EST
Maybe a better solution is:

ip r a ${DSTNET} via ${LOCALSRC} src ${LOCALSRC}

(I know it's horrible, but it happens to work - bear with me here :)

The only thing the route is used for is setting the source address of
locally generated traffic - the gateway can actually be set to
anything on the local network since it is not used (the actual gateway
the traffic is sent through is of course determined after
encapsulation so the gateway on this route is meaningless).

Setting the gateway to the local machine itself is allowed since it is
within the local subnet, and since it doesn't reference any external
gateway it doesn't need to be fiddled by any dynamic routing which the
host might be doing.
Comment 5 Bill Nottingham 2005-03-10 18:10:55 EST
Actually, can you test without setting the route at all?
Comment 6 Some One 2005-03-10 19:53:30 EST
Sorry sirs,

I'm running production system with "hacked" initscripts. I'm paying 
for Enterprise Linux and I wait the solution and errata from you. 

Don't you Red Hat have test lab (eg virtual servers on VMware 
Workstation) for support issues like this ?-o

So unfortenately I can't do tests.
Comment 7 Steve Hill 2005-03-11 03:22:35 EST
If you don't set a route for the traffic with "src ${LOCALSRC}" then
traffic generated on the local machine gets the external IP address
set as the source since the routing table usually shows that this
traffic would go through the default route.  With the external IP
address set the traffic doesn't match the policy and goes out
unencrypted (and in the case where you are connecting RFC1918 networks
together over the internet the traffic won't make it to the
destination anyway since you're now sending unencapsulated traffic
from a public IP to an RFC1918 IP over the internet).
Comment 8 Some One 2005-03-11 03:30:13 EST
I followed Bugzilla entry for FC2/3. Here are quotes from 
bug "140654" maybe this helps one.

I've tested without the route between disparate networks, and it 
works for me; the key was turning off rp_filter.
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
on both systems and now, yes, it does work without the route present.
My comment:
RHEL3ES has also default rp_filter value of "1".
Comment 9 Steven Whitehouse 2005-03-11 04:16:59 EST
I agree with Steve Hill's comment above. Whether you need the route or
not will depend upon the addresses on the various interfaces at each
end of the link. There will be some cases in which you do not need it, 
but I think you do need it in the general case.

Setting the source address for the outgoing packet according to the
destination net is the important thing here. Then the SPD will match

I've actually initially worked around the problem by commenting out
the route adding in ifup-ipsec and then added the routes to a
route-ethX file. This is because ipsec interfaces don't apparently
allow the creation of route-ipsec0 (for example) files like other
interfaces. If route-ipsec0 could be used, then it might be best
just to put the route there, if its required rather than having it
as part of the ifup-ipsec script?

I then discovered another problem with what I was intending to do: it
is impossible with the current Linux ipsec tunnel implementation to
have several different tunnels from the a single source net to a
single destination net (SPD key is source net, destination net). So in
the end I solved the problem with point-to-point ipsec transport mode
plus ip_gre which does work nicely as you can then set a route with
multiple next hops via each GRE device.

Of course Red Hat is missing ifup-gre scripts, but I wrote my own,
only to find someone else had got there before me:
Comment 10 Steve Hill 2005-03-11 09:26:33 EST
Created attachment 111882 [details]
Patch against ifup-ipsec to add the correct route

The attached patch adds the route I proposed - seems to work ok for me.
Comment 11 Steve Hill 2005-03-11 09:28:44 EST
Created attachment 111883 [details]
Patch for ifdown-ipsec

This complements the above ifup-ipsec patch by removing the route correctly
Comment 12 Steve Hill 2005-03-11 09:28:52 EST
Created attachment 111884 [details]
Patch for ifdown-ipsec

This complements the above ifup-ipsec patch by removing the route correctly
Comment 13 Bill Nottingham 2005-03-28 15:48:48 EST
Adding a patch to CVS that does this, using the $SRCGW variable.

Should be in initscripts-7.93.14.EL/7.31.23.EL. This is probably likely to land
in  RHEL3 U6/RHEL 4 U2.
Comment 14 Bill Nottingham 2005-04-19 23:23:19 EDT
*** Bug 126907 has been marked as a duplicate of this bug. ***
Comment 15 Steve Hill 2005-04-21 06:54:58 EDT
Changes confirmed working.
Comment 17 Florian La Roche 2005-05-11 03:58:37 EDT
Comment 18 Aleksandar Milivojevic 2005-05-17 11:09:24 EDT
I've played with patched ifup-ipsec scripts, and there's one case where it
doesn't work.

I played with following configuration in ifup-vpn file:

Machine has two ethernet interfaces, eth0 connected to "local" network
(, and eth1 connected to firewall (which is then connected to
the rest of the network).


default gateway: (to the rest of network)

The proposed patch would set route to (DSTNET) to point to (eth0 interface).  Err...  wrong side.  Setting the route to
point to doesn't work either (correct side, interface local IP). 
Not sure exactly why, but there's probably some trivial explanation that escapes
me (not finished with my first morning coffe yet).  Setting the route to point
to (next hop) works.  As stated in comment #4, this route is used
only for setting correct src IP address, so this should be OK:

ip route add to $DSTNET via $SRCGW
Comment 19 Aleksandar Milivojevic 2005-05-17 11:29:35 EDT
Errr...  Forget about my previous comment.  It was kind of rushed and not
thinked over.  It made network-to-network traffic pass through (encrypted), but
traffic between VPN gateways (host-to-host) would go unencrypted.  Which is bad,
of course.  My problem lies elsewhere...
Comment 20 Bill Nottingham 2005-05-17 11:31:16 EDT
See bug 150682?
Comment 21 Aleksandar Milivojevic 2005-05-17 11:59:43 EDT
Bug 150682 is "font rendering artefacts with 1.0.1 at odd DPI"?  Typo, I guess ;-)
Comment 22 Bill Nottingham 2005-05-17 12:20:27 EDT
*sigh*. Bug 150862.
Comment 23 Aleksandar Milivojevic 2005-05-18 15:06:59 EDT
The 150862 and this bug depend on each other.  This is how I needed to modify
routefix patch to work with overlaping networks:

TUNSRC=`ip -o route get to $SRCNET | sed "s|.*src \([^ ]*\).*|\1|"`
TUNGW=`ip -o route get to $DSTNET`
if echo $TUNGW | grep -q '^[0-9].*via'; then
   TUNGW=`echo $TUNGW | sed "s|.*via \([^ ]*\).*|\1|"`
ip route add to $DSTNET via $TUNGW src $TUNSRC

For ifdown-ipsec, replace "add" with "delete" in ip route command.

Without this change, my log files would be full of "martians" (and of course,
kernel would drop all such packets).

I'll attach combined patch file under bug #150862 shortly (and mark my previous
4 attachments under that bug as obsolete).
Comment 24 Aleksandar Milivojevic 2005-05-18 15:59:51 EDT
BTW, thinking of it, maybe it would be better to change:



    TUNGW=`echo $TUNGW | sed "s|.*src \([^ ]*\).*|\1|"`

in the else statement (when DSTNET is directly connected network).  The route
would than point to the correct interface.  Otherwise, kernel might complain
about martians in some cases.  Or not?  Not sure, still drawing things in my head.
Comment 26 Bill Nottingham 2005-07-01 17:09:58 EDT
Fixed in 7.31.24.EL-1 for RHEL 3.
Comment 27 Bill Nottingham 2005-07-01 17:15:35 EDT
Fixed in 7.93.14.EL-1 for RHEL-4.
Comment 28 Aleksandar Milivojevic 2005-08-04 12:37:25 EDT
Is 7.93.14.EL-1 released?  What approach went into it?

I'm currently using ifup-ipsec patched to execute "ip route add to $DSTNET via
$TUNGW src $TUNSRC" (see my previous comments).  One problem I run into is that
xDSL interfaces will be brought up after IPSec "interfaces".  That means setting
the route will fail.

Regardless of the "route" problem, the correct order would be xDSL and than
IPSec anyhow (since later usually depends on former being up and running).
Comment 29 Bill Nottingham 2005-08-04 12:44:25 EDT
They're scheduled for RHEL 4 U2 and RHEL 3 U6.
Comment 30 Red Hat Bugzilla 2005-09-28 11:54:25 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 31 Red Hat Bugzilla 2005-10-05 11:46:03 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.