Hi,

This issue varies to different destinations on my side. I cannot browse 
www.google.com <http://www.google.com/> and twitter.com <http://twitter.com/> 
and www.facebook.com <http://www.facebook.com/> (and possibly more), while I 
can browse duckduckgo.com <http://duckduckgo.com/>. Firefox returns Network 
Protocol Error on www.google.com <http://www.google.com/> and timeout on 
twitter.com <http://twitter.com/> and www.facebook.com 
<http://www.facebook.com/>. Additionally, IMAPS and SMTPS is working on Gmail, 
this email is sending via the VPN.

~> openssl s_client -connect www.google.com:443 -showcerts
CONNECTED(00000005)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = 
www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIEgjCCA2qgAwIBAgIIaLoHUPAeg/4wDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODExMjcxNDAyMDBaFw0x
OTAyMTkxNDAyMDBaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRcw
FQYDVQQDDA53d3cuZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAKhtF0MjB2unptytQW44dm3c9eL3f3YrxJ684rqX8c901CD73NCO+vcF
iVd0c6PiYpYK/kw9vRDXNrognt3CKYWVq/FdTlrjuKWExt7qD/sxZCKetTl5qekm
V4PwcbEvS98NF9vXIIIzOTK3WdYjz573ydyCWpA32qOLpCt8a6XoedFzX7KiUaGS
RPPNQI0+xZgow7jgNpZklB+iEwymSgFrM5SHxp4fouJMVG3BnJqXyhTdz4U4Ck+S
3gVEBNKc/y+ZKGplwbZ5NngYaov7U9uItceawa5xplcN0A1RcDmVaaRtsF51ktVQ
pZaAauc7LibJc9j4+ov5wTYYDwrxDK8CAwEAAaOCAUIwggE+MBMGA1UdJQQMMAoG
CCsGAQUFBwMBMBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMGgGCCsGAQUFBwEB
BFwwWjAtBggrBgEFBQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMu
Y3J0MCkGCCsGAQUFBzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAd
BgNVHQ4EFgQUz7BpFM91Drzs5f0URBWlje274G0wDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBR3wrhQmmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB
1nkCBQMwCAYGZ4EMAQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtp
Lmdvb2cvR1RTR0lBRzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQABZMq2qOr84g64
B0gEEkvQKIuNX+a2PB5R/IkhehqlH13120pTF1uoUBob9GCpmn2HT3KF88FiVzZ9
hfP2VturJv2WSzn1XSQGsba4oO6uiKWn1bAcXKpHWy+r+vnmuNBgLDNQ6uX3nC3A
5MrhGVv6D/7k5NPzOnI6mclBA/U/dE2Tp48Ej9RYg8rTjWajxUX4TTSskJZwmwXx
klEVY9Q4Gi3s5TrmDknusXhsIN9INzWDypB7h8Q5/IwjosMe2/rVK28BeSVtXRRy
xDI/NgavhvJJdAYOPiO0JW38QEHxKO3Fp7eO2zmZlVTbrq/VARguWl3qag526weW
4CNWWXYg
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 2945 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
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-CHACHA20-POLY1305
    Session-ID: 2319C8A3053A44BBFC253AE53CF6A35D9A37D19CD0CBC46ABA47D7398F657925
    Session-ID-ctx: 
    Master-Key: 
A0B7364DBE160E54FF0BA997618F6317A0E376BFF8A4C5B4373974735B370AE8DB8C397DCC2C608D9037CFBEB2901B13
    TLS session ticket lifetime hint: 100799 (seconds)
    TLS session ticket:
    0000 - 00 30 ac f3 8e b3 c5 a7-90 c9 65 8c 5e 88 17 e4   .0........e.^...
    0010 - d2 09 7e 4b 97 1b 97 b3-55 4c 08 01 cb 52 6f 3c   ..~K....UL...Ro<
    0020 - 84 87 85 47 d4 83 f4 78-df fc a2 68 88 a3 4c 00   ...G...x...h..L.
    0030 - d1 6e 38 ae b5 d6 27 19-e4 3f 48 b8 f4 cf e2 b0   .n8...'..?H.....
    0040 - b6 89 69 e5 ab 24 b3 27-64 b3 45 58 cb 21 69 81   ..i..$.'d.EX.!i.
    0050 - 35 61 a4 f3 59 e0 68 e4-0e c9 0b a2 75 85 f3 65   5a..Y.h.....u..e
    0060 - a0 0e 89 72 df 41 09 b1-31 18 05 7e 75 6c 45 73   ...r.A..1..~ulEs
    0070 - fa df a6 e6 e3 38 8e 04-e1 21 39 97 e7 91 59 c1   .....8...!9...Y.
    0080 - 98 3a 00 46 58 b8 73 a4-0f 0f 36 ba 8f d9 e4 3c   .:.FX.s...6....<
    0090 - 7b f2 f9 2c f1 70 06 86-3f 76 e4 e3 7a 9b 40 9f   {..,.p..?v..z.@.
    00a0 - f9 ab 16 3d e8 e6 54 81-67 a0 99 c1 c3 98 cd 27   ...=..T.g......'
    00b0 - c5 31 2a 96 00 e0 82 67-74 6d 84 1d 88 0b 26 ae   .1*....gtm....&.
    00c0 - 45 45 ee 04 97 a1 a1 d1-86 09 75 75 1d a9 e3 01   EE........uu....
    00d0 - 1b 0f 1c 44 ca                                    ...D.

    Start Time: 1544866145
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
read:errno=0



~> openssl s_client -connect twitter.com:443 -showcerts
CONNECTED(00000006)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High 
Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Twitter, Inc.", OU = 
tsa_m Point of Presence, CN = twitter.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=tsa_m Point of 
Presence/CN=twitter.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
-----BEGIN CERTIFICATE-----
MIIGhDCCBWygAwIBAgIQCWOaUnUDLiExEJVsj5mYWTANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xODA3MTcwMDAwMDBaFw0xOTA3MjIxMjAwMDBa
MIGKMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN
U2FuIEZyYW5jaXNjbzEWMBQGA1UEChMNVHdpdHRlciwgSW5jLjEgMB4GA1UECwwX
dHNhX20gUG9pbnQgb2YgUHJlc2VuY2UxFDASBgNVBAMTC3R3aXR0ZXIuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2dPpr8iFvJu73+YyFXH+9NSR
VyjeeVBhUhilZPL+Ajnl2qct/D0Xq8/zX2YNM7UjRO3HxiTYaP4sZ2Lxw0PomLUt
gnzDSK8E/w+/GFCMJ/6GVuJJnpI2G9NTDbylQD+UYqzuivmvTlwmmzIAd2+JH3yj
46np7VkZaVqrliRmLbBNNW7rj6CdC2O78xR2L9NJufzIL2Y0bkGGo6yJj0mt7bLx
791TG5g60QdUGombIvAvzrtFKb3RGc5u2DE6d2mhE5L/EtMgVBZ/jyQGlZTmJjuW
k56uviiYO7SDEHZRGqm2DxiNTvQ/IgVcMwnBYxFuQPSnaEO4Y56d7fD4F7/v1wID
AQABo4IC/TCCAvkwHwYDVR0jBBgwFoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYD
VR0OBBYEFHPl7L1zGyD02cZRjdu6yNL3hIMkMCcGA1UdEQQgMB6CC3R3aXR0ZXIu
Y29tgg93d3cudHdpdHRlci5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3Js
My5kaWdpY2VydC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRw
Oi8vY3JsNC5kaWdpY2VydC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1Ud
IARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRp
Z2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYB
BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFu
Y2VTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADCCAQQGCisGAQQB1nkCBAIEgfUE
gfIA8AB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABZKnLxH8A
AAQDAEcwRQIhAIv5Jd1U1I8M9mEenBA9ErrFBxzldJ2useWhCpXrEOQZAiAje6IA
AmiKgAAgl7YRvRYLtuLv7Owe9wvj45+zi1HIMAB2AId1v+dZfPiMQ5lfvfNu/1aN
R1Y2/0q1YMG06v9eoIMPAAABZKnLxRkAAAQDAEcwRQIgbgidp2Ag5bmFIv1Ovpwk
228o1rv8UnWcmLEykZ6LNiYCIQD/blrpcjTwA0sVv5YcwO2bLzMYC+jZvIbFCkyJ
Zy2/ijANBgkqhkiG9w0BAQsFAAOCAQEAHOaryx+H1h/L7Wjwjyccyd8f54k18gcr
W1jRxVjnXFyT32MIV8cg/l8Oh1J/oTKe4jkVbGhzX3w+L44v9rgcUDqtQHOxizpd
ygr2s88JsjickVCS5YRaSquLJsYX8LR2g1/FoFHYUSKQq2Vwd60czltlOvJoN09k
nqOM0wvjD30AO6hmuAz0icAxKKjAZMjkQ+GkLs3sOZw670QaFOfNj/CFT8IZ7JT0
iWNlHDC6eMd0u5Kk6lY/Q84EWVD26ZZxQyO9n1jjiErtSGfbHbpgaZASsPaIFlUE
XiQmuj3SqjfQb6Iue77d6zPDbJiweOVu9IVbv73sz7PkD5gvUM73KA==
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV 
Root CA
-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEvMC0GA1UEAxMmRGlnaUNlcnQgU0hBMiBIaWdoIEFzc3Vy
YW5jZSBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2
4C/CJAbIbQRf1+8KZAayfSImZRauQkCbztyfn3YHPsMwVYcZuU+UDlqUH1VWtMIC
Kq/QmO4LQNfE0DtyyBSe75CxEamu0si4QzrZCwvV1ZX1QK/IHe1NnF9Xt4ZQaJn1
itrSxwUfqJfJ3KSxgoQtxq2lnMcZgqaFD15EWCo3j/018QsIJzJa9buLnqS9UdAn
4t07QjOjBSjEuyjMmqwrIw14xnvmXnG3Sj4I+4G3FhahnSMSTeXXkgisdaScus0X
sh5ENWV/UyU50RwKmmMbGZJ0aAo3wsJSSMs5WqK24V3B3aAguCGikyZvFEohQcft
bZvySC/zA/WiaJJTL17jAgMBAAGjggFJMIIBRTASBgNVHRMBAf8ECDAGAQH/AgEA
MA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDA9BgNVHSAENjA0MDIG
BFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAdBgNVHQ4EFgQUUWj/kK8CB3U8zNllZGKiErhZcjswHwYDVR0jBBgwFoAUsT7D
aQP4v0cB1JgmGggC72NkK8MwDQYJKoZIhvcNAQELBQADggEBABiKlYkD5m3fXPwd
aOpKj4PWUS+Na0QWnqxj9dJubISZi6qBcYRb7TROsLd5kinMLYBq8I4g4Xmk/gNH
E+r1hspZcX30BJZr01lYPf7TMSVcGDiEo+afgv2MW5gxTs14nhr9hctJqvIni5ly
/D6q1UEL2tU2ob8cbkdJf17ZSHwD2f2LSaCYJkJA69aSEaRkCldUxPUd1gJea6zu
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae
cPUeybQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=tsa_m Point of 
Presence/CN=twitter.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3534 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: 58375F7A637D8738C8705D81D8598949753B923C66CBCD9AADC7AB02F92641D0
    Session-ID-ctx: 
    Master-Key: 
00EC0FFE25E5605EC545802324E90A493DB94F829814CDA8828F1309141BE13C7B8BF348FFB674F2DC60B12BBFB9A31E
    TLS session ticket lifetime hint: 129600 (seconds)
    TLS session ticket:
    0000 - d1 a8 5a f8 f7 17 60 12-a1 14 ef 55 8e fc f5 c0   ..Z...`....U....
    0010 - 67 e7 0e cb 45 f1 bb d1-b5 1d 48 83 97 28 a7 0a   g...E.....H..(..
    0020 - c6 8d 41 ab f1 45 cc c1-53 21 47 52 51 b2 65 47   ..A..E..S!GRQ.eG
    0030 - d3 9d 95 b5 80 dc 6d c7-a2 2e 6e 23 63 04 96 fc   ......m...n#c...
    0040 - 45 57 ab ce 92 ff df 62-a8 c1 7e 2e 8d 95 33 85   EW.....b..~...3.
    0050 - da a8 9b 28 be 7e f6 31-a7 8f 6d 58 64 b7 9f aa   ...(.~.1..mXd...
    0060 - 9e ca b0 e0 c0 73 3c 4f-42 21 fb ed 4a 04 ff 31   .....s<OB!..J..1
    0070 - bb 08 2d 94 f9 36 72 33-cd 5e 23 3f 1d b9 bb ab   ..-..6r3.^#?....
    0080 - 3b 7b b0 c5 f1 49 e9 f2-29 f5 91 4a 2d b0 db c9   ;{...I..)..J-...
    0090 - c9 5a b8 11 c3 17 be a3-52 70 ed a3 45 22 3c de   .Z......Rp..E"<.

    Start Time: 1544866734
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
closed



~> openssl s_client -connect www.facebook.com:443 -showcerts
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High 
Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = Menlo Park, O = "Facebook, Inc.", CN = 
*.facebook.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
-----BEGIN CERTIFICATE-----
MIIGsjCCBZqgAwIBAgIQCzw7YBoY9Z7itrsFYF7ywDANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTUwMDAwMDBaFw0xOTAzMjIxMjAwMDBa
MGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRMwEQYDVQQHEwpN
ZW5sbyBQYXJrMRcwFQYDVQQKEw5GYWNlYm9vaywgSW5jLjEXMBUGA1UEAwwOKi5m
YWNlYm9vay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASIA87IjqqM6JBX
puN20BXCVsDjoP9wnF2rSV60qC130oLTrgfOQ3Uk1dv1R6LFCx4gs2pJUu6iDKBS
/b+BXOUbo4IEGDCCBBQwHwYDVR0jBBgwFoAUUWj/kK8CB3U8zNllZGKiErhZcjsw
HQYDVR0OBBYEFMD9dPV9y8Yn8QPTYqJF14QcFSEIMIHHBgNVHREEgb8wgbyCDiou
ZmFjZWJvb2suY29tgg4qLnh4LmZiY2RuLm5ldIILKi5mYnNieC5jb22CDioueHou
ZmJjZG4ubmV0gg4qLmZhY2Vib29rLm5ldIIOKi54eS5mYmNkbi5uZXSCDyoubWVz
c2VuZ2VyLmNvbYIGZmIuY29tggsqLmZiY2RuLm5ldIIIKi5mYi5jb22CECoubS5m
YWNlYm9vay5jb22CDW1lc3Nlbmdlci5jb22CDGZhY2Vib29rLmNvbTAOBgNVHQ8B
Af8EBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRu
MGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZl
ci1nNi5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zaGEyLWhh
LXNlcnZlci1nNi5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgIwgYMG
CCsGAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQu
Y29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGln
aUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAA
MIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCkuQmQtBhYFIe7E6LMZ3AKPDWY
BPkb37jjd80OyA3cEAAAAWBXnEHoAAAEAwBHMEUCIBC3Rn4i2bhLyR344u3vl7be
vxoi+WPJBhGT+j1gJmg5AiEAwQ3rzH1mmMSYNYKtVNDZMo+l6e8Z35t+X9NDR7Du
gWAAdwCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWBXnEL7AAAE
AwBIMEYCIQCRjvvPARW3J1ENmo2Nz1cxisa1BcbDuqvSrfuXkz8btAIhAPmllqgF
8JjlVHUChiFzghsKVBeTxRagi55tgsAciaoZAHUAu9nfvB+KcbWTlCOXqpJ7RzhX
lQqrUugakJZkNo4e0YUAAAFgV5xCUgAABAMARjBEAiBY6qdNgMoQAqVTl3zRrTmy
+X/1f/esBUczsb3MWdZ1ZgIgXdxZNTrDBgyTzxgbVRObkqU3tZZdaiwsw4WI0xI0
BtQwDQYJKoZIhvcNAQELBQADggEBAGu0uxZD+IRXXlFWLPvknRkXA7J08NyVKG70
M2vDi2xF2YB8qlZgoxW8YiiV86IpwtOhYLZinSO0iCBDQmTf627LTPfuDcF6qOuO
WFTvj1IbplPvGWIu5tNBiFWNQxFAIL2Rf+5vmIe+YezUHTLGGqwRtFa2ImS17IMk
YjZ90LYXXO5qb1RKkFJtAvEBTbJsv8kr+J6Rx+YNJy17LnBX+MbWiyBbvUQoM3sY
MmcWmcaQmECz9ZHWYjZeufSHbHKG6KDYLU8x6DyhgtxK2rsoIMlNnJkNHaLjw+b8
7VCYa+EMWppvVuNyXOk9Jkbx7Q3SEoodT77kkHUX0bF2OkZy6cc=
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV 
Root CA
-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEvMC0GA1UEAxMmRGlnaUNlcnQgU0hBMiBIaWdoIEFzc3Vy
YW5jZSBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2
4C/CJAbIbQRf1+8KZAayfSImZRauQkCbztyfn3YHPsMwVYcZuU+UDlqUH1VWtMIC
Kq/QmO4LQNfE0DtyyBSe75CxEamu0si4QzrZCwvV1ZX1QK/IHe1NnF9Xt4ZQaJn1
itrSxwUfqJfJ3KSxgoQtxq2lnMcZgqaFD15EWCo3j/018QsIJzJa9buLnqS9UdAn
4t07QjOjBSjEuyjMmqwrIw14xnvmXnG3Sj4I+4G3FhahnSMSTeXXkgisdaScus0X
sh5ENWV/UyU50RwKmmMbGZJ0aAo3wsJSSMs5WqK24V3B3aAguCGikyZvFEohQcft
bZvySC/zA/WiaJJTL17jAgMBAAGjggFJMIIBRTASBgNVHRMBAf8ECDAGAQH/AgEA
MA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDA9BgNVHSAENjA0MDIG
BFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAdBgNVHQ4EFgQUUWj/kK8CB3U8zNllZGKiErhZcjswHwYDVR0jBBgwFoAUsT7D
aQP4v0cB1JgmGggC72NkK8MwDQYJKoZIhvcNAQELBQADggEBABiKlYkD5m3fXPwd
aOpKj4PWUS+Na0QWnqxj9dJubISZi6qBcYRb7TROsLd5kinMLYBq8I4g4Xmk/gNH
E+r1hspZcX30BJZr01lYPf7TMSVcGDiEo+afgv2MW5gxTs14nhr9hctJqvIni5ly
/D6q1UEL2tU2ob8cbkdJf17ZSHwD2f2LSaCYJkJA69aSEaRkCldUxPUd1gJea6zu
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae
cPUeybQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3412 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES128-GCM-SHA256
    Session-ID: FCB725472E0112F95A596012CDD55AB38A73CE46BABF6226978651E9F259C609
    Session-ID-ctx: 
    Master-Key: 
A35C3023DE520684DA23B557656DDC3478FCD3C66B5BA677F62B605BCC4CD395C085D3A980587DE72D9C6FFCA988F5F4
    TLS session ticket lifetime hint: 172800 (seconds)
    TLS session ticket:
    0000 - e1 ec 9e 74 56 16 6a 55-7a 80 74 3d 2e 44 3e 0d   ...tV.jUz.t=.D>.
    0010 - 5f c0 6f 4a 8c d8 ec 2a-2b 27 91 29 de 04 3d 49   _.oJ...*+'.)..=I
    0020 - f5 ae 40 d6 86 3e 3c 29-66 7b 3f ed c5 ad 80 b1   ..@..><)f{?.....
    0030 - bb 3e 0b b1 67 6b 07 4b-ac 9f 30 f3 9f 8b ba 3b   .>..gk.K..0....;
    0040 - bf 51 24 e7 25 19 74 d2-c2 b1 c6 12 cb 50 dd 10   .Q$.%.t......P..
    0050 - 4f 08 7f 12 36 de 4e 8d-50 05 32 99 71 e4 a0 aa   O...6.N.P.2.q...
    0060 - a6 35 30 5e ed a9 f1 f5-b4 59 46 62 60 d6 5b 9a   .50^.....YFb`.[.
    0070 - 66 2d 6b 1f 69 ad b4 d3-52 b2 3e 83 16 92 93 38   f-k.i...R.>....8
    0080 - 59 70 9c 4c e7 f1 a4 e0-89 d4 6e 9b 47 f6 b5 be   Yp.L......n.G...
    0090 - bd 60 9c a1 3e ae 1d f1-0e d6 43 cb 0a 61 37 5d   .`..>.....C..a7]
    00a0 - 9f f5 6d 46 e8 8a 75 3e-ea b6 8f c6 02 5e 67 1a   ..mF..u>.....^g.

    Start Time: 1544866854
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
closed


Thanks and best regards,
Siegfried


> On Dec 14, 2018, at 1:59 PM, Zhi-Qiang Lei <zhiqiang....@gmail.com> wrote:
> 
> 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 <t...@uchicago.edu> 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 <mss 1460,nop,nop,sackOK,nop,wscale 
>> 6,nop,nop,timestamp 2698316052 0>
>> 
>> 16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 
>> 256 <nop,nop,timestamp 2698316052 3536824996>
>> 
>> 16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 <nop,nop,timestamp 2698316052 3536824996>
>> 
>> 16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 <nop,nop,timestamp 2698316055 3536824996>
>> 
>> 16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
>> 256 <nop,nop,timestamp 2698316061 3536824996>
>> 
>> 16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 
>> 256 <nop,nop,timestamp 2698316061 3536824996>
>> 
>> 16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 
>> win 256 <nop,nop,timestamp 2698316073 3536825005>
>> 
>> 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 <mss 
>> 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 <mss 
>> 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 <nop,nop,timestamp 2698316052 
>> 3536824996> (encap)
>> 
>> 16:43:05.147365 (unprotected): SPI 0x0000ef27: 172.30.1.254.7305 > 
>> 172.30.7.205.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 2698316052 
>> 3536824996> (encap)
>> 
>> 16:43:06.645932 (unprotected): SPI 0x0000ef27: 172.30.1.254.7305 > 
>> 172.30.7.205.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 2698316055 
>> 3536824996> (encap)
>> 
>> 16:43:09.646049 (unprotected): SPI 0x0000ef27: 172.30.1.254.7305 > 
>> 172.30.7.205.443: P 1:197(196) ack 1 win 256 <nop,nop,timestamp 2698316061 
>> 3536824996> (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 <nop,nop,timestamp 2698316061 
>> 3536824996> (encap)
>> 
>> 16:43:09.981966 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
>> 172.30.1.254.7305: . ack 1 win 261 <nop,nop,timestamp 3536825005 
>> 2698316052,nop,nop,sack 1 {197:197} > (encap)
>> 
>> 16:43:15.646158 (unprotected): SPI 0x0000ef27: 172.30.1.254.7305 > 
>> 172.30.7.205.443: FP 1:197(196) ack 1 win 256 <nop,nop,timestamp 2698316073 
>> 3536825005> (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 <mss 
>> 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 2698316052 0> (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 <mss 
>> 1300,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3536824996 2698316052> 
>> (encap)
>> 
>> 16:43:05.174802 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 
>> > 172.30.7.205.443: . ack 1 win 256 <nop,nop,timestamp 2698316052 
>> 3536824996> (encap)
>> 
>> 16:43:09.966420 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 
>> > 172.30.7.205.443: F 197:197(0) ack 1 win 256 <nop,nop,timestamp 2698316061 
>> 3536824996> (encap)
>> 
>> 16:43:09.966853 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
>> 172.30.1.254.7305: . ack 1 win 261 <nop,nop,timestamp 3536825005 
>> 2698316052,nop,nop,sack 1 {197:197} > (encap)
>> 
>> 
>> I have no idea what this all means, or what to do with it. 
>> But, I am following up in case anybody has any idea of what may be 
>> happening. 
>> 
>> Also, yesterday I described how the local iked machine appeared to be 
>> blocking packets that were explicitly allowed by pf.conf.  From my post 
>> yesterday:
>> 
>> (   For example, in the log I see: 
>> Dec  8 15:50:01 ... pf: Dec 08 15:48:49.346816 rule 4/(match) block out on 
>> em0: 172.30.7.205.22112 > 172.30.2.99.5665: R 3963276584:3963276584(0) ack 
>> 252894831 win 0
>> 
>> But, pfctl is running with following: 
>> 
>> # pfctl -s rules 
>> match in all scrub (no-df random-id max-mss 1300) 
>> pass in quick on em1 all flags S/SA 
>> pass out quick on em1 all flags S/SA 
>> block drop in log on em0 all 
>> block drop out log on em0 all 
>> ... 
>> pass quick inet proto tcp from 172.30.7.205 to 172.30.2.99 port = 5665 flags 
>> S/SA 
>> ... and on.    ) 
>> 
>> Well, whatever was happening appears to have been resolved, because at about 
>> midnight local time on Sunday morning, icinga2 declared that the host was 
>> back up.
>> 
>> To be clear, I have made no changes to either pf.conf or iked.conf on any of 
>> the machines involved in this testing from Saturday.
>> 
>> Also, this had all been stable for the last (about) 2 years, until about 
>> two-three weeks ago.  I did have another post, where I discussed the fact 
>> the iked VPN had failed to be reestablished after an update about 3-4 
>> snapshots back.  I got it working again by changing the local endpoint on 
>> the "remote" iked machine from the internal ip associated with the internal 
>> interface to an internal "alias" ip address associated with the 
>> outgoing/external interface of that machine.
>> 
>> But, again, it had been working for 2 years until the recent update. 
>> 
>> I don't have any idea of what may be helpful in figuring out what I am doing 
>> wrong, or what has changed, but I am happy to provide any information that 
>> may be of help.
>> 
>> I don't believe I have the knowledge to do more on my own at this point. 
>> 
>> Thanks for any advice. 
>> Ted 
>> 
>> 
>> 
>> 
> 

Reply via email to