[Openswan Users] Tranport mode over multiple hops

[George Hadjichristofi]

Dear Paul,

I think that I may have not fully described my environment.
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.  

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? 

Thank you,
George


-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Paul Wouters
Sent: Thursday, December 15, 2005 1:57 PM
To: George Hadjichristofi
Cc: users at openswan.org
Subject: Re: [Openswan Users] Tranport mode over multiple hops


On Thu, 15 Dec 2005, George Hadjichristofi wrote:

> I am trying to establish an ipsec security association in transport 
> mode over multiple hops.
>
> I currently have this network configuration:
> G1(10.0.0.1)----G2(10.0.0.2)------G3(10.0.0.3)
> This configuration represents a small mesh/mobile ad hoc network.

If it is a nesh, it should be assigning things differently, or passing
things as a bridge. The way you've drawn it, it won't work, it's an
invalid network. 10.0.0.1 will arp for 10.0.0.3.

Paul
_______________________________________________
Users mailing list
Users at openswan.org http://lists.openswan.org/mailman/listinfo/users