Ipsec/l2tp

Ipsec/l2tp

[Eray Aslan]

>> Haven't worked much with IPSec (at least not over firewall).  Are you
>> sure that IPSec packets will go through Netfilter twice (once encrypted,
>> and than once again unencrypted)?
>
>They do.   This makes it easy to filter the packet types you want to allow 
>through the tunnel, rather than having a VPN which passes just everything.
>
>Regards,
>
>Antony.

Hi,

I am having problems in setting up the following (setup is similar to what is described at http://koeppe-net.de/l2tp-howto.txt )

WinXP (VPN Client)
|
|(ipsec/l2tp)
|
Firewall (linux 2.6.6 iptables 1.2.9)
|
|(l2tp)
|
Win2K3 (VPN Server)

Basically, the client should connect to the firewall with ipsec/l2tp.  At the firewall, the incoming encrypted packets from the VPN clients should be unencrypted and sent to the VPN Server.  However, I am confused about which tables the packets go through both in their first and second rounds. My guess is that I should

For the encrypted pockets coming in from the VPN Client:
Mark the encrypted packets in mangle/prerouting
Accept the marked packets in the filter/input
DNAT (to VPN Server) the marked packets in nat/output
Accept the marked packets in filter/output

Any comments? Or better yet, can anyone give me a list of tables an ipsec packet goes through in the 2 rounds it makes in netfilter? What is meant by "IPSec packets will go through Netfilter twice (once encrypted, and than once again unencrypted)" ?  Does the same packet hit mangle/prerouting, for example, twice (first encrypted and then unencrypted)?  Also, how about the other way around (from VPN Server to VPN Client)?

Any comments / suggestions on the setup are also welcome.  I'd rather not use pptp if I can help it.

Thanks
Eray Aslan

Re: Ipsec/l2tp

[Antony Stone]

On Saturday 03 July 2004 11:25 am, Eray Aslan wrote:

> >> Haven't worked much with IPSec (at least not over firewall).  Are you
> >> sure that IPSec packets will go through Netfilter twice (once encrypted,
> >> and than once again unencrypted)?
> >
> >They do.   This makes it easy to filter the packet types you want to allow
> >through the tunnel, rather than having a VPN which passes just everything.
> >
> >Regards,
> >
> >Antony.
>
> Hi,
>
> I am having problems in setting up the following (setup is similar to what
> is described at http://koeppe-net.de/l2tp-howto.txt )
>
> WinXP (VPN Client)
>   |  (ipsec/l2tp)
> Firewall (linux 2.6.6 iptables 1.2.9)
>   |  (l2tp)
> Win2K3 (VPN Server)
>
> Basically, the client should connect to the firewall with ipsec/l2tp.  At
> the firewall, the incoming encrypted packets from the VPN clients should be
> unencrypted and sent to the VPN Server.  However, I am confused about which
> tables the packets go through both in their first and second rounds.
>
> What is meant by "IPSec packets will go through Netfilter twice (once
> encrypted, and than once again unencrypted)" ?

I wrote the above comment, and I was specifically referring to FreeS/WAN / 
OpenS/WAN and the Linux 2.4 kernel series at the time.   Things are different 
in the 2.6 kernel because of the inbuilt IPsec implementation.

I'll explain how things work in the 2.4 kernel for completeness, however 
you'll have to ask someone else about what happens with 2.6, since I haven't 
played with the IPsec system in that yet.   I do know that it's much more 
difficult to get to filter the unencrypted packets.

Firstly, encrypted packets coming in to the Security Gateway for forwarding:
1. Encrypted packet arrives at SG and enters PREROUTING, then INPUT chain 
(because it's addressed to the SG itself)
2. Encrypted packet traverses INPUT and goes to local klips process for 
decryption
3. Decrypted packet appears on ipsec0 pseudo-interface and enters PREROUTING, 
then FORWARD chain (because the decrypted contents are now addressed to the 
end client machine)
4. FORWARDing rules can filter on normal TCP/UDP etc protocols and port 
numbers, and the input interface is ipsec0, so these packets can be 
distinguished from any coming in on eth0 etc.
5. Decrypted packet traverses POSTROUTING and leaves SG for the client.

Secondly, plaintext packets coming in to the Security Gateway for encryption:
1. Unencrypted packet enters PREROUTING and FORWARD (because it's addressed to 
the remote client on the other end of the VPN)
2. FORWARDing rules can filter on normal TCP/UDP etc protocols and port 
numbers; the output interface is ipsec0.
3. Unencrypted packet traverses POSTROUTING and goes to ipsec0 
pseudo-interface.
4. Klips process picks up packet from ipsec0, encrypts it, and generates new 
encrypted packet from a local process.
5. Encrypted packet goes through OUTPUT chain (because it's been generated on 
the local machine), then POSTROUTING and leaves through eth0, addressed to 
the remote SG.

> Any comments / suggestions on the setup are also welcome.  I'd rather not
> use pptp if I can help it.

Good man :)

I hope someone else here can now fill in some useful details for you, given 
that you're using 2.6.6

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Ipsec/l2tp

[Primero]

>
> I hope someone else here can now fill in some useful details for you,  
> given
> that you're using 2.6.6
>
> Regards,
>
> Antony.
>

I'm not an expert, but AFAIK and because it works using this way i think  
that in 2.6 the process is very similar.

In 2.6 ipsec imlementation there is no Virtual interface, like ipsec0 or  
everything else, but the packets both encrypted and unencrypted come from  
the same interface , in expample eth0. They traverse netfilter two times,  
like in 2.4 , they get the first time to the INPUT chain, if accepted they  
traverse netfilter again in the normal process.

The reason i mark my packets at the STEP 1 when they come in encrypted is  
because i needed a way to identify packets that arrived ENCRYPTED, get  
decrypted and acceppted by ipsec and that are traversing the netfilter for  
the second time.
This way i can be sure that i handle only packets that have been accepted  
by ipsec and i can feel good :)
  for example, i use ipsec fot my WIFI lan and i have this kind of rules:

1) MANGLE/PREROUTING for packets arriving in esp protocol

iptables -t mangle -a PREROUTING -s $Y_WIFI_HOSTS -i $MY_WIFI_INTERFACE -p  
esp -j MARK --set-mark 10

2) INPUT for packets arriving in esp protocol

iptables -A INPUT -p esp -j ACCEPT

now IPSEC will authenticate and eventually accept the packets

3) INPUT and FORWARD for previously athenticated packets

iptables -A FORWARD -m --mark 10 -j MY_FORWARD_CHAIN
iptables -A INPUT -m --mark 10 -j MY_INPUT_CHAIN



bye



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Re: Ipsec/l2tp

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On Sat, Jul 03, 2004 at 01:46:01PM +0200, Primero wrote:
> 
> >
> >I hope someone else here can now fill in some useful details for you,  
> >given
> >that you're using 2.6.6
> >
> >Regards,
> >
> >Antony.
> >
> 
> I'm not an expert, but AFAIK and because it works using this way i think  
> that in 2.6 the process is very similar.
> 
> In 2.6 ipsec imlementation there is no Virtual interface, like ipsec0 or  
> everything else, but the packets both encrypted and unencrypted come from  
> the same interface , in expample eth0. They traverse netfilter two times,  
> like in 2.4 , they get the first time to the INPUT chain, if accepted they  
> traverse netfilter again in the normal process.
> 
> The reason i mark my packets at the STEP 1 when they come in encrypted is  
> because i needed a way to identify packets that arrived ENCRYPTED, get  
> decrypted and acceppted by ipsec and that are traversing the netfilter for  
> the second time.
> This way i can be sure that i handle only packets that have been accepted  
> by ipsec and i can feel good :)
>  for example, i use ipsec fot my WIFI lan and i have this kind of rules:
> 
> 1) MANGLE/PREROUTING for packets arriving in esp protocol
> 
> iptables -t mangle -a PREROUTING -s $Y_WIFI_HOSTS -i $MY_WIFI_INTERFACE -p  
> esp -j MARK --set-mark 10
> 
> 2) INPUT for packets arriving in esp protocol
> 
> iptables -A INPUT -p esp -j ACCEPT
> 
> now IPSEC will authenticate and eventually accept the packets
> 
> 3) INPUT and FORWARD for previously athenticated packets
> 
> iptables -A FORWARD -m --mark 10 -j MY_FORWARD_CHAIN
> iptables -A INPUT -m --mark 10 -j MY_INPUT_CHAIN

Hi

I believe there is a patch in pom-ng called policy that let you match a
packet based on which ipsec policy it used.

Another methog I use is using the updown script option and adding remove
firewall rules on the fly, on seconds thoughts that is not as good as
above though.

Alex

> 
> 
> 
> bye
> 
> 
> 
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]