Thank you!

I will try this.

I have confirmed it wasn't due to last year's OpenBSD 5.7 to 5.8 upgrade
as I built a VM with 5.7 using same settings and get exactly the same
behavior.  This was triple confirmed by being able to connect with iOS
on an iPhone, Windows 10, Chromebook (with md5 hmacs only) and even a
tablet running an older version of Android.  Here is the link to the bug
if anyone is interested.  But I will try the workaround offered by Yasuoka.

In the mean time, I have confirmed there is a Google Android bug
reported (by many people) confirming this is actually an issue with
Android not OpenBSD (or the myriad other VPN routers listed in the bug
report).  Though I very much appreciate understanding the underlying
reason as like Mattieu said, tweaking ipsec.conf for 3 days yielded no
solution.

https://code.google.com/p/android/issues/detail?id=196939

Thanks again!

Sly


On 03/30/2016 02:18 AM, YASUOKA Masahiko wrote:
> On Tue, 29 Mar 2016 11:37:14 +0200
> Mattieu Baptiste <mattie...@gmail.com> wrote:
>> On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight <slymidni...@yahoo.com> wrote:
>>> 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 the very same problem.
>> To me, It's caused by some Android updates. I saw this since 6.0, but
>> some security updates near 5.1.1 seems to trigger the same behavior.
>> I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
>> did not have the time to dig further...
> My colleague and I also hit this issue.
>
> This issue is caused by Android, it sends ESP packets with wrong
> padding size when SHA2-256 is selected for HMAC.  It seems that
> Android is using an old ietf draft for SHA2-256, but OpenBSD is using
> RFC 4868.
>
> When the issue occurs,
>
>   XXX packets with bad payload size or padding received
>
> counter in "netstat -sp esp" will be incremented.
>
> We can force using MD5 or SHA for HMAC to workaround this issue.  To
> do this, put the text below to /etc/isakmpd/isakmpd.policy and remove
> "-K" from isakmpd_flags.
>
>   Authorizer: "POLICY"
>   Comment: This is test
>   Licensees: "passphrase:PASSPHRASE"
>   conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present 
> == "yes" && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> 
> "true";
>
> --yasuoka

Reply via email to