[Openswan dev] Odd connectivity issue

[Kevan Benson]

I'm posting this to both users and dev, because I'm not quite sure at this 
point where the problem lies, but it seems that it might be sufficiently high 
level enough that a code chane might be required if it is indeed a bug.

I have an issue with some end hosts behind openswan ipsec boxes with a tunnel 
being unable to communicate in certain instances.  In these instances, the 
hosts in question can contact all other hosts on both ends of the tunnel, 
just not eachother, where there was no problem beforehand.

Site A has a dedicated T1, site B has a somewhat spotty DSL connection.  There 
is an Active Directory Server at site A that serves clients at both site A 
and site B.  Occasionally a host at site B that is normally in frequent 
contact with the ADS will be unable to access it.  No traffic whatsoever will 
pass between the boxes, either direction, yet the hosts can still contact 
other machines on both networks.  A tcpdump of the real interface and the 
ipsec interface on both sides shows information passing throguh the real 
interface to the ipsec interface from the originating side, but no traffic is 
winessed on the other end.  This seems to happen more frequently with hosts 
that are left on over night, and are connected and possibly passing traffic 
when the spotty DSL connection goes down.

Downing the tunnel and bringing it back up on either or both of the ipsec 
boxes does not solve the problem, but a service ipsec restart at site B will 
solve the issues, doing a restart of the ipsec service at site A only hasn't 
been tried yet.

The machines are both Via CV860A's running Mandrake 10.1 with a custom 
compiled 2.4.29 kernel.  Openswan is compiled from source and is version 
2.3.0 with the natt patch.

Site A is running the single iptables rule:
iptables -A POSTROUTING -s 192.168.200.0/255.255.255.0 -d ! 
192.168.0.0/255.255.0.0 -j MASQUERADE

Site B is running the single iptables rule:
iptables -A POSTROUTING -s 192.168.210.0/255.255.255.0 -d ! 
192.168.0.0/255.255.0.0 -j MASQUERADE

I would gladly provide any more info requested from normal or degraded 
operation; tcpdumps, dumps of /prc/net/ipsec/*, just let me know what's 
needed.

-Kevan Benson