On 2018-09-07, Alexander Skwar <alexanders.mailinglists+nos...@gmail.com> wrote:
> Hello
>
> We use a L2TP over IPsec VPN running on OpenBSD 6.1, which was setup
> by prior sysadmins. They are no longer at the company.
>
> Now a user running Ubuntu 16.04 + Gnome tries to connect to the VPN.
> The VPN client (on Linux side) was configured with NetworkManager.
>
> The connection fails. In /var/log/daemon log on the openbsd system,
> there's then (also on https://pastebin.com/xyS6UMsn):
>
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> HASH_ALGORITHM: got MD5, expected SHA
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep 7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep 7 09:46:41 apu isakmpd[69488]: message_negotiate_sa: no
> compatible proposal found
> Sep 7 09:46:41 apu isakmpd[69488]: dropped message from 212.25.17.146
> port 57092 due to notification type NO_PROPOSAL_CHOSEN
>
> Connections from Android, iOS and Mac work just fine. That's the
> first linux user trying to connect.
>
> The ipsec.conf (https://pastebin.com/3gmQR0iN) is:
>
> vpn_ext="redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "aes" group modp1024 \
> quick auth "hmac-sha" enc "aes" \
> psk "redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "3des" group modp1024 \
> quick auth "hmac-sha" enc "3des" \
> psk "redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "3des" group modp1024 \
> quick auth "hmac-sha" enc "aes" \
> psk "redacted"
>
> (vpn_ext and psk are of course not "redacted" in reality.)
>
> Well, uhm, anyone got an idea about what might be the cause of
> this issue?
>
> Thanks a lot,
>
> Alexander
>
>
This type of setup with "to any" uses what is called the "default
peer" which there is only one of, here you're defining it with one
set of ciphers/PFS (main aes/sha, pfs modp1024, quick aes/sha),
then redefining it with a different one (3des/sha/modp1024, 3des/sha),
then again with (3des/sha/modp1024, aes/sha). i.e. the first two
configuration blocks in your file are doing nothing.
The simple fix (that won't break anything currently working) would
be to configure Linux to use the same crypto as you've actually
got configured here, i.e. main: hmac-sha / 3des, PFS modp1024 (group 2),
and quick: hmac-sha / aes.
That is using pretty weak crypto though so it may be better to keep
Linux as-is and try this instead, see if your various clients still
connect:
ike passive esp transport \
proto udp from { $vpn_ext } to any port 1701 \
main auth "hmac-sha" enc "aes" group modp2048 \
quick auth "hmac-sha" enc "aes" \
psk "redacted"
That's more likely to work with your Linux client, and I've had a
setup with similar settings with Android/iOS and I think
also Windows.
