> On Tue, 28 May 2019, Paul Wouters wrote: > > The only possible other remote option is that the initial IKEv2 packet > is getting fragmented (a misconfiguration with the crypto system policies > in fedora can cause that). You can use tcpdump to see a very large packet > coming in (that doesn't make it to the libreswan pluto daemon).
Thanks Paul. 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. 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.) Thanks for your help. 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. Ian _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
