<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>There are times I hate Windows.... this is one of them.</p>
<p>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.</p>
<p>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)</p>
<p>What I have on the server is quite curious:</p>
<p>In the log (set to level 2) I get this:</p>
<p><tt>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)<br>
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 ]<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] received MS NT5
ISAKMPOAKLEY v9 vendor ID<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] received MS-Negotiation
Discovery Capable vendor ID<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] received
Vid-Initial-Contact vendor ID<br>
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<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] 208.54.70.220 is
initiating an IKE_SA<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] local host is behind NAT,
sending keep alives<br>
Jun 25 20:05:47 NewFS charon: 15[IKE] remote host is behind NAT<br>
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"<br>
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) ]<br>
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)<br>
Jun 25 20:06:08 NewFS charon: 15[IKE] sending keep alive to
208.54.70.220[49944]<br>
Jun 25 20:06:17 NewFS charon: 15[JOB] deleting half open IKE_SA
with 208.54.70.220 after timeout<br>
</tt></p>
<p><tt>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.</tt></p>
<p><tt>Tracing it on the inbound interface I see this:</tt></p>
<p><tt>[\u@NewFS /disk/karl]# tcpdump -v -i em0 port 500 or 4500<br>
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture
size 262144 bytes<br>
20:05:47.905157 IP (tos 0x0, ttl 114, id 10177, offset 0, flags
[none], proto UDP (17), length 908)<br>
mdc4636d0.tmodns.net.49944 > FS.Denninger.net.isakmp:
isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:<br>
(sa: len=516<br>
(p: #1 protoid=isakmp transform=4 len=40<br>
(t: #1 type=encr id=3des )<br>
(t: #2 type=integ id=hmac-sha )<br>
(t: #3 type=prf id=hmac-sha )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #2 protoid=isakmp transform=4 len=40<br>
(t: #1 type=encr id=3des )<br>
(t: #2 type=integ id=#12 )<br>
(t: #3 type=prf id=#5 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #3 protoid=isakmp transform=4 len=40<br>
(t: #1 type=encr id=3des )<br>
(t: #2 type=integ id=#13 )<br>
(t: #3 type=prf id=#6 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #4 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0080))<br>
(t: #2 type=integ id=hmac-sha )<br>
(t: #3 type=prf id=hmac-sha )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #5 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0080))<br>
(t: #2 type=integ id=#12 )<br>
(t: #3 type=prf id=#5 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #6 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0080))<br>
(t: #2 type=integ id=#13 )<br>
(t: #3 type=prf id=#6 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #7 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=00c0))<br>
(t: #2 type=integ id=hmac-sha )<br>
(t: #3 type=prf id=hmac-sha )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #8 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=00c0))<br>
(t: #2 type=integ id=#12 )<br>
(t: #3 type=prf id=#5 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #9 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=00c0))<br>
(t: #2 type=integ id=#13 )<br>
(t: #3 type=prf id=#6 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #10 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0100))<br>
(t: #2 type=integ id=hmac-sha )<br>
(t: #3 type=prf id=hmac-sha )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #11 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0100))<br>
(t: #2 type=integ id=#12 )<br>
(t: #3 type=prf id=#5 )<br>
(t: #4 type=dh id=modp1024 ))<br>
(p: #12 protoid=isakmp transform=4 len=44<br>
(t: #1 type=encr id=aes (type=keylen value=0100))<br>
(t: #2 type=integ id=#13 )<br>
(t: #3 type=prf id=#6 )<br>
(t: #4 type=dh id=modp1024 )))<br>
(v2ke: len=128 group=modp1024)<br>
(nonce: len=48
data=(9a83d508dd3d77ea8a6b...01528bbbc00696121849ab9a1c5b2a5100000002))<br>
(n: prot_id=#0 type=16388(nat_detection_source_ip))<br>
(n: prot_id=#0 type=16389(nat_detection_destination_ip))<br>
(v2vid: len=20 vid=.+Qi...}|......a....)<br>
(v2vid: len=16 vid=.....A.......U. )<br>
(v2vid: len=16 vid=&$M8..a..*6.....)<br>
(v2vid: len=20 vid=.R.......I...[*Q....)<br>
20:05:47.910326 IP (tos 0x0, ttl 64, id 27156, offset 0, flags
[none], proto UDP (17), length 361)<br>
FS.Denninger.net.isakmp > mdc4636d0.tmodns.net.49944:
isakmp 2.0 msgid 00000000: parent_sa ikev2_init[R]:<br>
(sa: len=40<br>
(p: #1 protoid=isakmp transform=4 len=40<br>
(t: #1 type=encr id=3des )<br>
(t: #2 type=integ id=hmac-sha )<br>
(t: #3 type=prf id=hmac-sha )<br>
(t: #4 type=dh id=modp1024 )))<br>
(v2ke: len=128 group=modp1024)<br>
(nonce: len=32
data=(b0b6589088e64b2e2b50...02b720e1c1739fdf04cdf4320000000800004014))<br>
(n: prot_id=#0 type=16388(nat_detection_source_ip))<br>
(n: prot_id=#0 type=16389(nat_detection_destination_ip))<br>
(v2cr: len=21)<br>
(n: prot_id=#0 type=16404(status))</tt></p>
<p><tt>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:<br>
</tt></p>
<p><tt>20:05:48.066485 IP (tos 0x0, ttl 113, id 10178, offset 0,
flags [+], proto UDP (17), length 820)<br>
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)</tt></p>
<p><tt>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.<br>
</tt></p>
<p><tt>20:05:49.132864 IP (tos 0x0, ttl 113, id 10179, offset 0,
flags [+], proto UDP (17), length 820)<br>
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)<br>
20:05:50.092938 IP (tos 0x0, ttl 113, id 10180, offset 0, flags
[+], proto UDP (17), length 820)<br>
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)</tt></p>
<p><tt>Finally, we have the shutdown notification from the server on
the half-open connection.<br>
</tt></p>
<p><tt>20:06:08.002905 IP (tos 0x0, ttl 64, id 27171, offset 0,
flags [none], proto UDP (17), length 29)<br>
FS.Denninger.net.isakmp > mdc4636d0.tmodns.net.49944:
[|isakmp]<br>
^C<br>
6 packets captured<br>
7921 packets received by filter<br>
0 packets dropped by kernel<br>
</tt></p>
<p>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.</p>
<p>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....<br>
</p>
<p>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.<br>
</p>
<p>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!)</p>
<p>If anyone has seen this one before or has an idea what's going on
I'd appreciate it.</p>
<p>Thanks.<br>
</p>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
</div>
</body>
</html>