IPSec Transport mode over NAT needed with v3.0.0

[lano1106]

I have tried to upgrade openswan from 2.6.56.3 to 3.0.0 and I had this unpleasant message:

003 "L2TP-PSK" #3: NAT-Traversal: Transport Mode not allowed due to security concerns -- using Tunnel mode. Rebuild Openswan with USE_NAT_TRAVERSAL_TRANSPORT_MODE=true in Makefile.inc to support transport mode.

So, I did try to do what the error message was suggesting to do. I did recompile openswan after making sure that USE_NAT_TRAVERSAL_TRANSPORT_MODE was set to true.

It did change nothing to the outcome. After some investigation, I did try to grep USE_NAT_TRAVERSAL_TRANSPORT_MODE in all c files and all h files and it seems like the only place where the define show up is in the error message text because otherwise it isn't used at all by the code itself.

This is a problem because I am using opeswan to use a L2TP over IPSec VPN and here is what is written in RFC 3193 Securing L2TP using IPSec, Section 2.1 L2TP Security Protocol:

Transport mode MUST be supported; tunnel mode MAY be supported.

It happens that the RFC-compliant VPN gateway that I talk to does not support tunnel mode.

So, I really don't care at all about possible security concerns, if I cannot use the VPN, openswan 3.0.0 is useless to me.

Please make sure that it is possible to use transport mode with NAT.

Thank you

[lano1106]

I have discovered I_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT it somehow did not been defined on my second compilation. I'll investigate it a little bit more and I'll come back to close this issue if I succeed in using transport mode with 3.0.0

[lano1106]

Ok, I went as far as removing the #ifndef I_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT blocks in

programs/pluto/spdb_v1_struct.c

and

programs/pluto/ikev1_quick.c

and I still have the error msg. Giving the option to the user of using transport mode despite the security concern is just broken. It doesn't work and as I have explained it is a serious issue because in some context the only usable mode is transport.

[letoams]

There is no concern with security and transport mode, other than some weirdness of Microsoft with L2TP.

That’s why libreswan killed that compile option years ago and always supports transport mode.

Paul

On Feb 27, 2021, at 14:17, Olivier Langlois notifications@github.com wrote:

 Ok, I went as far as removing the #ifndef I_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT blocks in

programs/pluto/spdb_v1_struct.c

and

programs/pluto/ikev1_quick.c

an I still have the error msg. Giving the option to the user of using transport mode despite the security concern is just broken. It doesn't work and as I have explained it is a serious issue because in some context the only usable mode is transport.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[lano1106]

thx for the answer Paul. can libreswan be an easy replacement to openswan without having to change too much the config?

I ended up being an openswan user because of this wiki page: https://wiki.archlinux.org/index.php/Openswan_L2TP/IPsec_VPN_client_setup

I did look into strongwan and it did look significantly too different from openswan for considering investing time to replace my working openswan v2.6.56.3 setup...

[letoams]

It’s a continuation fork, so yes. It is mostly a drop in replacement

https://nohats.ca/wordpress/openswan/

https://nohats.ca/swan.gif

https://libreswan.org/wiki/HOWTO:_openswan_to_libreswan_migration

Paul

On Feb 28, 2021, at 13:48, Olivier Langlois notifications@github.com wrote:

 thx for the answer Paul. can libreswan be an easy replacement to openswan without having to change too much the config?

I ended up being an openswan user because of this wiki page: https://wiki.archlinux.org/index.php/Openswan_L2TP/IPsec_VPN_client_setup

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mcr]

There is no concern with security and transport mode, other than some weirdness of Microsoft with L2TP. That’s why libreswan killed that compile option years ago and always supports transport mode. Paul

Oh, i see. I always wondered why you put that in without any explanation or test cases.

[mcr]

thx for the answer Paul. can libreswan be an easy replacement to openswan without having to change too much the config?

Libreswan no longer supports rawpublickeys in the way that openswan did, you have to do EVERYTHING with libnss, and so it doesn't work very well on embedded systems. If you don't need that, then libreswan is a much better fit.

[letoams]

I'm pretty sure that was not me who put it in :) git tracks the define back to your original git import, so if you want to check your old CVS, you ahead

[letoams]

you are right that all unaudited crypto code from 25 years ago that has seen no security review or gotten FIPS certification was removed. It is known to contain a number of vulnerabilities, like padding attacks, weak E=3 component, etc. I would also not use it on embedded systems.....

[letoams]

note that we ported libreswan with nss to the Lantronix Xport PRO, which is an embedded 32bit x86 nommu CPU with 16MB of RAM. https://www.lantronix.com/products/xport-pro/

How small is your embedded device?

[letoams]

https://www.reddit.com/r/archlinux/comments/d7yqjv/libreswan_is_easier_than_openswan/

So for l2tp, the arch wiki recommends Openswan. I made it work and I learned a lot, but today
I had to configure the VPN client again and I used Libreswan + NetworkManager +
NetworkManager-Libreswan plugin and it was a *trivial* configuration effort.

I post this here in case someone is looking for Openswan alternatives for arch.

Maybe it was easier to set up because I already had to understand the mysteries of IPsec;
I'll never know.

[lano1106]

wow. so much help! I am grateful.

This is for a desktop that has more likely than not already libnss already installed so memory footprint is not an issue for me.

I got 2 issues making the VPN work and doing it the hard way made me force to read a bunch of RFCs, something that I used to enjoy very much.

Both issues were at the PPP level:

1. peer was returning the error: Unauthorized remote IP address (Revolved by using ppp option noipdefault)
2. I was unable to accept peer request to use VJ comp during the IPPC nego (I have found in RFC 2661 why VJ comp with L2TP/IPSec is not a good idea...)

One last question: Will I still need xelerance l2tpd with libreswan or libreswan has everything needed to create a L2T?

[letoams]

You still need xl2tpd for L2TP. Note the latest versions don’t work for everyone. Try downgrading if you see issues.

But you should migrate that setup eventually to IKEv2.

Sent from my iPhone

On Mar 1, 2021, at 14:46, Olivier Langlois notifications@github.com wrote:

 wow. so much help! I am grateful.

This is for a desktop that has more likely than not already libnss is already installed so this is not.

I got 2 issues making the VPN work and doing it the hard way made me force to read a bunch of RFCs, something that I used enjoy very much.

Both issues were at the PPP level:

peer was returning the error: Unauthorized remote IP address (Revolved by using ppp option noipdefault) I was unable to accept peer request to use VJ comp during the IPPC nego (I have found in RFC 2661 why VC comp with L2TP/IPSec is not a good idea...) One last question: Will I still need xelerance l2tpd with libreswan or libreswan has everything needed to create a L2T?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.