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 0x000054ab comp deflate
ipcomp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0x00008bf1 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 <CR> ))
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(00000003)
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 <mss
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 <mss
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 <nop,nop,timestamp 48604571 730029501> (encap)
17:37:00.236086 (unprotected): SPI 0x000054ab: 172.30.1.20.20692 >
172.30.6.201.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 48604571
730029501> (encap)
17:37:01.726509 (unprotected): SPI 0x000054ab: 172.30.1.20.20692 >
172.30.6.201.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 48604574
730029501> (encap)
17:37:04.726571 (unprotected): SPI 0x000054ab: 172.30.1.20.20692 >
172.30.6.201.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 48604580
730029501> (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 <nop,nop,timestamp 48604586
730029501> (encap)
17:37:07.820525 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
172.30.1.20.20692: . ack 1 win 271 <nop,nop,timestamp 730029516
48604571,nop,nop,sack 1 {197:197} > (DF) (encap)
17:37:10.726697 (unprotected): SPI 0x000054ab: 172.30.1.20.20692 >
172.30.6.201.443: FP 1:197(196) ack 1 win 256 <nop,nop,timestamp 48604592
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 <nop,nop,timestamp 730029524
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 <nop,nop,timestamp 48604594
730029524> (encap)
17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
172.30.1.20.20692: . ack 1 win 271 <nop,nop,timestamp 730029524 48604571> (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 <mss
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 <mss
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 <nop,nop,timestamp 48604571 730029501> (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 <nop,nop,timestamp 48604586
730029501> (encap)
17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
172.30.1.20.20692: . ack 1 win 271 <nop,nop,timestamp 730029516
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.
Thanks again
Ted
