On Tue, 28 May 2019, Ian Dobson wrote:
I tried again from a different iphone running later iOS (12.2) and it
worked! (The device that didn't work is running iOS 10). Then I went back
to tcpdump and found the problem was staring me in the face:
tcpdump -i eth3 -nn host 144.132.45.114:
listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
14:30:55.417934 IP 1.143.57.22.30035 > 144.132.45.114.500: isakmp:
parent_sa ikev2_init[I]
It seems that iOS 10 client originates IKE packets from a high source port
rather than using port 500 like every other client I have used before.
I'm not sure that is entirely the case. If you are on your own DSL IP,
your first device behind NAT can likely use port 500. But if you are
using a phone on LTE that is behind Carrier Grade NAT, you likely do not
get port 500 even for the first client.
My firewall was then filtering it out as it only permitted '--sport 500
--dport 500.' A quick change to firewall rules to accept any source port
here and it all works now. (iOS 12 originates IKE packets from port 500
which is why the different iphone worked without any rule changes.)
Yes, our FAQ states you MUST allow any to (4)500 and 4(500) to any. And
you should allow TCP as well as UDP because soon there will be support
for TCP as well (as per RFC 8229)
BTW is there any plan for Libreswan to support EAP user authentication
methods in future, in addition to a certificate? On the iPhone, with IKEv1
I could use XAUTH to require a username/password in addition to the
installed certificate, which is an extra level of protection in case the
device itself is compromised.
We have plans for EAP support. The first supported method with be
EAP-TLS, targeting Windows machines without administrative privs to
install a machine certificate, then EAP-mschapv2.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
