-1

I set up VPN server on Oracle's OCI using Ubuntu 22.04 and strongSwan 5.9.5. When I tried connect from different roadwarriors, Android works good, Win10 works good even ancient Blackberry10 works good, but not for Win7 and Win8.1 laptops: they stuck on first stage:

mytestcloud charon[968]: 05[NET] received packet: from <MYIP>[500] to 10.0.0.64[500] (616 bytes)
mytestcloud charon[968]: 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
mytestcloud charon[968]: 05[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
mytestcloud charon[968]: 05[IKE] received MS-Negotiation Discovery Capable vendor ID
mytestcloud charon[968]: 05[IKE] received Vid-Initial-Contact vendor ID
mytestcloud charon[968]: 05[ENC] received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
mytestcloud charon[968]: 05[IKE] <MYIP> is initiating an IKE_SA
mytestcloud charon[968]: 05[IKE] <MYIP> is initiating an IKE_SA
mytestcloud charon[968]: 05[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
mytestcloud charon[968]: 05[IKE] local host is behind NAT, sending keep alives
mytestcloud charon[968]: 05[IKE] remote host is behind NAT
mytestcloud charon[968]: 05[IKE] sending cert request for "C=<MYCOUNTRY>, O=<MYFIRM>, CN=<MYNAME>"
mytestcloud charon[968]: 05[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(CHDLESS_SUP) N(MULT_AUTH) ]
mytestcloud charon[968]: 05[NET] sending packet: from 10.0.0.64[500] to <MYIP>[500] (345 bytes)
mytestcloud charon[968]: 08[IKE] sending keep alive to <MYIP>[500]
mytestcloud charon[968]: 09[JOB] deleting half open IKE_SA with <MYIP> after timeout

My ipsec.conf is:

config setup
    charondebug="ike 1, knl 1, cfg 1"
    strictcrlpolicy=no
    # uniqueids = no

conn %default
   ikelifetime=24h
   keylife=24h
   keyexchange=ikev2
   dpdaction=clear
   dpdtimeout=3600s
   dpddelay=3600s
   compress=yes
   leftfirewall=yes
   left=%any
   leftsubnet=0.0.0.0/0
   right=%any
   rightsourceip=192.168.2.100/28
#   rightdns=8.8.8.8, 8.8.4.4
#   leftsendcert=always
#   fragmentation=yes
#   rightsendcert=never
#   forceencaps=yes
   rekey=no
   auto=add
   ike=aes256-sha1-modp1024,3des-sha1-modp1024!
   esp=aes256-sha1,3des-sha1!

conn roadwarrior
   leftauth=pubkey
   leftcert=VPNCert.pem
   leftid=<SERVERIP>
   rightauth=pubkey

Status is (Win10 laptop is connected):

ubuntu@mytestcloud:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.0-1025-oracle, aarch64):
  uptime: 36 minutes, since Dec 12 09:05:21 2022
  malloc: sbrk 2605056, mmap 0, used 1670848, free 934208
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon pkcs11 aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac ccm gcm drbg curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-aka eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-tls eap-ttls eap-peap eap-tnc xauth-generic tnc-tnccs dhcp counters
Virtual IP pools (size/online/offline):
  192.168.2.100/28: 11/1/0
Listening IP addresses:
  10.0.0.64
Connections:
 roadwarrior:  %any...%any  IKEv2, dpddelay=3600s
 roadwarrior:   local:  [<SERVERIP>] uses public key authentication
 roadwarrior:    cert:  "C=<MYCOUNTRY>, O=<MYFIRM>, CN=<SERVERIP>"
 roadwarrior:   remote: uses public key authentication
 roadwarrior:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
 roadwarrior[3]: ESTABLISHED 7 minutes ago, 10.0.0.64[150.136.154.215]...<MYIP>[C=<MYCOUNTRY>, O=<MYFIRM>, CN=Win10]
 roadwarrior[3]: IKEv2 SPIs: 250f9e9db620a7e7_i 29b6ebbdb66a922a_r*, rekeying disabled
 roadwarrior[3]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
 roadwarrior{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c084f973_i 5daafdba_o
 roadwarrior{1}:  AES_CBC_256/HMAC_SHA1_96, 30958 bytes_i (122 pkts, 80s ago), 14517 bytes_o (50 pkts, 80s ago), rekeying disabled
 roadwarrior{1}:   0.0.0.0/0 === 192.168.2.100/32

I suspect, it's some kind of fragmentation problem, because after adding

fragmentation=no

in ipsec.conf, Win10 device falls in very same manner. I added everything is needed, I believe; I mean

net/ipv4/ip_no_pmtu_disc=1

in sysctl.conf and

FORWARD -t mangle --match policy --pol ipsec --dir in -o enp0s3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

in iptables rules. Please keep in mind, I can use almost identical config in Ubuntu 16.04 / strongSwan 5.2.2 on AWS without any problem. Small differencies are default cipher suites and different server certificate. So, can I force to connect those Windows beasts somehow?

Night_prowler
  • 1
  • 1
  • Maybe windows 7 relies on Agressive IKE in phase1? This has been disabled in later Strongswan. Maybe you can use **i_dont_care_about_security_and_use_aggressive_mode_psk = yes**, but agressive mode is vulnerable to brute forcing if you use preshared keys. – Gerrit Dec 12 '22 at 12:06
  • As per my understanding, agressive mode is defined for ikev1, not ikev2. Anyway, **i care about security** :) – Night_prowler Dec 12 '22 at 12:58
  • Unfortunately, I can't trace back which strongswan stopped work with win7/8, because I couldn't compile anything beyond 5.9: it throws error while compiling – Night_prowler Dec 12 '22 at 13:04
  • Reading Strongswan documentation, it seems older Windows clients do not support fragmentation in IKEv2, but do allow it in IKEv1. With large certificates, this can indeed be a problem, as I encountered it in TLS also. You could experiment with a small public key perhaps. – Gerrit Dec 12 '22 at 13:29
  • For the client to send smaller packets if path-mtu is not working properly, then you would need to set the MTU on the interface of the client. MSS does not work for UDP. – Gerrit Dec 12 '22 at 13:32
  • I'm not shure it's cert size problem - it has only 1212 b length, at first, and it's small enough to work in Ubuntu 16 and strongSwan 5.2, at second. Ifconfig shows MTU 9000 on interface, precisely the same as for Ubuntu 16, which one works perfectly. And yes, You're absolutely right, my **iptables** rule is for TCP, not for UDP. I'm completely lost, to be honest – Night_prowler Dec 12 '22 at 14:22
  • Just to complete my setup: on both machines (Ubuntu 16/22) in credentials I have the same: client private key/ client cert, server private key. Hence different are server certs only – Night_prowler Dec 12 '22 at 14:24
  • MTU 9000 is a bit bogus. That can only exist on internal networks with jumbo frames. If you want a server to reliably communicatie with the outside world, the MTU of the outside interface should never exceed 1500. Try and lower MTU on the client side, but also on the server side. – Gerrit Dec 12 '22 at 14:33

1 Answers1

0

Well, it seems problem is packets fragmentation. At one hand, I believe Oracle has fragmentation hardcoded into its public interfaces; at another hand, legacy Windows OSes (Windows 7, Windows 8/8.1, Windows 10 pre 1803, Ubuntu 16) don't support fragmentation. So, there aren't any way to use clients on such OSes to connect strongSwan running on Oracle OCI. There are 3 workarounds to overcome that limitation:

  1. Move away from legacy clients (not very impressive for persons use them).
  2. Change cloud provider - I tested strongSwan on Amazon AWS and DigitalOcean: everything works flawlessly.
  3. Change VPN type - personally I ended with that solution: WireGuard hasn't any problem on Oracle OCI. And I solved problem with DNS leaks as a nice adding.
Night_prowler
  • 1
  • 1