[Openswan Users] Drooping of return packets.

[Paul Wouters]

On Thu, 20 Jan 2005, Vinod Chandran wrote:

>> That all depends on how you load and/or start your connections, and when
>> openswan starts.
>> 
>   >>>>> Currently when we boot up our box, we bring up the interfaces and 
> add specific routes for it.
>                Then IPSEC is started on all the interfaces, and then the 
> connections are brought up. Till here the
>                 routing table looks fine. Then when I ping from a node on 
> the LAN side, at certain instances,
>                 completely random, there are instances when the Kernel 
> Routing Cache shows an entry for the specific
>                 node with interface IPSEC0 instead of eth0 causing the ping 
> to fail. This decision is taken at random.

This is not a random decision.
If an ipsec tunnel is loaded (eg auto=add) then routing is caught using the ipsecX
interface. However, if the tunnel is not established yet, packets will be dropped.
This is to prevent packets meant for a tunnel to leak out in plaintext. Once an
ipsec tunnel is established, packets still go into the ipsecX interface, but now
are encrypted and then send further on the ethX interface again.
If you have auto=start, the same applies, since there wil be a time where the
connection has loaded, but the IPsec tunnel hasn't established yet.

>                 Now if I restart IPSEC, it starts pinging since the entry 
> now shows ETH0, instead of IPSEC0. Is this a

Yes, you have restarted, and the connectin has not loaded yet, so packets are not
caught. If you want your packets to not leak out in plaintext when Openswan is
down, add a firewall rule to prevent this.

>                 problem with how kernel routing cache learns, as if it was a 
> problem with the routing table, it should
>                 have occured everytime rebooting is done, which is not the 
> case.

Probablu because the time to establish the ipsec connection is slightly different
every reboot.

Paul