[strongSwan] What the blankety-blank-blank is Win10 doing? :-)
Karl Denninger
karl at denninger.net
Mon Jun 26 03:33:35 CEST 2017
There are times I hate Windows.... this is one of them.
I had a working certificate-based system on my Win10 laptop. I haven't
used it in a while, and now it won't connect. My Android phone does,
using the StrongSwan app -- it's fine.
StrongSwan (on a FreeBSD host) is getting the connection request, it
agrees with the proposal, and then when it should start getting
authentication information..... it doesn't. After a few seconds the
half-open connection is torn down of course. The client says it's "not
communicating" (that's Windows 10's error message)
What I have on the server is quite curious:
In the log (set to level 2) I get this:
Jun 25 20:05:47 NewFS charon: 15[NET] received packet: from
208.54.70.220[49944] to 192.168.10.100[500] (880 bytes)
Jun 25 20:05:47 NewFS charon: 15[ENC] parsed IKE_SA_INIT request 0 [ SA
KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
Jun 25 20:05:47 NewFS charon: 15[IKE] received MS NT5 ISAKMPOAKLEY v9
vendor ID
Jun 25 20:05:47 NewFS charon: 15[IKE] received MS-Negotiation Discovery
Capable vendor ID
Jun 25 20:05:47 NewFS charon: 15[IKE] received Vid-Initial-Contact vendor ID
Jun 25 20:05:47 NewFS charon: 15[ENC] received unknown vendor ID:
01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
Jun 25 20:05:47 NewFS charon: 15[IKE] 208.54.70.220 is initiating an IKE_SA
Jun 25 20:05:47 NewFS charon: 15[IKE] local host is behind NAT, sending
keep alives
Jun 25 20:05:47 NewFS charon: 15[IKE] remote host is behind NAT
Jun 25 20:05:47 NewFS charon: 15[IKE] sending cert request for "C=US,
ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=Cuda Systems LLC CA"
Jun 25 20:05:47 NewFS charon: 15[ENC] generating IKE_SA_INIT response 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Jun 25 20:05:47 NewFS charon: 15[NET] sending packet: from
192.168.10.100[500] to 208.54.70.220[49944] (333 bytes)
Jun 25 20:06:08 NewFS charon: 15[IKE] sending keep alive to
208.54.70.220[49944]
Jun 25 20:06:17 NewFS charon: 15[JOB] deleting half open IKE_SA with
208.54.70.220 after timeout
So right up until the last two lines everything looks good -- so far.
But then StrongSwan gets nothing else, sends a keepalive, and eventually
deletes the half-open connection.
Tracing it on the inbound interface I see this:
[\u at NewFS /disk/karl]# tcpdump -v -i em0 port 500 or 4500
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size
262144 bytes
20:05:47.905157 IP (tos 0x0, ttl 114, id 10177, offset 0, flags [none],
proto UDP (17), length 908)
mdc4636d0.tmodns.net.49944 > FS.Denninger.net.isakmp: isakmp 2.0
msgid 00000000: parent_sa ikev2_init[I]:
(sa: len=516
(p: #1 protoid=isakmp transform=4 len=40
(t: #1 type=encr id=3des )
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp1024 ))
(p: #2 protoid=isakmp transform=4 len=40
(t: #1 type=encr id=3des )
(t: #2 type=integ id=#12 )
(t: #3 type=prf id=#5 )
(t: #4 type=dh id=modp1024 ))
(p: #3 protoid=isakmp transform=4 len=40
(t: #1 type=encr id=3des )
(t: #2 type=integ id=#13 )
(t: #3 type=prf id=#6 )
(t: #4 type=dh id=modp1024 ))
(p: #4 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp1024 ))
(p: #5 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=integ id=#12 )
(t: #3 type=prf id=#5 )
(t: #4 type=dh id=modp1024 ))
(p: #6 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=integ id=#13 )
(t: #3 type=prf id=#6 )
(t: #4 type=dh id=modp1024 ))
(p: #7 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=00c0))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp1024 ))
(p: #8 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=00c0))
(t: #2 type=integ id=#12 )
(t: #3 type=prf id=#5 )
(t: #4 type=dh id=modp1024 ))
(p: #9 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=00c0))
(t: #2 type=integ id=#13 )
(t: #3 type=prf id=#6 )
(t: #4 type=dh id=modp1024 ))
(p: #10 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp1024 ))
(p: #11 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=#12 )
(t: #3 type=prf id=#5 )
(t: #4 type=dh id=modp1024 ))
(p: #12 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=#13 )
(t: #3 type=prf id=#6 )
(t: #4 type=dh id=modp1024 )))
(v2ke: len=128 group=modp1024)
(nonce: len=48
data=(9a83d508dd3d77ea8a6b...01528bbbc00696121849ab9a1c5b2a5100000002))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(v2vid: len=20 vid=.+Qi...}|......a....)
(v2vid: len=16 vid=.....A.......U. )
(v2vid: len=16 vid=&$M8..a..*6.....)
(v2vid: len=20 vid=.R.......I...[*Q....)
20:05:47.910326 IP (tos 0x0, ttl 64, id 27156, offset 0, flags [none],
proto UDP (17), length 361)
FS.Denninger.net.isakmp > mdc4636d0.tmodns.net.49944: isakmp 2.0
msgid 00000000: parent_sa ikev2_init[R]:
(sa: len=40
(p: #1 protoid=isakmp transform=4 len=40
(t: #1 type=encr id=3des )
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp1024 )))
(v2ke: len=128 group=modp1024)
(nonce: len=32
data=(b0b6589088e64b2e2b50...02b720e1c1739fdf04cdf4320000000800004014))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(v2cr: len=21)
(n: prot_id=#0 type=16404(status))
This looks ok -- we have agreed on a proposal and intend to communicate.
I don't like the 3DES deal but I'll deal with that later. The problem
starts here:
20:05:48.066485 IP (tos 0x0, ttl 113, id 10178, offset 0, flags [+],
proto UDP (17), length 820)
mdc4636d0.tmodns.net.36695 > FS.Denninger.net.sae-urn: NONESP-encap:
isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len
mismatch: isakmp 1580/ip 788)
StrongSwan never gets this packet. I assume the problem here is the
length mismatch, but not certain. What is certain is that StrongSwan
never sees it; no matter how far up I turn the logging I never see any
evidence of it being logged. The transmission gets repeated two more
times (which I've verified is also on the wire itself) and then the
client gives up.
20:05:49.132864 IP (tos 0x0, ttl 113, id 10179, offset 0, flags [+],
proto UDP (17), length 820)
mdc4636d0.tmodns.net.36695 > FS.Denninger.net.sae-urn: NONESP-encap:
isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len
mismatch: isakmp 1580/ip 788)
20:05:50.092938 IP (tos 0x0, ttl 113, id 10180, offset 0, flags [+],
proto UDP (17), length 820)
mdc4636d0.tmodns.net.36695 > FS.Denninger.net.sae-urn: NONESP-encap:
isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len
mismatch: isakmp 1580/ip 788)
Finally, we have the shutdown notification from the server on the
half-open connection.
20:06:08.002905 IP (tos 0x0, ttl 64, id 27171, offset 0, flags [none],
proto UDP (17), length 29)
FS.Denninger.net.isakmp > mdc4636d0.tmodns.net.49944: [|isakmp]
^C
6 packets captured
7921 packets received by filter
0 packets dropped by kernel
Anyone seen this before? I'm not at all sure what's going on here since
it appears to be at the stack level. I'm attempting to make the
connection over a tethered cellular link but that shouldn't matter
because the same cellular phone and link works perfectly well with the
StrongSwan app.
There is one material difference: The IP address is different when I
bring it up from the StrongSwan app on the phone! I'm wondering if this
is some sort of artifact of T-Mobile doing a 6-to-4 conversion
internally when I am using the hotspot but not when I am on the "native"
app (or the other way around) and screwing the pooch....
I've had this working before but it's been quite a while since I've
cared... now I have a need for it on that machine and of course it's
broken. I haven't made changes on the server or client end that I'm
aware of, but of course Windows like to load "updates" at whim and that
may be involved here too.
I'd just tether through the phone with the VPN up on it via the
StrongSwan app except for one problem -- the Android tethering app and
StrongSwan don't "adjust" DNS cooperatively (e.g. forwarding it or
similar), so what winds up happening is that the client ends up with no
functional nameserver. It *does* have a functional packet path, but
it's not surprising the nameserver doesn't work since that would be a
double-NAT (first to the phone and then again into the VPN host.) If I
could override the phone's tethering advertisement for DNS (say, to a
public one like 8.8.8.8) that would be a functional alternative but
Android has no way to do that in their built-in tethering server
(Google, of course, doesn't want you blocking ads that way and it would
be trivial to do so!)
If anyone has seen this one before or has an idea what's going on I'd
appreciate it.
Thanks.
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170625/09051e63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170625/09051e63/attachment-0001.bin>
More information about the Users
mailing list