Les Mikesell wrote:
> On Fri, 2005-08-05 at 16:09, Aleksandar Milivojevic wrote:
>
>
>>Well, after some debugging, the problem seems to be that Netfilter is not
>>placing returning packets into establieshed state for direct connections
>>between VPN gateways (public addresses, those that should not go through GRE
>>tunnel, just IPSec encrypted). If I use private interface addresses of VPN
>>gateways (so that packets go through GRE tunnel, and then IPSec), things seem
>>to work OK. However, I still need to do some additional testing.
>>
>>Have you seen something like that before?
>
>
> One thing I've seen before is that if you have made an ip_conntrack
> entry for a connection before adding the route into the tunnel
> (e.g. a packet has already gone out the default route) the
> entry doesn't go away when you change the route. If there
> was NAT associated with the other interface, when the route
> changes, the nat entry stays and the packet goes over the
> private link but is source-natted to the other interface address
> and won't work. Does it make a difference if you connect to
> something that had not been connected before changing the
> route?
No, haven't tried that. However, the problematic packets are not the
ones going to tunnel. I had problems with packets that are not affected
by change of routing (those having external IP addresses). What I'll
try on Monday is using IPSec by itself (in transport mode), and GRE by
itself, and see if in any of those two cases I'll get the same problem
(might send question to Netfilter list too).
Just for the complete info. I'm not using NAT. Also, while
experimenting I was doing /etc/init.d/iptables restart, which would also
reload connection tracking module (effectively clearing all connection
tracking tables in kernel).
