<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>re: Status of KLIPS</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>> What's the status of KLIPS today? Is it still an activly developed project<BR>
> that you can rely on, or is it a dead, abandoned project?<BR>
><BR>
> Is there any Linux distribution, preferable firewall/router oriented that<BR>
> ships with a KLIPS enabled kernel?<BR>
><BR>
> I really, really miss the ipsecX interfaces from KLIPS on recent linux<BR>
> kernels with NETKEY, like beeing able to write simple iptables rules based<BR>
> in traffic comming in or going out on the ipsec interface, and beeing able<BR>
> to run tcpdump on the ipsec0 interface for troubleshooting.<BR>
><BR>
> >From a user and firewall admin perspective it was a so much better design<BR>
> to have virtual interfaces to work with.<BR>
><BR>
> Is using the policy module of iptables the de facto way of getting similar<BR>
> functionallity with NETKEY as you had with the ipsecX interfaces with<BR>
> KLIPS, or is there any other method to filter traffic based on whether it<BR>
> is comming from/going to an IPsec tunnel?<BR>
><BR>
> Br // Mathias<BR>
<BR>
I use centos linux 5.2 with NETKEY. I too used klips in the past. I periodically do test compiles to see how the fast moving 2.6 series works with klips.<BR>
I have found the best combo for klips to be centos-4.x with a compiled<BR>
kernel from Adrian Bunk's 2.6.16.x stable series. When I do this I use<BR>
2.4.13. I need to test this with 2.6.20 as I have read that 2.4.13 is<BR>
now retired from active development.<BR>
<BR>
<BR>
The way I do the rules for filtering in iptables for NETKEY with eth0 being my outside interface is as follows:<BR>
<BR>
iptables -t mangle -A PREROUTING -i eth0 -p 50 -j MARK --set-mark 0x9<BR>
iptables -t mangle -A PREROUTING -i eth0 -p 50 -j RETURN<BR>
iptables -t mangle -A PREROUTING -i eth0 -p udp --sport 500 --dport 500<BR>
-j MARK --set-mark 0x9<BR>
iptables -t mangle -A PREROUTING -i eth0 -p udp --sport 500 --dport 500<BR>
-j RETURN<BR>
iptables -A FORWARD -m mark --mark 0x9 -j ACCEPT<BR>
iptables -A INPUT -m mark --mark 0x9 -j ACCEPT<BR>
<BR>
If I am doing roaming clients with nat-t I add:<BR>
<BR>
iptables -t mangle -A PREROUTING -i eth0 -p udp --sport 500 --dport 4500<BR>
-j MARK --set-mark 0x9<BR>
iptables -t mangle -A PREROUTING -i eth0 -p udp --sport 500 --dport 4500<BR>
-j RETURN<BR>
<BR>
<BR>
My current understanding is the mark survives decryption, so the<BR>
decrypted packet still carry the 0x9 mark and are allowed. If this is<BR>
wrong I am sure Paul or someone will chime in.<BR>
<BR>
Chris Patch<BR>
</FONT>
</P>
</BODY>
</HTML>