Re: TLS suddenly not working over IKED site-to-site - SOLVED?

2019-03-15 Thread Janne Johansson 
Den tors 14 mars 2019 kl 21:51 skrev Zhi-Qiang Lei :

> Mine is resolved by applying a smaller max-mss in pf and disabling ipcomp.
> Only disabling ipcomp didn’t work.
>
> > On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko 
> wrote:
> >> Then, I took the advice above, and disable ipcomp on the tunnel, and,
> BAHM, https (and imaps) were working without an issue from openbsd, Windows
> 7, and Macs!
>

I ran into something similar a while ago, and even if "fixing" https/imaps
works with mss clamping, it will still cause
issues with fragmented UDP and large icmp, since those will not care about
mss, only TCP does.

The problem is still there, its just a tcp-only workaround to lower mss
in-flight for a problem that is mostly visible
when doing *s services since they ship long lists of preferred algorithms
which causes large packets to be sent,
whereas simple ldap lookups or ntp/dns/http get by with less info sent and
hence send smaller packets.

Still, large non-tcp ip will see unexpected drops in such scenarios where
you only lower mss and not the MTU
on some in-between L3 interface so it correctly fragments when needed.

-- 
May the most significant bit of your life be positive.

Re: TLS suddenly not working over IKED site-to-site - SOLVED?

2019-03-14 Thread Zhi-Qiang Lei 
Mine is resolved by applying a smaller max-mss in pf and disabling ipcomp. Only 
disabling ipcomp didn’t work.

> On Mar 15, 2019, at 3:15 AM, Andrew Daugherity  
> wrote:
> 
> On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko  
> wrote:
>> Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, 
>> https (and imaps) were working without an issue from openbsd, Windows 7, and 
>> Macs!
>> 
>> Just to be sure, I updated this am to the 12/19 amd64 snapshot.
>> 
>> When I turn on ipcomp, https/imaps hangs for most connections; when I turn 
>> ipcomp off, https/imaps works.
> 
> I can confirm this behavior.  I've set up a simple RSA key VPN as
> described at http://www.openbsd.org/faq/faq17.html#site2site, which
> does not include ipcomp by default, and everything works fine,
> including https.  After reading this I decided to test enabling
> ipcomp, and sure enough, loading an https page across the VPN fails.
> With ipcomp I also see some "unprotected" packets when running tcpdump
> on enc0, e.g.:
> 13:32:19.600062 (authentic,confidential): SPI 0xee345270:
> 10.95.10.236.57254 > 10.95.0.233.443: P 273:518(245) ack 5604 win 455
>  (DF) (encap)
> 13:32:19.614996 (unprotected): SPI 0x5a04: 10.95.0.233.443 >
> 10.95.10.236.57254: . 5604:7052(1448) ack 518 win 252  timestamp 61011950 1069884950> (DF) (encap)
> 
> I don't know why that is happening, but as everything seems to work
> well and perform decently without ipcomp, I'll be leaving it disabled.
> 
>> I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing 
>> this is the code that is involved) in the log (I think) was about 3 months 
>> ago, and at this point, I can't recall if my last updated (prior to the one 
>> where the instability began) was before or after that change.
>> 
>> I was going to try to recompile it with the change undone, but am not sure 
>> how to do that, or even if it can be done for just that one part of sys.
> 
> Yes, just use git or cvs (whatever you checked out the code with) to
> fetch an earlier revision of that file (not the whole repo) and then
> build a new kernel.  Sometimes you'd need to also revert other related
> changes, but that does not appear to be the case here, assuming you're
> referring to [1].  Note that some previous commits did touch multiple
> files.
> 
>> And, after removing ipcomp from iked.conf, my subjective observation is that 
>> things load a lot faster than they seemed to in the past with ipcomp on; so, 
>> I am happy with where I am.
>> 
>> I was just posting my observations in case anyone else has a similar issue.
> 
> Thank you for sharing.  I had (I think) been using ipcomp in my old
> ikev1 (ipsec.conf/isakmpd) setup but had not yet gotten around to
> enabling it in the ikev2 setup.  Based on this, I won't bother.
> 
> 
> -Andrew
> 
> [1] https://github.com/openbsd/src/commit/4b5fa55
>

Re: TLS suddenly not working over IKED site-to-site - SOLVED?

2019-03-14 Thread Andrew Daugherity 
On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko  wrote:
> Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, 
> https (and imaps) were working without an issue from openbsd, Windows 7, and 
> Macs!
>
> Just to be sure, I updated this am to the 12/19 amd64 snapshot.
>
> When I turn on ipcomp, https/imaps hangs for most connections; when I turn 
> ipcomp off, https/imaps works.

I can confirm this behavior.  I've set up a simple RSA key VPN as
described at http://www.openbsd.org/faq/faq17.html#site2site, which
does not include ipcomp by default, and everything works fine,
including https.  After reading this I decided to test enabling
ipcomp, and sure enough, loading an https page across the VPN fails.
With ipcomp I also see some "unprotected" packets when running tcpdump
on enc0, e.g.:
13:32:19.600062 (authentic,confidential): SPI 0xee345270:
10.95.10.236.57254 > 10.95.0.233.443: P 273:518(245) ack 5604 win 455
 (DF) (encap)
13:32:19.614996 (unprotected): SPI 0x5a04: 10.95.0.233.443 >
10.95.10.236.57254: . 5604:7052(1448) ack 518 win 252  (DF) (encap)

I don't know why that is happening, but as everything seems to work
well and perform decently without ipcomp, I'll be leaving it disabled.

> I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this 
> is the code that is involved) in the log (I think) was about 3 months ago, 
> and at this point, I can't recall if my last updated (prior to the one where 
> the instability began) was before or after that change.
>
> I was going to try to recompile it with the change undone, but am not sure 
> how to do that, or even if it can be done for just that one part of sys.

Yes, just use git or cvs (whatever you checked out the code with) to
fetch an earlier revision of that file (not the whole repo) and then
build a new kernel.  Sometimes you'd need to also revert other related
changes, but that does not appear to be the case here, assuming you're
referring to [1].  Note that some previous commits did touch multiple
files.

> And, after removing ipcomp from iked.conf, my subjective observation is that 
> things load a lot faster than they seemed to in the past with ipcomp on; so, 
> I am happy with where I am.
>
> I was just posting my observations in case anyone else has a similar issue.

Thank you for sharing.  I had (I think) been using ipcomp in my old
ikev1 (ipsec.conf/isakmpd) setup but had not yet gotten around to
enabling it in the ikev2 setup.  Based on this, I won't bother.


-Andrew

[1] https://github.com/openbsd/src/commit/4b5fa55

Re: TLS suddenly not working over IKED site-to-site - SOLVED?

2018-12-20 Thread Theodore Wynnychenko 
> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of William Ahern 
> Sent: Monday, December 17, 2018 1:11 PM 
> To: Theodore Wynnychenko 
> Cc: misc@openbsd.org 
> Subject: Re: TLS suddenly not working over IKED site-to-site 
> 
. 
. 
. 
> I'm not well versed in these issues but if I were in your shoes I would 
> 
> 1) Figure out why those packets were unprotected. (Could be normal for 
> all I 
> know, but in a quick test on my enc0 I didn't see any packets like 
> that.) 
> 
> 2) Make sure the tunnel handles fragmentation correctly. Are fragments 
> being 
> dropped? Are reassembled fragments being dropped? 
> 
> 2.a) Relatedly, make sure the tunnel handles pMTU discovery. Do ICMP 
> Fragmentation Needed packets make it back through the tunnel? pMTU and 
> ICMP 
> issues are very common with IPSec tunnels. IME most people "fix" these 
> issues by forcing a lower MSS or setting a lower MTU at the ingress 
> point 
> rather than properly configuring routing so ICMP errors are properly 
> routed. 
> I've experienced this issue myself and had to learn the hard way. 
> 
> 3) From an earlier post it looks like you're using ipcomp. You should 
> remove 
> this complication while debugging. It's possible ipcomp is hiding MTU 
> issues. 


Thank you so much for the suggestions. 

To summarize, I have noticed that in the last month, SSL/TLS connections were 
failing when traversing an ipsec tunnel created by iked.

This had worked stably for over a year, with no changes to iked.conf or 
pf.conf. 

In trying to find the issue, I had added "max-mss" to pf and tried decreasing 
MTU values on the adapters.  This did not seem to make a difference.

In addition, the problem was very sporadic, and seemed to "evolve" over the 
last few weeks.  In the last few days, I was able to establish https 
connections over the tunnel when that connection was initiated by the gateway 
openbsd machine or a Mac on the "local" network; but connections from another 
openbsd machine "behind" the gateway, and a Windows 7 machine kept hanging.

Anyway, I decided to revert everything to the way it was.  I removed all 
"max-mss" entries and reset MTU values to 1500.

Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, 
https (and imaps) were working without an issue from openbsd, Windows 7, and 
Macs!

Just to be sure, I updated this am to the 12/19 amd64 snapshot. 

When I turn on ipcomp, https/imaps hangs for most connections; when I turn 
ipcomp off, https/imaps works. 

I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this 
is the code that is involved) in the log (I think) was about 3 months ago, and 
at this point, I can't recall if my last updated (prior to the one where the 
instability began) was before or after that change.

I was going to try to recompile it with the change undone, but am not sure how 
to do that, or even if it can be done for just that one part of sys.

And, after removing ipcomp from iked.conf, my subjective observation is that 
things load a lot faster than they seemed to in the past with ipcomp on; so, I 
am happy with where I am.

I was just posting my observations in case anyone else has a similar issue. 

Ted

Re: TLS suddenly not working over IKED site-to-site

2018-12-17 Thread William Ahern 
On Sat, Dec 15, 2018 at 06:18:39PM -0600, Theodore Wynnychenko wrote:

> On the local gateway: 
> 
> 17:37:00.199269 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: S 3823001077:3823001077(0) win 16384  1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 48604571 0> (encap)
> 
> 17:37:00.235313 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
> 172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 730029501 48604571> (DF) 
> (encap)
> 
> 17:37:00.235335 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: . ack 1 win 256  
> (encap)
> 
> 17:37:00.236086 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
> 172.30.6.201.443: P 1:197(196) ack 1 win 256  730029501> (encap)
> 
> 17:37:01.726509 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
> 172.30.6.201.443: P 1:197(196) ack 1 win 256  730029501> (encap)
> 
> 17:37:04.726571 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
> 172.30.6.201.443: P 1:197(196) ack 1 win 256  730029501> (encap)

This looks odd to me. Why unprotected?
 
> 17:37:10.726697 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
> 172.30.6.201.443: FP 1:197(196) ack 1 win 256  730029516> (encap)
> 
> 17:37:11.724643 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
> 172.30.1.20.20692: F 1:1(0) ack 1 win 271  48604571> (DF) (encap)
> 
> 17:37:11.724680 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: F 197:197(0) ack 2 win 256  730029524> (encap)
> 
> 17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
> 172.30.1.20.20692: . ack 1 win 271  
> (DF) (encap)

Packet fragmentation is something to investigate.
 
> 
> But, tcpdump of enc0 on the remote gateway only shows: 
> 
> 17:37:00.207517 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: S 3823001077:3823001077(0) win 16384  1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 48604571 0> (encap)
> 
> 17:37:00.207551 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
> 172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 730029501 48604571> (DF) 
> (encap)
> 
> 17:37:00.244461 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: . ack 1 win 256  
> (encap)
> 
> 17:37:07.792702 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
> 172.30.6.201.443: F 197:197(0) ack 1 win 256  730029501> (encap)
> 
> 17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
> 172.30.1.20.20692: . ack 1 win 271  48604571,nop,nop,sack 1 {197:197} > (DF) (encap)
 
> Needless to say, if I try these connections WITHOUT traversing the iked
> vpn, the openssl s_client to s_server connection works as expected.
> 
> Not being in any way an expert on these things, I cannot understand why
> "regular" tcp packets are able to traverse the VPN and emerge on the other
> side, while tcp pakets to the same port attempting to establish a secure
> connection are lost. Why are the tcp PUSH data packets that leave the
> local gateway on enc0 never seen on the remote gateway's ecn0?
> 
> I am really hoping that somebody has some sort idea of what I can do to
> fix whatever it is that I have broken. I will be happy to send more
> specific information, I just don't know what that might be.

I'm not well versed in these issues but if I were in your shoes I would

1) Figure out why those packets were unprotected. (Could be normal for all I
know, but in a quick test on my enc0 I didn't see any packets like that.)

2) Make sure the tunnel handles fragmentation correctly. Are fragments being
dropped? Are reassembled fragments being dropped?

2.a) Relatedly, make sure the tunnel handles pMTU discovery. Do ICMP
Fragmentation Needed packets make it back through the tunnel? pMTU and ICMP
issues are very common with IPSec tunnels. IME most people "fix" these
issues by forcing a lower MSS or setting a lower MTU at the ingress point
rather than properly configuring routing so ICMP errors are properly routed.
I've experienced this issue myself and had to learn the hard way.

3) From an earlier post it looks like you're using ipcomp. You should remove
this complication while debugging. It's possible ipcomp is hiding MTU
issues.

Re: TLS suddenly not working over IKED site-to-site

2018-12-15 Thread Theodore Wynnychenko 
Hello again: 

I updated my iked endpoints to the most recent (12/14/18) amd64 snapshot today, 
and am still having problems with secure connections.

So, today, I am just looking at the gateway machines. 

The iked vpn tunnel gets established without an issue. 

# ipsecctl -s all 
FLOWS: 
flow esp in from xx.xx.xx.xx to 172.30.1.20 peer xx.xx.xx.xx srcid FQDN/x.x.x 
dstid FQDN/x.x.x type use 
flow ipcomp in from 172.30.6.0/23 to 172.30.0.0/22 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type use 
flow ipcomp out from 172.30.0.0/22 to 172.30.6.0/23 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type require 
flow esp out from 172.30.1.20 to xx.xx.xx.xx peer xx.xx.xx.xx srcid FQDN/x.x.x 
com dstid FQDN/x.x.x type require 

SAD: 
ipcomp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x54ab comp deflate 
ipcomp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0x8bf1 comp deflate 
esp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x0934ef93 auth hmac-sha2-256 
enc aes-256 
esp transport from xx.xx.xx.xx to 172.30.1.20 spi 0x29a95d18 auth hmac-sha2-256 
enc aes-256 
esp transport from 172.30.1.20 to xx.xx.xx.xx spi 0x7b90f84c auth hmac-sha2-256 
enc aes-256 
esp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0xa9238cfb auth hmac-sha2-256 
enc aes-256 


I have also added "set skip on { lo enc0 }" to pf.conf on both gateways (trying 
to take that out of the equation). 


If, on the remote gateway I run: 
# nc -l https 

Then, when, on the local gateway I run: 
# nc remote.gateway https 
(( and enter "some text" and  )) 

On the remote gateway I see: 
"some text" 

OK, traffic is flowing from one to the other and allowed on https.  Right? 

If I run s_server on the remote gateway: 
# openssl s_server -state -accept https -CAfile /etc/ssl/cert.pem -cert 
/etc/ssl/server.crt -key /etc/ssl/private/server.key

The s_server starts: 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 

When I try connecting with s_client on the local gateway: 
# openssl s_client -state -connect remote.gateway:https 

All I see is: 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 


And there is no output on the server side (the remote gateway). 

At the same time, tcpdump of enc0 shows: 

On the local gateway: 

17:37:00.199269 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.235313 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.235335 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:00.236086 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:01.726509 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:04.726571 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:07.777123 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.820525 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)

17:37:10.726697 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: FP 1:197(196) ack 1 win 256  (encap)

17:37:11.724643 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: F 1:1(0) ack 1 win 271  (DF) (encap)

17:37:11.724680 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 2 win 256  (encap)

17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) 
(encap)


But, tcpdump of enc0 on the remote gateway only shows: 

17:37:00.207517 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.207551 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.244461 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:07.792702 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)


Needless to say, if I try these connections WITHOUT traversing the iked vpn, 
the openssl s_client to s_server connection works as expected.

Not being in any way an expert on these things, I cannot understand why 
"regular" tcp packets are able to traverse the VPN and emerge on the other 
side, while tcp pakets to the same port attempting to establish a secure 
co

Re: TLS suddenly not working over IKED site-to-site

2018-12-15 Thread Zhi-Qiang Lei 
roup 
> curve25519 \
>childsa enc chacha20-poly130 group curve25519 \
>dstid "asgard.local"
> 
> Sites are reachable by ping, but https doesn’t respond at all. I was 
> wondering if it is because the GRE part, will do more experiments.
> 
>> On Dec 11, 2018, at 9:04 AM, Theodore Wynnychenko  wrote:
>> 
>> I would like to re-title this as something like "pf and iked instability on 
>> recent snapshots," but don’t know if doing so would break the mailing list 
>> thread, exiso, I left the subject unchanged...
>> 
>>> -----Original Message- 
>>> From: Theodore Wynnychenko [mailto:t...@uchicago.edu] 
>>> Sent: Saturday, December 08, 2018 4:03 PM 
>>> To: misc@openbsd.org 
>>> Cc: 'Rachel Roch' 
>>> Subject: RE: TLS suddenly not working over IKED site-to-site 
>>> 
>>>> 
>> . 
>> . 
>> . 
>>> I now find I can no longer connect to with TLS/SSL over the iked tunnel 
>>> (the original behavior that seemed to have corrected itself).  Also, 
>>> icinga continues to be unable to verify the status of the remote hosts 
>>> over port 5665. 
>>> 
>>> I don't have time right now to try using s_client and s_server and 
>>> watching enc0 to see what is happening, but I will when I can. 
>>> 
>>> If anyone has an ideas on what may be happening, please let me know. 
>>> 
>>> Thanks 
>>> Ted 
>> 
>> 
>> Hello again; 
>> 
>> So, I am at a complete loss to understand what is going on. 
>> Today, I tried using openssl s_client and s_server to make a connection 
>> through the iked vpn (as I described in my last post).  However, with NO 
>> changes to iked.conf or pf.conf, today I had several connection attempts 
>> that completed correctly.  I have not included any output from those 
>> sporadic, completely functional connections.
>> 
>> Rather, today, most of the connections by s_client are not even acknowledged 
>> by the s_server on the other side of the iked vpn.
>> 
>> For example: 
>> On the s_client machine: 
>> 
>> # openssl s_client -state -connect "remote.host":https 
>> SSL_connect:before/connect initialization 
>> SSL_connect:SSLv3 write client hello A 
>> ... and nothing more ... 
>> 
>> But on the s_server machine today all I see is: 
>> # openssl s_sever -state -accept https ...certificate options... 
>> Using auto DH parameters 
>> Using default temp ECDH parameters 
>> ACCEPT 
>> ... and no connection attempt is ever acknowledged ... 
>> 
>> (Yesterday, at least this first part of the connection was received by the 
>> s_server: 
>> Using auto DH parameters 
>> Using default temp ECDH parameters 
>> ACCEPT 
>> SSL_accept:before/accept initialization 
>> ... and nothing more yesterday ...) 
>> 
>> 
>> So, today using tcpdump on the outgoing interface of the s_client machine 
>> and the incoming interface of the "local" iked vpn endpoint shows:
>> 
>> 16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S 
>> 1751796302:1751796302(0) win 16384 > 6,nop,nop,timestamp 2698316052 0>
>> 
>> 16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 
>> 256 
>> 
>> 16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 
>> 
>> 16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 
>> 
>> 16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 
>> 
>> 16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 
>> 256 
>> 
>> 16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 
>> win 256 
>> 
>> And this traffic (incomplete thought it may be for an ssl handshake) appears 
>> to be passed to enc0 intact: 
>> 
>> 16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 
>> > 172.30.7.205.443: S 3570513915:3570513915(0) win 16384 > 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 2698316052 0> (encap)
>> 
>> 16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
>> 172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384 > 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3536824996 2698316052> 
>> (encap)
>> 
>> 16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 
>> > 172.30.7.205.443: . ac

Re: TLS suddenly not working over IKED site-to-site

2018-12-13 Thread Zhi-Qiang Lei 
I’m having the same issue on OpenBSD 6.4. My iked.conf is similar to Rachel’s:

include "/etc/iked/macros.conf"

ikev2 quick active ipcomp esp proto gre\
from 192.168.1.0/24 to $iked_server \
local egress peer $iked_server \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 
\
childsa enc chacha20-poly130 group curve25519 \
dstid "asgard.local"

Sites are reachable by ping, but https doesn’t respond at all. I was wondering 
if it is because the GRE part, will do more experiments.

> On Dec 11, 2018, at 9:04 AM, Theodore Wynnychenko  wrote:
> 
> I would like to re-title this as something like "pf and iked instability on 
> recent snapshots," but don’t know if doing so would break the mailing list 
> thread, exiso, I left the subject unchanged...
> 
>> -Original Message- 
>> From: Theodore Wynnychenko [mailto:t...@uchicago.edu] 
>> Sent: Saturday, December 08, 2018 4:03 PM 
>> To: misc@openbsd.org 
>> Cc: 'Rachel Roch' 
>> Subject: RE: TLS suddenly not working over IKED site-to-site 
>> 
>>> 
> . 
> . 
> . 
>> I now find I can no longer connect to with TLS/SSL over the iked tunnel 
>> (the original behavior that seemed to have corrected itself).  Also, 
>> icinga continues to be unable to verify the status of the remote hosts 
>> over port 5665. 
>> 
>> I don't have time right now to try using s_client and s_server and 
>> watching enc0 to see what is happening, but I will when I can. 
>> 
>> If anyone has an ideas on what may be happening, please let me know. 
>> 
>> Thanks 
>> Ted 
> 
> 
> Hello again; 
> 
> So, I am at a complete loss to understand what is going on. 
> Today, I tried using openssl s_client and s_server to make a connection 
> through the iked vpn (as I described in my last post).  However, with NO 
> changes to iked.conf or pf.conf, today I had several connection attempts that 
> completed correctly.  I have not included any output from those sporadic, 
> completely functional connections.
> 
> Rather, today, most of the connections by s_client are not even acknowledged 
> by the s_server on the other side of the iked vpn.
> 
> For example: 
> On the s_client machine: 
> 
> # openssl s_client -state -connect "remote.host":https 
> SSL_connect:before/connect initialization 
> SSL_connect:SSLv3 write client hello A 
> ... and nothing more ... 
> 
> But on the s_server machine today all I see is: 
> # openssl s_sever -state -accept https ...certificate options... 
> Using auto DH parameters 
> Using default temp ECDH parameters 
> ACCEPT 
> ... and no connection attempt is ever acknowledged ... 
> 
> (Yesterday, at least this first part of the connection was received by the 
> s_server: 
> Using auto DH parameters 
> Using default temp ECDH parameters 
> ACCEPT 
> SSL_accept:before/accept initialization 
> ... and nothing more yesterday ...) 
> 
> 
> So, today using tcpdump on the outgoing interface of the s_client machine and 
> the incoming interface of the "local" iked vpn endpoint shows:
> 
> 16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S 
> 1751796302:1751796302(0) win 16384  6,nop,nop,timestamp 2698316052 0>
> 
> 16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 
> 256 
> 
> 16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
> 256 
> 
> 16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
> 256 
> 
> 16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
> 256 
> 
> 16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 
> 256 
> 
> 16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 win 
> 256 
> 
> And this traffic (incomplete thought it may be for an ssl handshake) appears 
> to be passed to enc0 intact: 
> 
> 16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
> 172.30.7.205.443: S 3570513915:3570513915(0) win 16384  1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 2698316052 0> (encap)
> 
> 16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
> 172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384  1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3536824996 2698316052> 
> (encap)
> 
> 16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
> 172.30.7.205.443: . ack 1 win 256  
> (encap)
> 
> 16:43:05.147365 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
> 172.30.7.205.443: P

Re: TLS suddenly not working over IKED site-to-site

2018-12-10 Thread Theodore Wynnychenko 
I would like to re-title this as something like "pf and iked instability on 
recent snapshots," but don’t know if doing so would break the mailing list 
thread, exiso, I left the subject unchanged...

> -Original Message- 
> From: Theodore Wynnychenko [mailto:t...@uchicago.edu] 
> Sent: Saturday, December 08, 2018 4:03 PM 
> To: misc@openbsd.org 
> Cc: 'Rachel Roch' 
> Subject: RE: TLS suddenly not working over IKED site-to-site 
> 
> > 
. 
. 
. 
> I now find I can no longer connect to with TLS/SSL over the iked tunnel 
> (the original behavior that seemed to have corrected itself).  Also, 
> icinga continues to be unable to verify the status of the remote hosts 
> over port 5665. 
> 
> I don't have time right now to try using s_client and s_server and 
> watching enc0 to see what is happening, but I will when I can. 
> 
> If anyone has an ideas on what may be happening, please let me know. 
> 
> Thanks 
> Ted 


Hello again; 

So, I am at a complete loss to understand what is going on. 
Today, I tried using openssl s_client and s_server to make a connection through 
the iked vpn (as I described in my last post).  However, with NO changes to 
iked.conf or pf.conf, today I had several connection attempts that completed 
correctly.  I have not included any output from those sporadic, completely 
functional connections.

Rather, today, most of the connections by s_client are not even acknowledged by 
the s_server on the other side of the iked vpn.

For example: 
On the s_client machine: 

# openssl s_client -state -connect "remote.host":https 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
... and nothing more ... 

But on the s_server machine today all I see is: 
# openssl s_sever -state -accept https ...certificate options... 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
... and no connection attempt is ever acknowledged ... 

(Yesterday, at least this first part of the connection was received by the 
s_server: 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
SSL_accept:before/accept initialization 
... and nothing more yesterday ...) 


So, today using tcpdump on the outgoing interface of the s_client machine and 
the incoming interface of the "local" iked vpn endpoint shows:

16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S 
1751796302:1751796302(0) win 16384 

16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 256 


16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 
256 

16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 win 
256 

And this traffic (incomplete thought it may be for an ssl handshake) appears to 
be passed to enc0 intact: 

16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: S 3570513915:3570513915(0) win 16384  (encap)

16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384  
(encap)

16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: . ack 1 win 256  
(encap)

16:43:05.147365 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:06.645932 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:09.646049 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:09.945908 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: F 197:197(0) ack 1 win 256  (encap)

16:43:09.981966 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: . ack 1 win 261  (encap)

16:43:15.646158 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: FP 1:197(196) ack 1 win 256  (encap)


BUT, at the other end of the VPN, on enc0, all that is seen leaving the iked 
VPN tunnel is: 

16:43:05.130558 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: S 3570513915:3570513915(0) win 16384  (encap)

16:43:05.131049 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384  
(encap)

16:43:05.174802 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: . ack 1 win 256  
(encap)

16:43:09.966420 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: F 197:197(0) ack

Re: TLS suddenly not working over IKED site-to-site

2018-12-08 Thread Theodore Wynnychenko 
> 
> > Rachel, 
> > 
> > As a first step, try using s_client to connect to a TLS service and 
> see what comes back: 
> > 
> > $ openssl s_client -connect : -showcerts 
> > 
> > There are more possible options on s_client to debug more deeply but 
> this is a good start. 
> > 
> > 
> > --Paul 
> > 
> 
> In answer to the above. Testing against three "random" servers  (see 
> bottom of the email for full exchange, top three are through VPN, rest 
> are bypassing VPN): 
> 


I wanted to follow up on this. 

I updated the servers that create the iked VPN to the 12/5 snapshot the other 
day. 

I then took one machine on the "remote" net and ran openssl s_server. 
I had another machine on the "local" net try to connect with openssl s_client. 

So, the s_client shows: 

SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
... and nothing more. 

The s_server shows: 

Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
SSL_accept:before/accept initialization 
... and nothing more. 

I also had tcpdump running at several places along the route. 

On the outgoing/sending interface of the "s_client" machine I see: 

21:19:54.735257 172.30.1.254.44715 > 172.30.7.205.443: S 950714671:950714671(0) 
win 16384  
(DF)

21:19:54.773320 172.30.7.205.443 > 172.30.1.254.44715: S 668125506:668125506(0) 
ack 950714672 win 16384 

21:19:54.773391 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 (DF) 
21:19:54.774143 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:56.272544 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:59.272615 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:20:05.272786 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256 

21:20:10.743468 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.781912 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.124726 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.124786 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.162326 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 
21:20:17.273069 172.30.1.254.44715 > 172.30.7.205.443: FP 1:197(196) ack 2 win 
256  (DF)


On the incoming/receiving interface of the "local" iked machine I see: 

21:19:54.737490 172.30.1.254.44715 > 172.30.7.205.443: S 950714671:950714671(0) 
win 16384  
(DF)

21:19:54.775299 172.30.7.205.443 > 172.30.1.254.44715: S 668125506:668125506(0) 
ack 950714672 win 16384 

21:19:54.775625 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 (DF) 
21:19:54.776378 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:56.274790 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:59.274859 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:20:05.275017 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256 

21:20:10.745731 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.783860 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.126709 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.127041 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.164312 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


But, on the outgoing/sending interface of the "remote" iked machine, all that I 
see is: 

21:19:54.733973 172.30.1.254.44715 > 172.30.7.205.443: S 
4173630539:4173630539(0) win 16384 

21:19:54.734355 172.30.7.205.443 > 172.30.1.254.44715: S 
2645985599:2645985599(0) ack 4173630540 win 16384 

21:19:54.773048 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 
21:20:10.742843 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.743111 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.085788 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.123252 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.123472 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


And that is all that gets delivered to the incoming/receiving interface of the 
"s_server" machine: 

21:19:54.710031 172.30.1.254.44715 > 172.30.7.205.443: S 
4173630539:4173630539(0) win 16384 

21:19:54.710134 172.30.7.205.443 > 172.30.1.254.44715: S 
2645985599:2645985599(0) ack 4173630540 win 16384 

21:19:54.749110 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 
21:20:10.718972 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.719023 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.061678 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.099433 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.099484 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


Now, if I try connecting using

Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Paul Suh 


> On Dec 3, 2018, at 12:18 PM, Rachel Roch  wrote:
> 
> I hope someone here can shed light on an infuriating problem I’ve spent a 
> week trying to resolve without luck.
> 
> The problem concerns an IKED site-to-site VPN on OpenBSD 6.3 (both endpoints 
> fully syspatched).
> 
> The VPN worked absolutely perfectly until it suddenly started behaving 
> strangely.  Seriously, I’m talking about “pass any traffic you can think of”, 
> then I go on holiday for a week (nobody else has physical or remote access to 
> the machines, and I did not connect on holiday), then this behaviour starts.
> 
> Basically the behaviour I am seeing is that anything that uses TLS is no 
> longer able to connect (or at least gets no further than trying to do a TLS 
> handshake, e.g. Firefox hangs showing "performing TLS handshake..." at the 
> bottom of the screen), so that means:
> 
> - HTTPS websites
> - VoIP
> - IMAP over TLS
> - RDP over TLS
> 
> Are all broken on the VPN, but all TLS-based services continue to work 
> perfectly off-site (or when the site-to-site VPN is bypassed with a 
> third-party VPN).  This impacts multiple servers and multiple clients, so its 
> not just one server or one desktop PC, its anything that tries to talk TLS 
> over that VPN !
> 
> 
> However:
> - Ping (including large packet size, e.g. “-s 1600”)
> - SSH
> - DNS
> - Anything else you care to name that doesn’t use TLS
> 
> All continue to work perfectly over the VPN.
> 
> My PF rules (which cannot possibly be the problem, because they have not 
> changed a single bit between “working” and “not working) don’t even 
> differentiate between traffic types, so it can’t be some sudden PF oddity :
> 
> pass in on enc from  to  keep state (if-bound) 
> $midPriority
> pass out on enc from  to  keep state (if-bound) 
> $midPriority
> 
> Similarly, my IKED config is also completely unchanged between "working" and 
> "not working", and ipsecctl -sa continues to show everything correctly 
> established
> 
> ikev2 "to remote" active esp from $a_net to $b_net\
> local $local_ext peer $remote_ext \
> ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group 
> curve25519 \
> childsa enc chacha20-poly1305 group curve25519 \
> srcid $local_ext dstid $remote_ext \
> ikelifetime 4h lifetime 3h bytes 512M \
> ecdsa384
> 
> 
> This whole thing is just driving me crazy !
> 

Rachel, 

As a first step, try using s_client to connect to a TLS service and see what 
comes back: 

$ openssl s_client -connect : -showcerts

There are more possible options on s_client to debug more deeply but this is a 
good start. 


--Paul




smime.p7s
Description: S/MIME cryptographic signature

Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch 



> Rachel,
>
> As a first step, try using s_client to connect to a TLS service and see what 
> comes back:
>
> $ openssl s_client -connect : -showcerts
>
> There are more possible options on s_client to debug more deeply but this is 
> a good start.
>
>
> --Paul
>

In answer to the above. Testing against three "random" servers  (see bottom of 
the email for full exchange, top three are through VPN, rest are bypassing VPN):

Through the VPN:
- Server "A" (HTTPS with "real" cert)- Nothing more than "CONNECTED (0005)"
- Server "B" (HTTPS with "self-signed" cert)- Certificates get displayed (this 
correlates with behaviour seen in browser where I get shown the "do you want to 
continue" prompt, I can see details of the certs presented, but when I click 
continue it hangs)
- Server "C" (IMAPS) - Nothing more than "CONNECTED (0005)"

Bypassing the VPN:
- Server A shows certs in openssl(and browser works ok)- Server "C" shows certs 
in openssl (and email client works ok)

foobarOVERVPN $ openssl s_client -connect web1.example.com:443 -showcerts
CONNECTED(0005)
^C
foobarOVERVPN $ openssl s_client -connect web2.example.com:8443 -showcerts
CONNECTED(0005)
depth=0 C = US, ST = CA, L = San Jose, O = example.com, OU = MyCorp, CN = MyCorp
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = San Jose, O = example.com, OU = MyCorp, CN = MyCorp
verify return:1
---
Certificate chain
0 s:/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

   i:/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

-BEGIN CERTIFICATE-

-END CERTIFICATE-
---
Server certificate
subject=/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

issuer=/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1316 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 5C0575730056006E28542F880C1AB6541729337C0DDBEC95347E2B5B4669EAD7
    Session-ID-ctx:
    Master-Key: 
66B8EB1A3FB0857509627840D8DDB595659A5794D365D462DED737AAD4532F4AD542663B8BAE27A7665539D15C14ADEA
    Start Time: 1543861619
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---
^C

foobarOVERVPN $ openssl s_client -connect imaps.example.com:993 -showcerts
CONNECTED(0005)
^C
foobarBYPASSVPN $ openssl s_client -connect web1.example.com:443 -showcerts
CONNECTED(0005)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN 
= COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN 
= COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = web1.example.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=web1.example.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
-BEGIN CERTIFICATE-

-END CERTIFICATE-
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Certification Authority
-BEGIN CERTIFICATE-

-END CERTIFICATE-
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-BEGIN CERTIFICATE-

-END CERTIFICATE-
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-BEGIN CERTIFICATE-

-END CERTIFICATE-
---
Server certificate
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=web1.example.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 6299 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 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: 6D5EC20FC1493D55F28309A02B1B589268F251D625A7EB3

Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Theodore Wynnychenko 



> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Rachel Roch 
> Sent: Monday, December 03, 2018 11:19 AM 
> To: misc@openbsd.org 
> Subject: TLS suddenly not working over IKED site-to-site 
> 
> I hope someone here can shed light on an infuriating problem I’ve spent 
> a week trying to resolve without luck. 
> 
> The problem concerns an IKED site-to-site VPN on OpenBSD 6.3 (both 
> endpoints fully syspatched). 
. 
. 
. 
> 
> 
> This whole thing is just driving me crazy ! 


Hello, 
This appears to be the same thing I have been having issues with and mentioned 
in a post to misc last week ("Untable ssl connections over ikev2 VPN") - (yes, 
typo intact - it should be "unstable").

I have tried adding a "max-mss 1300" directive into pf.conf (i.e.: "match in 
all scrub (no-df random-id max-mss 1300)").

At first, I _thought_ this made a difference, but I am not sure if that is 
really true. 

I have also noticed that the TLS failures seem to vary based on OS.  At this 
point, I was able to get an https connection to work with firefox on MacOS, but 
the TLS handshake continues to hang (100% of the time) with firefox on a 
Windows 7 PC.  With an openBSD laptop, it seems like it sometimes works and 
sometimes doesn't (using "openssl s_client" to test).

I also made no changes in pf.conf or iked.conf from the working to non-working 
period. 

I have no idea what to do; I am just posting my observations if that helps. 
Thanks

Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch 



>
> Hello, 
> This appears to be the same thing I have been having issues with and 
> mentioned in a post to misc last week ("Untable ssl connections over ikev2 
> VPN") - (yes, typo intact - it should be "unstable").
>
> I have tried adding a "max-mss 1300" directive into pf.conf (i.e.: "match in 
> all scrub (no-df random-id max-mss 1300)").
>
> At first, I _thought_ this made a difference, but I am not sure if that is 
> really true. 
>
> I have also noticed that the TLS failures seem to vary based on OS.  At this 
> point, I was able to get an https connection to work with firefox on MacOS, 
> but the TLS handshake continues to hang (100% of the time) with firefox on a 
> Windows 7 PC.  With an openBSD laptop, it seems like it sometimes works and 
> sometimes doesn't (using "openssl s_client" to test).
>
> I also made no changes in pf.conf or iked.conf from the working to 
> non-working period. 
>
> I have no idea what to do; I am just posting my observations if that helps. 
> Thanks
>

Hi,

Glad its just not me !!! Even if you don't know the fix, at least I now know I 
haven't gone completely crazy !

For me it more consistent, on OSX its 100% hang, on Windows 10 its 100% hang.  
Haven't tried OpenBSD client yet, I've been too busy putting emergency 
workarounds in place to bypass the site-to-site stuff. Will try OpenBSD client 
though when I get a chance.

Appreciate you taking the time to email ... keep in touch !

TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch 
I hope someone here can shed light on an infuriating problem I’ve spent a week 
trying to resolve without luck.

The problem concerns an IKED site-to-site VPN on OpenBSD 6.3 (both endpoints 
fully syspatched).

The VPN worked absolutely perfectly until it suddenly started behaving 
strangely.  Seriously, I’m talking about “pass any traffic you can think of”, 
then I go on holiday for a week (nobody else has physical or remote access to 
the machines, and I did not connect on holiday), then this behaviour starts.

Basically the behaviour I am seeing is that anything that uses TLS is no longer 
able to connect (or at least gets no further than trying to do a TLS handshake, 
e.g. Firefox hangs showing "performing TLS handshake..." at the bottom of the 
screen), so that means:

- HTTPS websites
- VoIP
- IMAP over TLS
- RDP over TLS

Are all broken on the VPN, but all TLS-based services continue to work 
perfectly off-site (or when the site-to-site VPN is bypassed with a third-party 
VPN).  This impacts multiple servers and multiple clients, so its not just one 
server or one desktop PC, its anything that tries to talk TLS over that VPN !


However:
- Ping (including large packet size, e.g. “-s 1600”)
- SSH
- DNS
- Anything else you care to name that doesn’t use TLS

All continue to work perfectly over the VPN.

My PF rules (which cannot possibly be the problem, because they have not 
changed a single bit between “working” and “not working) don’t even 
differentiate between traffic types, so it can’t be some sudden PF oddity :

pass in on enc from  to  keep state (if-bound) 
$midPriority
pass out on enc from  to  keep state (if-bound) 
$midPriority

Similarly, my IKED config is also completely unchanged between "working" and 
"not working", and ipsecctl -sa continues to show everything correctly 
established

ikev2 "to remote" active esp from $a_net to $b_net\
    local $local_ext peer $remote_ext \
    ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 
\
    childsa enc chacha20-poly1305 group curve25519 \
    srcid $local_ext dstid $remote_ext \
    ikelifetime 4h lifetime 3h bytes 512M \
    ecdsa384


This whole thing is just driving me crazy !