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.
