The problem is on Android 6.x/7.x that need to be rooted to change their
ipsec settings to allow for higher encryption. The following works on
those OSes:
cat ipsec.conf:
ike passive esp transport \
proto udp from "publicip" to any port l2tp \
main group "modp1024" \
quick group "modp1024" \
psk "yourpass"
It's bad, but what can you do? Google won't deal with it, and the
vendors claim it would break current solutions. I've seen in debug that
after a few tries Android would give the right aes2-256 keying but by
then isakmpd was having none of it...
Cheers,
Noth
On 03/10/17 00:49, Charles Amstutz wrote:
Hello Sterling,
Thanks for the response. I changed it to
ike passive esp transport \
proto udp from $public_ip to any port 1701 \
main auth "hmac-sha1" enc "aes-256" group modp1024\
quick auth "hmac-sha1" enc "aes-256" \
PSK "PSK-GOES-HERE"
and still no luck. I found out that Android 8 will connect (using aes). I am
dumpping pflog0 and seeing no blocks. However, that doesn't mean it still isn't
a potential pf problem I guess. However, if IOS and android 8 would connect, I
would think that would rule a pf problem?
Is there a way to turn on additional debugging? I'm using isakmpd -K in
rc.conf.local, so not using isakmpd.policy/.conf (from my understanding)
Everything in /var/log/messages is just from npppd. Unless I'm reading it
wrong, there doesn't appear to be any errors.
-----Original Message-----
From: Sterling Archer [mailto:deb...@gmail.com]
Sent: Monday, October 2, 2017 5:35 PM
To: Charles Amstutz <charl...@infinitesys.com>
Cc: misc@openbsd.org
Subject: Re: l2tp and openbsd 6.1
On Mon, Oct 2, 2017 at 10:03 PM, Charles Amstutz <charl...@infinitesys.com>
wrote:
Hello everyone,
I'm new to this list and l2tp/openbsd (but do have working UNIX/Linux
knowledge). After searching the previous forum posts (and the internet) I have
found a lot of information on l2tp ipsec.conf connection strings. However, I
can't get android to connect. I keep getting IKE negotiation failed errors.
I've looked at sites such as:
http://bluepilltech.blogspot.com/2017/02/openbsd-l2tp-over-ipsec-andro
id-601-ios.html
https://www.authbsd.com/blog/?p=20
http://daemonforums.org/showthread.php?t=10326
https://rzemieniecki.wordpress.com/2014/05/28/debugging-ipsec-on-openb
sd-invalid_cookie/
https://man.openbsd.org/npppd.conf.5
https://blog.gordonturner.com/2016/12/10/openbsd-6-0-vpn-endpoint-for-
ios-and-osx/
https://marc.info/?l=openbsd-misc&m=145922338026396&w=2
https://marc.info/?l=openbsd-misc&m=145614573528471&w=2
https://www.mail-archive.com/misc@openbsd.org/msg145747.html
... etc
I can get IOS to connect, but I can't get android 7 to connect. I've
read that android has bugs with the vpn client in 6.x and 7.x (not
sure if it is fixed in 8 or not). However, what is confusing is it
connections just fine To my windows l2tp server. Bug tracker:
https://issuetracker.google.com/issues/37074640#c35
My goal: Setup openbsd to work with IOS/android/windows/whatever.
My questions.
1) Can you have more than one ike line in ipsec.conf? from my presumption
of looking at sites on the internet, you can, however, I am not sure.
https://www.authbsd.com/blog/?p=20 makes it seem like you can, unless
it is just two examples
2) Every time I read a site that says, "this configuration worked for me on
android", it doesn't work for me. I presume it is my lack of understanding, though,
I'm not ruling out the possible android bug.
I appreciate any help.
Here is my ipsec.conf (this allows IOS to connect)
public_ip = "x.x.x.x"
ike passive esp transport \
proto udp from $public_ip to any port 1701 \
main auth "hmac-sha1" enc "aes" group modp1024\
quick auth "hmac-sha1" enc "aes" \
psk "PSK-GOES-HERE"
Here is my npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on 0.0.0.0
listen on ::
}
ipcp IPCP {
pool-address 10.0.0.101-10.0.0.254
dns-servers x.x.x.x
}
# use pppx(4) interface. use an interface per a ppp session.
interface pppx0 address 10.0.0.1 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0
I'm able to connect using a similar setup, but using aes-256 instead of aes as
encoding in ipsec.conf.
--
:wq!
