[Openswan Users] Tranport mode over multiple hops
Paul Wouters
paul at xelerance.com
Fri Dec 16 15:23:15 CET 2005
On Fri, 16 Dec 2005, George Hadjichristofi wrote:
> I set up a mobile ad hoc network, which is running the OLSR routing
> protocol. Based on connectivity, OLSR sets the routing table such that
> G2 can forward packets for G1 and G3. e.g., on G1 the routing table
> entry is "10.0.0.3 10.0.0.2 ... eth0" (The links between the nodes are
> wireless.)
>
> After I establish the IPsec security association between G1 and G3, the
> route entry on G1 changes to "10.0.0.3 * eth0" meaning that the nodes
> are directly connected, which is not the case. Therefore G1 and G3 can
> not communicate with each other. If I restart the routing protocol, it
> restores the routing entry back to the previous one and everything is
> working. That is I can send encrypted traffic from G1 to G3.
Yes, in this case, KLIPS routing method really works against you, especially
with frequent routing changes. You are better of using NETKEY.
> I believe that Openswan incorrectly adds the route entry "10.0.0.3 *
> eth0" causing failure of connectivity. In order to further verify that
> this behavior does not originate from the built-in kernel IPsec I used
> the "setkey" tool. With setkey, the routing table entry is not modified
> and everything works fine.
>
> As you may imagine it is impractical to restart the routing protocol at
> every gateway to correct the routing table and enable secure traffic
> flow. Since I am using the built-in kernel IPsec with Openswan, the
> routing entries should not be modified. Right?
>
> How can I fix this problem?
This is indeed a bug. I believe it is time to change the _updown script
and split it in two versions. One for klips and one for netkey. There are
just too many routing issues we keep getting on netkey.
(patches are welcomed :)
Paul
More information about the Users
mailing list