Re: L2TP/IPSec via npppd won't work with Android 5.x

[johnw]

Hi Renaud and the lists,

Did you tried to use iked/ikev2 for android (+5.x) client?
I checked my note3 is support ikev2 psk/rsa,
I want to setup my home OpenBSD router act as vpn/nat router for my note3,
Thanks.

Renaud Allard  allard.it> writes:

>
>
> I can't get android to connect with modp > 1024, but settings like this
> work:
> ike passive esp transport \
> proto udp from A.B.C.D to any port l2tp \
> main auth "hmac-sha2-256" enc "aes-256" group modp1024 \
> quick auth "hmac-sha2-256" enc "aes-256" \
> psk "mysharedsecret"

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Renaud Allard]

On 03/25/2016 04:27 PM, Sly Midnight wrote:
> Hello,
>
> I don't mean to bring up an old thread, but I was wondering if anyone
> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
> (preferably the version on the Nexus line of devices) connecting to
> ipsec/l2tp.
>
> I had this working late last year some time and hadn't used it in a few
> months.  When I went to use it again a few days ago it didn't work at
> all.  After rebooting my phone and even trying it on my tablet that
> coincidentally runs the exact same version of stock Android 6.0.1, it
> too didn't work there.
>
> I have confirmed some interesting behavior.
>
> First if I tweak the ipsec.conf stanza to something like:
>
>> ike passive esp transport \
>> proto udp from X.X.X.X to any port 1701 \
>> main auth "hmac-sha2-256" enc "aes-256" group "modp1024" \
>> quick auth "hmac-sha2-s256" enc "aes-256" group "modp1024" \
>> psk "redacted"
> It creates an IPSEC SA and flow as shown by ipsecctl -s all, but npppd
> never sees a connection attempt and tcpdumping enc0 shows no traffic and
> ultimately the connection fails.
>
> If I modify it to hmac-md5, aes, modp2048 I can get my Chromebook with
> latest updates to connect successfully.
> If I modify it to hmac-sha2-256, aes-256, modp2048 I can get an iPhone
> with iOS 9.3 to connect successfully.
> If I modify it to hmac-sha, aes, modp2048 I can get a Windows 10 box to
> connect successfully.
>
> If I restore it to hmac-sha1, aes, modp1024 I can get an older Android
> tablet (one of my kid's) to connect successfully.
>
> What else can I do to troubleshoot this?  Because I signed up to a free
> 1 day trial of some Internet based VPN provider and successfully was
> able to connect to their IPSEC/L2TP VPN using my Android phone so I know
> it works.  It must just be a recent change in Android (or during the
> OpenBSD 5.7->5.8) update that is causing this incompatibility that makes
> it almost work.  Any help would be greatly appreciated.
>

I can't get android to connect with modp > 1024, but settings like this
work:
ike passive esp transport \
proto udp from A.B.C.D to any port l2tp \
main auth "hmac-sha2-256" enc "aes-256" group modp1024 \
quick auth "hmac-sha2-256" enc "aes-256" \
psk "mysharedsecret"

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Sly Midnight]

Hello,

I don't mean to bring up an old thread, but I was wondering if anyone
else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
(preferably the version on the Nexus line of devices) connecting to
ipsec/l2tp.

I had this working late last year some time and hadn't used it in a few
months.  When I went to use it again a few days ago it didn't work at
all.  After rebooting my phone and even trying it on my tablet that
coincidentally runs the exact same version of stock Android 6.0.1, it
too didn't work there.

I have confirmed some interesting behavior.

First if I tweak the ipsec.conf stanza to something like:

> ike passive esp transport \
> proto udp from X.X.X.X to any port 1701 \
> main auth "hmac-sha2-256" enc "aes-256" group "modp1024" \
> quick auth "hmac-sha2-s256" enc "aes-256" group "modp1024" \
> psk "redacted"
It creates an IPSEC SA and flow as shown by ipsecctl -s all, but npppd
never sees a connection attempt and tcpdumping enc0 shows no traffic and
ultimately the connection fails.

If I modify it to hmac-md5, aes, modp2048 I can get my Chromebook with
latest updates to connect successfully.
If I modify it to hmac-sha2-256, aes-256, modp2048 I can get an iPhone
with iOS 9.3 to connect successfully.
If I modify it to hmac-sha, aes, modp2048 I can get a Windows 10 box to
connect successfully.

If I restore it to hmac-sha1, aes, modp1024 I can get an older Android
tablet (one of my kid's) to connect successfully.

What else can I do to troubleshoot this?  Because I signed up to a free
1 day trial of some Internet based VPN provider and successfully was
able to connect to their IPSEC/L2TP VPN using my Android phone so I know
it works.  It must just be a recent change in Android (or during the
OpenBSD 5.7->5.8) update that is causing this incompatibility that makes
it almost work.  Any help would be greatly appreciated.

Sly

On 02/22/2016 07:48 AM, Stefan Krueger wrote:
> In mailing.openbsd.misc, you wrote:
>> Hi, everyone:
>>
>> [...]
>>
>> But the android devices I had won't work by all means. I found out that
>> Android 5.x
>> L2TP/IPSec VPN client works in:
>> hash algorithm: hmac-sha2-256
>> encrypt method: aes_cbc
>> life time: 28800
>>
>> The ipsec.conf with:
>> ``
>> ike passive esp tunnel \
>>  from "IP_ADDRESS" to any \
>>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>>  quick group "modp1024" \
>>  psk "SECRET_KEY"
>> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)
> Hi,
>
> the following config worked for me when I was using it (with npppd)
> last year (dumped it since I couldn't find a way to use it with iOS
> and Android at the same time):
>
> /etc/ipsec.conf
> public_ip = "x.y.z.a"
>
> ike passive esp transport \
> proto udp from $public_ip to any port l2tp \
> aggressive auth "hmac-sha1" enc "aes" group modp1024 \
> psk "XXX"
>
> IIRC Android required the use of "aggressive auth" where iOS only worked
> with the default "main auth"...

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Stefan Krueger]

In mailing.openbsd.misc, you wrote:
> Hi, everyone:
>
> [...]
>
> But the android devices I had won't work by all means. I found out that
> Android 5.x
> L2TP/IPSec VPN client works in:
> hash algorithm: hmac-sha2-256
> encrypt method: aes_cbc
> life time: 28800
>
> The ipsec.conf with:
> ``
> ike passive esp tunnel \
>  from "IP_ADDRESS" to any \
>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>  quick group "modp1024" \
>  psk "SECRET_KEY"
> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)

Hi,

the following config worked for me when I was using it (with npppd)
last year (dumped it since I couldn't find a way to use it with iOS
and Android at the same time):

/etc/ipsec.conf
public_ip = "x.y.z.a"

ike passive esp transport \
proto udp from $public_ip to any port l2tp \
aggressive auth "hmac-sha1" enc "aes" group modp1024 \
psk "XXX"

IIRC Android required the use of "aggressive auth" where iOS only worked
with the default "main auth"...

Re: L2TP/IPSec via npppd won't work with Android 5.x

[YASUOKA Masahiko]

Hi,

On Mon, 22 Feb 2016 00:26:11 +0800
Jiahao Dai  wrote:
> I am a new openBSD user and I found it's extramly difficult to setup a
> L2TP/IPSec(IKEv1) Road Warrior server to getting work with Android devices.
> 
> I followed the tutorial here Configuring L2TP Over IPSec on OpenBSD for Mac
> OS X
> Clients [1], deployed on fresh openBSD 5.8 and found out that iOS9.x ipad
> works like a
> charm.
> 
> But the android devices I had won't work by all means. I found out that
> Android 5.x
> L2TP/IPSec VPN client works in:
> hash algorithm: hmac-sha2-256
> encrypt method: aes_cbc
> life time: 28800
> 
> The ipsec.conf with:
> ``
> ike passive esp tunnel \
>  from "IP_ADDRESS" to any \
>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>  quick group "modp1024" \
>  psk "SECRET_KEY"
> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)
> 
> The /var/log/messages didn't report anything as the VPN connection failed
> on
> Android device.
> 
> When debugging at the foreground with `isakmpd -v -K -d`

In this case, you should do "ipsecctl -f /etc/ipsec.conf" again after
start the isakmpd.

> It still reported that:
> ``
> 002212.657833 Default isakmpd: starting [priv]
> 002219.561051 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561236 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561386 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561546 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561664 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561746 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561832 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.561916 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562003 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562085 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562189 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562308 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562385 Default message_negotiate_sa: no compatible proposal found
> 002219.562459 Default dropped message from 139.227.237.86 port 500 due to
> notification type NO_PROPOSAL_CHOSEN
> ^C002221.748476 Default isakmpd: shutting down...
> 002221.748562 Default isakmpd: exit
> 
> ""
> 
> I am trying to use aes and encryption algorithm but it seems that it keep
> using 3des, what can I do?

This seems that the "ike" line in ipsec.conf wasn't appied to the
received packets.

I think you should:

  - make sure to do "ipsectl" after iksampd starts
(ipsec=YES in rc.conf.local does this)
  - check the "ike" line (especially the IP address of "from")

> Please help. I have spent all my weekends on it, still no idea. Other idea
> on VPN
> type with setup (except OpenVPN which needs additional software implement)
> are
> welcome.
> Jiahao Dai