[Openswan Users] Forwrward decripted traffic with NETKEY

[Peter McGill]

> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net] 
> Sent: June 8, 2007 1:02 PM
> To: 'davorkk at hotmail.com'
> Cc: 'users at openswan.org'
> Subject: RE: [Openswan Users] Forwrward decripted traffic with NETKEY
> 
> > -----Original Message-----
> > Date: Fri, 08 Jun 2007 17:29:19 +0200
> > From: "davor krabse" <davorkk at hotmail.com>
> > Subject: [Openswan Users] Forwrward decripted traffic with NETKEY
> > To: users at openswan.org
> > 
> > I have the production server Debian Sarge,  running openswan 
> > 2.2.0-8 on 
> > 2.4.27 with kernel patch - klips. This ipsec implementation 
> has ipsec 
> > device, so I forward l2tp traffic from ipsec0 device to 
> > Windows 2003 Server 
> > that acts like l2tp server. I use DNAT:
> > 
> > iptables -t nat -A PREROUTING -i ipsec0 -p udp --dport 1701 
> > -j DNAT --to 
> > localWin2K3
> > 
> > The ipsec/l2tp configuration works well.
> > 
> > I have a new server now, running Debian Etch on 2.6.18.3 with 
> > openswan 
> > 2.4.6. I would like to use the native kernel ipsec 
> > implementation - NETKEY. 
> > As long as there is no ipsec device in NETKEY, I do not have 
> > a simple access 
> > to decripted l2tp traffic.
> > 
> > To solve the problem, some articles on the net suggest using 
> > iptables mark 
> > facility to mark packets that were entering INPUT chain in 
> > the encapsulated 
> > form (eg. ESP). As far as I understand, decrypted packets appear on 
> > INPUT/FORWARD firewall again, but in unencrypted form. I read 
> > that NETKEY 
> > decription preserves mark. So I changed above simple DNAT to:
> > 
> > iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 1
> > iptables -t nat -A PREROUTING -m mark --mark 1 -p udp --dport 
> > 1701 -j DNAT 
> > --to localWin2K3
> > 
> > Unfortunatelly there is no l2tp traffic DNATed to 
> > localWin2K3. Any ideas??
> > 
> > Davor
> 
> Looks good, do you get any errors when you input them?
> Is iptables mark enabled in your kernel?
> Is localWin2K3 a hostname or ip address?
> If hostname must be in /etc/hosts because iptables runs before dns.
> 
> Peter

Could also add a FORWARD allow rule, might do the trick.

iptables -t filter -A FORWARD -d localWin2K3 --dport 1701 -j ACCEPT
iptables -t filter -A FORWARD -s localWin2K3 --sport 1701 -j ACCEPT

Could try -I FORWARD instead of -A FORWARD to override any previous filter rules.

Peter