[Openswan Users] Fwd: Lost packets after DNAT

[George Adams]

 --- George Adams <georgebadams at yahoo.com.au> wrote: 
>  --- Paul Wouters <paul at xelerance.com> wrote: 
> > On Tue, 1 Mar 2005, George Adams wrote:
> > 
> > > ipsec0 is bound to eth1.
> > > 
> > > the sysctl.conf file has:
> > > 
> > > # Controls source route verification
> > > net.ipv4.conf.default.rp_filter = 1
> > > net.ipv4.conf.eth1.rp_filter=0
> > > 
> > > and 
> > > 
> > > # cat /proc/sys/net/ipv4/conf/eth1/rp_filter
> > > 0
> > > 
> > > should I disable default.rp_filter? 
> > 
> > Yes, because "ipsec0" is also a device that gets
> > packets from
> > "martian" sources. If you really want spoof
> > protection, just
> > add those to your firewall rules. rp_filter is
> just
> > too
> > stupid to use. 
> >  
> 
> Done. I'll get the client to test later since I dont
> have acess to the client end. 
> 

I got the client to test and it works up to the point
where the response is back at the VPN server. tcpdump
shows the responding UDP traffic on the internal
interface. while another tcpdump on ipsec0 shows
nothing going out. 

For example on ipsec0: 

18:02:31.530655 10.0.62.128.5432 > 192.168.2.137.5432:
 udp 12 (DF) [tos 0x48] 
18:02:58.476845 10.0.62.129.5432 > 192.168.2.137.5432:
 udp 12 (DF) [tos 0x48] 
18:03:03.512156 10.0.62.129.5432 > 192.168.2.137.5432:
 udp 12 (DF) [tos 0x48] 

please ignore the ip addr change. the client is
running WinCE which will change its ip address if it
cannot communicate with its server. 

on the internal eth0:

18:02:31.530766 10.0.62.128.5432 >
192.168.208.137.5432:  udp 12 (DF) [tos 0x48] 
18:02:31.540248 192.168.208.137.5432 >
10.0.62.128.5432:  udp 12
18:02:58.477048 10.0.62.129.5432 >
192.168.208.137.5432:  udp 12 (DF) [tos 0x48] 
18:02:58.495033 192.168.208.137.5432 >
10.0.62.129.5432:  udp 12
18:03:03.512274 10.0.62.129.5432 >
192.168.208.137.5432:  udp 12 (DF) [tos 0x48] 
18:03:03.521812 192.168.208.137.5432 >
10.0.62.129.5432:  udp 12

Now I would expect that the connection tracking of
iptables will allow the responses through. I have a
related/established rule on the top of the FORWARD
chain and nothing is logged as droppped. 

I've also added an SNAT rule to nat the new address
back to the old just in case the connection tracking
is not working but it has not helped.

Any suggestions?

> > > I recall having to disable eth1.rp_filter
> because
> > > IPSEC complains about it during startup.
> > 
> > Well, later versions just turn rp_filter off when
> > needed.
> >  
> > [ ipsec verify ]
> > 
> > That looks ok.
> >   
> > > I should mention that this is running on Redhat
> 8
> > with
> > > kernel version 2.4.20. We are currently testing
> > 
> > That should work fine.
> > 
> > > Openswan on RHEL 3es but in the meantime I need
> to
> > get
> > > this working.
> > 
> > That will be hell, since RHEL3 uses a hybrid
> 2.4/2.6
> > kernel,
> > and you won't be able to get KLIPS going, and the
> > NETKEY version
> 
> Not my choice really and quite annoyed about the
> lack
> of KLIPS, but some management feel better when they
> pay. :-)
> 
> > in RHEL3 kernels is just too broken last time I
> > checked.
> > 
> > Paul
> > 
> 
> The new setup Openswan+L2TP is being used with WINXP
> SP2 roadwarriors. So far I've been very happy with
> it.
> 
> Many thanks for your help.
> 
> George.
> 
> Find local movie times and trailers on Yahoo!
> Movies.
> http://au.movies.yahoo.com
>  

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com