> -----Original Message-----
> Hello
>
> I have been having trouble getting an openBSD laptop to connect to ssl
> connections when communicating over ikev2.
>
> In general terms (since I don't know exactly what specifics would be
> important), this is what I observe:
>
> 1. OpenBSD laptop has no issues connecting to imaps or https on a
> openBSD server when connected to the local network over wireless
> connection. For example:
>
> $ openssl s_client -state -connect name.tld:imaps
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv3 write client hello A
> SSL_connect:SSLv3 read server hello A
> .
> .
> .
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:SSLv3 read server key exchange A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:SSLv3 read server session ticket A
> SSL_connect:SSLv3 read finished A
> ---
> Certificate chain
> .
> .
> .
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, X25519, 253 bits
> ---
> SSL handshake has read 4779 bytes and written 281 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> .
> .
> .
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL
> ACL2=UNION] Courier-IMAP ready. Copyright 1998-2017 Double Precision,
> Inc. See COPYING for distribution information.
>
>
> 2. Apple iOS devices have no issues connecting to imaps/https on
> openbsd server, when connected to the local network.
>
> 3. OpenBSD laptop, when connected remotely using iked is unable to
> complete ssl connection _most_ of the time (by this, I would guesstimate
> about 95%+ of the connections to imaps "hang," and about 75%+ of the
> connections to https "hang"). This occurs at one of two places.
> Either:
>
> $ openssl s_client -state -connect name.tld:imaps
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv3 write client hello A
> SSL_connect:SSLv3 read server hello A
>
> ... and that's it. Or:
>
> $ openssl s_client -state -connect name.tld:imaps
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv3 write client hello A
> SSL_connect:SSLv3 read server hello A
> .
> .
> .
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:SSLv3 read server key exchange A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
>
> ... and nothing more. However, using nc to connect to the non-ssl imap
> port appears to work (both locally and over the ikev2 VPN):
>
> $ nc name.tld imap
> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION]
> Courier-IMAP ready. Copyright 1998-2017 Double Precision, Inc. See
> COPYING for distribution information.
>
>
> 4. Apple iOS devices, when connected (using ssl) over iked VPN appear
> to be much more reliable. While there are times when they appear to
> "hang" when connecting, it seems like it happens < 20% of the time.
>
> I don't use my laptop remotely very often; the last time I did was about
> 4-5 months ago. At that point, I was able to connect to imaps much more
> reliably (basically, the mail client worked over imaps, and there was no
> reason to investigate anything).
>
> I don't think this is a pf issue, since the connection attempts over ssl
> get an initial response.
>
> I tried dropping the mtu on the openbsd laptop's wireless adapter to
> 1200; but that did not seem to change anything.
>
> I guess I don't really have much of an idea how to investigate this
> further.
>
> Any suggestions on how to proceed would be great.
>
> Thanks
> Ted
>
I wanted to update my observations.
I now realize that since my most recent update (yesterday), I am getting
100% failure of https/imaps connection, when that connection includes
traversing a VPN tunnel established by iked.
This is true both for an openBSD laptop with a wireless connection to the
network, and openBSD servers connected with a cable.
This behavior did not exist prior to my update yesterday.
As I stated above, my laptop can connect over ssl to https/imaps when on the
local network.
However, when attempting those connections over an iked VPN, ssl connections
fail.
I also have a remote server at a remote location that uses rsync to keep a
copy of my data off-site.
This remote server also serves a simple webpage with some basic status
information that I can quickly look at.
Since yesterday (I now realize), this remote (over iked) webpage is not
accessible over https, but is available over http.
So, in summary, when I try to connect to a service with ssl, and I am NOT
traversing an ikev2 tunnel, everything is fine:
$ openssl s_client -state -connect name.tld:https
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
.
.
.
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
.
.
.
---
Server certificate
.
.
.
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 4648 bytes and written 289 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
009F42B70956AE8140EC2BB59D8D6935BF6907B1C9D5E465875D67D378F68696
Session-ID-ctx:
Master-Key:
8EE603E0CF6F6C6B621AC20F386DD5A94D982E76E345CEC8D07C3D26E4482DF803E00F75706F
123D42954FD024A95431
Start Time: 1543535784
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
But, when I try to access the same service, when the packets are traveling
through the VPN, I see:
$ openssl s_client -state -connect name.tld:https
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
... and nothing more (eventually, the connection times out).
I can access things that don't use ssl over the VPN (ssh, http, imap, rsync,
etc.), and those seem to work without an issue.
The systems are running a snapshot from yesterday:
$ uname -rvm
6.4 GENERIC.MP#479 amd64
I would appreciate any advice on how to more specifically define/address
this issue.
Thanks
Ted
