[Openswan Users] iproute2, 26sec

[Hans Fugal]

Pardon my bluntness, but this is absolutely broken. I didn't find any
discussions about it through google, but I'm open to reading what has
been said/done before.

I have a pretty simple setup.

falcon:
  - eth0: 166.70.37.149
  - eth1: 172.17.0.3

gwythaint:
  - eth0: 172.16.59.194
  - eth0, after NAT: 204.96.22.194

On falcon,
default via 166.70.4.82 dev ppp0

I set up ipsec.conf like so:

conn falcon-wencor
  left=falcon.fugal.net
  leftsrsasigkey=%cert 
  leftcert=falcon-cert.pem
  right=%defaultroute
  rightrsasigkey=%cert
  rightcert=gwythaint-cert.pem
  leftsubnet=172.17.0.0/16
  rightsubnet=172.16.59.0/24

This works fine, but routing isn't configured properly. _updown tries
to set up a bogus route (from falcon's perspective):
... _updown: doroute `ip route add 172.16.59.0/24 via 204.96.22.194 dev eth0
 ' failed (RTNETLINK answers: Network is unreachable)

The simplest correct route to create would be:
  ip route add 172.16.59.0/24 dev ppp0
Notice no via, and ppp0 which is the device of the default route.  In
addition, I would like to add "src 172.17.0.3". To do so would require
knowing which local IP is wanted, and there's no good way of doing
this that I know of in the config file (but I would like to see one).
There's the possibility of a parameter to leftupdown, and that works
if you're doing your own updown script.

If I change {left,right}nexthop I get strange behavior that I still
don't understand. It causes error messages like this:
cannot respond to IPsec SA request because no connection is known for
166.70.37.149:4500[C=US, O=fugal.net, CN=falcon.fugal.net,
E=hans at fugal.net]...204.96.22.194:15640[C=US, ST=Utah, L=Provo,
O=fugal.net, CN=Hans Fugal, E=hans at fugal.net]===172.16.59.194/32

>From the source of _updown I think setting nexthop would help the
routing situation, but I can't get that to work.

I'm not just complaining; I have suggestions and even some code. My
first suggestion is a way to specify in the config file that I don't
want to do routing. I can set up my routes once and not have to worry
about it. As it is, even when I do manually set the routes they get
deleted. (even though I have short-circuited doroute() in _updown,
apparently something else deletes the routes on restart?)

My second suggestion is to not try so hard and use a simpler route
command. I think this boils down to PLUTO_NEXT_HOP is always set now,
even though in the code it looks like it expects it not to be set
sometimes. So maybe some smarts to see if PLUTO_NEXT_HOP is a local
network that we can reach directly, or maybe just leaving out any via
clause altogether.

My third suggestion is some way in the config file to set
PLUTO_MY_SOURCEIP per connection. /etc/sysconfig/defaultsource, apart
from being in a distro-specific location, is pretty global.

This patch summarizes the latter two:

--- programs/_updown/_updown.ip2.in     2004-06-01 07:30:57.000000000 -0600
+++ /usr/lib/ipsec/_updown      2004-10-06 12:11:29.000000000 -0600
@@ -286,11 +286,21 @@
 doroute() {
        st=0
        parms="$PLUTO_PEER_CLIENT"
+
        parms2=
-       if [ -n "$PLUTO_NEXT_HOP" ]
+#      if [ -n "$PLUTO_NEXT_HOP" ]
+#      then
+#         parms2="via $PLUTO_NEXT_HOP"
+#      fi
+
+       nexthop_dev=`ip route get $PLUTO_NEXT_HOP|head -1|egrep -o "dev [^ ]+"`
+       if [ "dev $PLUTO_INTERFACE" != "$nexthop_dev" ]; 
        then
-          parms2="via $PLUTO_NEXT_HOP"
+          echo "doroute WARNING: \
+          PLUTO_INTERFACE doesn't match kernel's idea of how to get to \
+          PLUTO_NEXTHOP. Using PLUTO_INTERFACE"
        fi
+
        parms2="$parms2 dev $PLUTO_INTERFACE"
        parms3=
        if [ -n "$PLUTO_IPROUTETABLE" ] && [ "$PLUTO_IPROUTETABLE" != "main" ]
@@ -298,6 +308,8 @@
            parms3="table $PLUTO_IPROUTETABLE"
        fi
 
+       # Gee it would be nice to get this from the config file somehow, on a
+       # per-connection basis.
        if [ -z "$PLUTO_MY_SOURCEIP" ]
        then
            if [ -f /etc/sysconfig/defaultsource ]

PS I didn't submit this as a bug because it deserves discussion and to
be seen by the users (because they can use my patch immediately in
their own leftupdown script).

regards,
Hans
-- 
De gustibus non disputandum est.