VPN solutions (Openswan + xl2tp [Windows] or Openswan + Shrew VPN Client [Linux/Windows])

[Ph Vouters]

Dear everyone,

Perhaps this will interest the HP users community ?

Here are a set of Web documents using Openswan on Linux as the VPN server and the L2TP protocol coming from Windows or using Shrew VPN Client on Windows/Linux.

L2TP based VPN solution between Windows and Linux:

http://vouters.dyndns.org/tima/Linux-Openswan-Setting_up_an_Intranet_VPN_with_Windows_7.html

Shrew VPN Client based solutions between Linux/Windows and Linux:

1/ Quick introduction to Shrew VPN Client on Linux:

http://vouters.dyndns.org/tima/Linux-Shrew_VPN_Client-Installing_and_using_Shrew_VPN_client_on_Linux.html

2/ Setting up a simple VPN'ed computer  with Openswan as the VPN server on the Linux side

http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven.html

3/ Setting up a simple VPN'ed computer with asymetric PKCS12 keys exchange (Openswan on the Linux side)

http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven-Part_2.html

4/ Setting up a DHCP served VPN'ed network using Openswan on the Linux side (Pre-shared key)

http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven-Part_3.html

Thank you for your attention,

Philippe

[Matti_Kurkela · Accepted solution]

That was interesting. A while ago, I set up an IPsec + L2TP VPN for MacOSX and iOS, and it was a bit of a pain to find the necessary information from all over the internet. It's good that you've collected all the pieces of the puzzle together.

But your iptables configuration seems a little odd to me:

     -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[...]
     # xl2tp
     -A INPUT -m state --state NEW -m udp -p udp --dport 1701 -j ACCEPT
     -A INPUT -m mark --mark 0x1 -p udp --dport 1701 -j ACCEPT
     -A INPUT  -m policy --dir in --pol ipsec -j ACCEPT
[...]
     -A FORWARD -m mark --mark 0x1 -j ACCEPT

Your INPUT chain has the usual initial rule for a state-based match for ESTABLISHED and RELATED packets, which makes things much easier.

Then, you accept anything incoming to your UDP port 1701, explicitly checking that it is NEW. Because non-new packets are already matched by an earlier rule, it is redundant unless your plan is to explicitly exclude INVALID here... or if you are interested in the more advanced states (UNTRACKED/SNAT/DNAT). A comment explaining the overall logic you wish to achieve would be useful here.

Then, you accept anything incoming to your UDP port 1701, if it has a netfilter mark 0x1 on it. But your iptables configuration has nothing that sets any netfilter marks (= no rules with "... -j MARK"), and the previous rules will match all valid connections (whether NEW, ESTABLISHED or RELATED) anyway. I fail to see the purpose of this rule. Am I missing something?

The third INPUT rule under the #xl2tp comment accepts everything that is associated with an IPsec policy.

If you want a rule that accepts new connections to your xl2tp port only if they're protected with IPsec, you probably should replace the three rules under the #xl2tp comment with this single rule:

-A INPUT -p udp --dport 1701 -m policy --dir in --pol ipsec -j ACCEPT

Likewise, in the FORWARD chain, you also have a redundant-looking rule for accepting packets already stamped with netfilter mark 0x1:

     -A FORWARD -m mark --mark 0x1 -j ACCEPT

[Ph Vouters]

Dear Matti,

Thank you so much for your very valuable inputs regarding the iptables I was proposing. I took advantage of your remarks to first take them into account, to redo all tests and to upgrade my document to latest Linux Fedora version. My existing document along your remarks helped me to quickly reconfigure everything at low effort cost. I even added some precisions on problems I today faced. The real thing is to fully exploit each log file. I now much more trained in exploiting the Openswan IPSec logs. It was not the case where I first studied this VPN subject. The document you have read and made your valuable remarks upon was my first VPN study.

One question though ! Do I actually need -A FORWARD -m mark --mark 0x1 -j ACCEPT ? My current intuition would be that the answer is yes because of -A POSTROUTING -o eth0 -j MASQUERADE in the nat table. But this is not quite obvious in my mind.

With my renewed thanks for your valuable remarks.

Philippe

[Ph Vouters]

Dear Matti,

I just made a test. It happens I have answered my own question. The -A FORWARD -m mark --mark 0x1 -j ACCEPT is totally superfluous.

I shall cross reference this HP forum discussion and I shall name you the contributor for this document in its hidden section. In the hope HP won't break the URL link soon.

Post scriptum : if you want my original text document before it is turned to html, you have my email address on how to contact me.

Very warmest regards,

Philippe

[Ph Vouters]

Dear everyone,

As a follow-up of my VPN DHCP served network study, I have added a new document describing how to Openswan XAUTH PAM authenticate a VPN user. The VPN client is still Shrew. The document can be found at:

http://vouters.dyndns.org/tima/Linux-Openswan-Shrew_VPN_Client-PAM-Adding_XAUTH_PAM_support_to_Openswan-Testing_with_Shrew.html

The final goal I am running after is to Openswan XAUTH PAM authenticate a user indifferently using OpenLDAP or Microsoft Active Directory. Authenticating indifferently via OpenLDAP or Microsoft Active Directory depends upon available Windows server hardware + software.

Philippe

[Ph Vouters]

Dear Linux users,

Last but not least here is a paper showing how to PAM authenticate a Microsoft Active Directory user. It has been tested using Shrew + Openswan 2.6.38 (patched).

http://vouters.dyndns.org/tima/Linux-OpenLDAP-Windows_server-AD-Enabling_OpenLDAP_authentication_of_AD_users.html

There has been much work onto Openswan 2.6.38 for correct PAM authentications, especially when the OpenLDAP server hangs. The openswan 2.6.38 patch is all about this. Refer to the latest update of the document at:

http://vouters.dyndns.org/tima/Linux-Openswan-Shrew_VPN_Client-PAM-Adding_XAUTH_PAM_support_to_Openswan-Testing_with_Shrew.html

Yours truly,

Philippe