Description of problem: RTNETLINK error while ifup Version-Release number of selected component (if applicable): update 4 How reproducible: allways 140654 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: RTNETLINK error 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
*** This bug has been marked as a duplicate of 140654 ***
Whoops, fat fingered it. Sorry.
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 reported. 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.
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.
Actually, can you test without setting the route at all?
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.
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).
I followed Bugzilla entry for FC2/3. Here are quotes from bug "140654" maybe this helps one. ---quote1 I've tested without the route between disparate networks, and it works for me; the key was turning off rp_filter. ---quote2 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".
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 correctly. 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145464
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.
Created attachment 111883 [details] Patch for ifdown-ipsec This complements the above ifup-ipsec patch by removing the route correctly
Created attachment 111884 [details] Patch for ifdown-ipsec This complements the above ifup-ipsec patch by removing the route correctly
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.
*** Bug 126907 has been marked as a duplicate of this bug. ***
Changes confirmed working.
ack
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: DSTGW=192.168.120.132 SRCGW=192.168.252.1 DSTNET=192.168.0.0/16 SRCNET=192.168.252.128/25 DST=192.168.120.165 Machine has two ethernet interfaces, eth0 connected to "local" network (192.168.252.128/25), and eth1 connected to firewall (which is then connected to the rest of the network). eth0: 192.168.252.129/25 eth1: 192.168.252.2/25 default gateway: 192.168.252.1 (to the rest of 192.168.0.0 network) The proposed patch would set route to 192.168.0.0/16 (DSTNET) to point to 192.168.252.129 (eth0 interface). Err... wrong side. Setting the route to point to 192.168.252.2 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 192.168.252.1 (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
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...
See bug 150682?
Bug 150682 is "font rendering artefacts with 1.0.1 at odd DPI"? Typo, I guess ;-)
*sigh*. Bug 150862.
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|"` else TUNGW=$TUNSRC fi 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).
BTW, thinking of it, maybe it would be better to change: TUNGW=$TUNSRC into: 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.
Fixed in 7.31.24.EL-1 for RHEL 3.
Fixed in 7.93.14.EL-1 for RHEL-4.
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).
They're scheduled for RHEL 4 U2 and RHEL 3 U6.
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. http://rhn.redhat.com/errata/RHBA-2005-606.html
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. http://rhn.redhat.com/errata/RHBA-2005-607.html