IKEv2 to Windows10
-
Hello
show me the settings
/etc/strongswan/ipsec.conf
and the output of the command
strongswan statusall
when the client is connectedhere is an example of my strongswan settings on Centos for authorization via radius server
conn es_rw authby = ecdsasig fragmentation = yes keyexchange = ikev2 reauth = yes forceencaps = no mobike = no dpdaction = clear dpddelay = 10s dpdtimeout = 60s auto = add left = XXX.XXX.XXX.XXX right = %any leftid = @strongswan.XXXYYYZZZ.org ikelifetime = 86400s lifetime = 3600s rightsourceip = %radius ike = aes256-sha256-modp2048! esp = aes256-sha256-modp2048,aes256-sha256! eap_identity=%identity leftauth=pubkey rightauth=eap-radius leftcert=strongswan_ecdsa384.pem leftca="C=ES, O=Mzzz, CN=es.XXXYYYZZZ.org" leftfirewall=yes lefthostaccess=no leftsendcert=always rightsendcert=always leftsubnet = 0.0.0.0/0
Security Associations (2 up, 0 connecting): es_rw[491]: ESTABLISHED 9 seconds ago, 37.XXX.XXX.XXX[strongswan.XXXYYYZZZ.org]...176.59.48.16[sony_xperia.XXXYYYZZZ.org] es_rw[491]: IKEv2 SPIs: 1871b92991ed5291_i b7abe8784fcac66e_r*, public key reauthentication in 23 hours es_rw[491]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 es_rw{3550}: INSTALLED, TUNNEL, reqid 161, ESP in UDP SPIs: c6b527c4_i db1611ca_o es_rw{3550}: AES_CBC_256/HMAC_SHA2_256_128, 6571 bytes_i (73 pkts, 4s ago), 7200 bytes_o (56 pkts, 4s ago), rekeying in 44 minutes es_rw{3550}: 0.0.0.0/0 === 192.168.150.150/32
-
Hi @Konstanti,
this is "/usr/local/etc/ipsec.conf":
conn con-mobile fragmentation = yes keyexchange = ikev2 reauth = yes forceencaps = no mobike = yes rekey = yes installpolicy = yes type = tunnel dpdaction = clear dpddelay = 10s dpdtimeout = 60s auto = add left = 192.168.178.2 right = %any leftid = fqdn:XXXXXXXXXX ikelifetime = 28800s lifetime = 3600s rightsourceip = 192.168.48.0/24 rightdns = 192.168.50.15,192.168.60.16 ike = aes256-sha256-modp1024! esp = aes256-sha1-modp1024,aes256-sha1! eap_identity=%identity leftauth=pubkey rightauth=eap-radius leftcert=/var/etc/ipsec/ipsec.d/certs/cert-2.crt leftsendcert=always leftsubnet = 192.168.50.0/24,192.168.55.0/24
...and here is the "ipsec statusall":
Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p10, amd64): uptime: 79 minutes, since Dec 05 13:43:29 2019 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2 loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters Virtual IP pools (size/online/offline): 192.168.48.0/24: 254/0/1 Listening IP addresses: 192.168.50.1 192.168.178.2 2a02:810d:XXXXXX:1e1b 192.168.100.1 172.16.0.6 Connections: con-mobile: 192.168.178.2...%any IKEv2, dpddelay=10s con-mobile: local: [C=DE, ST=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] uses public key authentication con-mobile: cert: "C=DE, ST=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" con-mobile: remote: uses EAP_RADIUS authentication with EAP identity '%any' con-mobile: child: 192.168.50.0/24|/0 192.168.55.0/24|/0 === dynamic TUNNEL, dpdaction=clear Security Associations (0 up, 0 connecting): none
I can only see one different: "leftfirewall=yes". Do you think this is the key???
Thank you
Robert -
@killrob
I can't see that the client is connectedSecurity Associations (0 up, 0 connecting):
-
Hi @Konstanti,
sorry for this.. I thought you only want to see the configuration...
Here ist is:Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p10, amd64): uptime: 110 minutes, since Dec 05 13:43:27 2019 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7 loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters Virtual IP pools (size/online/offline): 192.168.48.0/24: 254/1/0 Listening IP addresses: 192.168.50.1 192.168.178.2 2a02:XXXXXXXXXX:1e1b 192.168.100.1 172.16.0.6 Connections: con-mobile: 192.168.178.2...%any IKEv2, dpddelay=10s con-mobile: local: [C=DE, STXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] uses public key authentication con-mobile: cert: "C=DE, STXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" con-mobile: remote: uses EAP_RADIUS authentication with EAP identity '%any' con-mobile: child: 192.168.50.0/24|/0 192.168.55.0/24|/0 === dynamic TUNNEL, dpdaction=clear Security Associations (1 up, 0 connecting): con-mobile[2]: ESTABLISHED 15 seconds ago, 192.168.178.2[C=DE, STSTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]...80.187.96.2[10.76.222.47] con-mobile[2]: Remote EAP identity: ROB\Rob con-mobile[2]: IKEv2 SPIs: b2144a48aac5a361_i b3727b0cfc730fa4_r*, public key reauthentication in 7 hours con-mobile[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024 con-mobile{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c577b657_i 8545b44e_o con-mobile{2}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i (0 pkts, 15s ago), 0 bytes_o, rekeying in 44 minutes con-mobile{2}: 192.168.50.0/24|/0 192.168.55.0/24|/0 === 192.168.48.1/32|/0
Thanks
Robert -
@killrob said in IKEv2 to Windows10:
192.168.48.1/32
The rules on the ipsec interface allow traffic to pass from 192.168.48.0/24 to 192.168.50.0/24 and 192.168.55.0/24?
-
I think so..
...and even if not, should the counter of the tunnel be increase by the dropped pkgs?
...and I can't find anything in the logsWireshark on the client schows a lot of action to find the DomainControllers...
-
@killrob
It is possible that the problem is in the windows client
Run tcpdump on the wan interface and see if there is an exchange of esp packets with the windows client ?
tcpdump -nettti wan_interface_name host remote_client_ip
for example,
tcpdump -nettti enp0s20f0 host 176.59.48.43tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s20f0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:00:00.000000 00:24:13:10:8c:00 > 0c:c4:7a:68:b5:e8, ethertype IPv4 (0x0800), length 1474: 176.59.48.43.58377 > 37.XXX.XXX.XXX.ipsec-nat-t: UDP-encap: ESP(spi=0xc260cbe1,seq=0xc25), length 1432 00:00:00.026351 0c:c4:7a:68:b5:e8 > 00:00:0c:9f:f0:1e, ethertype IPv4 (0x0800), length 1474: 37.XXX.XXX.XXX.ipsec-nat-t > 176.59.48.43.58377: UDP-encap: ESP(spi=0x9c4f7cdc,seq=0xcd7), length 1432 00:00:00.130524 00:24:13:10:8c:00 > 0c:c4:7a:68:b5:e8, ethertype IPv4 (0x0800), length 146: 176.59.48.43.58377 > 37.XXX.XXX.XXX.ipsec-nat-t: UDP-encap: ESP(spi=0xc260cbe1,seq=0xc26), length 104
-
I think you are rigth... There is someting with the client...
tcpdump -pni hn1 host 80.187.96.2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on hn1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:01:00.398913 IP 80.187.96.2.500 > 192.168.178.2.500: isakmp: parent_sa ikev2_init[I] 16:01:00.403551 IP 192.168.178.2.500 > 80.187.96.2.500: isakmp: parent_sa ikev2_init[R] 16:01:00.473333 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.473606 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.473704 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.507530 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.507536 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.507537 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.608506 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.630480 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.709746 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.714944 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.775771 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.778474 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:00.839844 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:01:00.845113 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa ikev2_auth[R] 16:01:10.779999 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: parent_sa inf2 16:01:11.119857 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: parent_sa inf2[IR] 16:01:20.312048 IP 80.187.96.2.22174 > 192.168.178.2.4500: isakmp-nat-keep-alive 16:01:20.813816 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa inf2 16:01:20.879943 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa inf2[IR] 16:01:30.835583 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa inf2 16:01:31.039993 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa inf2[IR] 16:01:39.297803 IP 80.187.96.2.22174 > 192.168.178.2.4500: isakmp-nat-keep-alive 16:01:40.880117 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa inf2 16:01:40.938225 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa inf2[IR] 16:01:50.980046 IP 192.168.178.2.4500 > 80.187.96.2.22174: NONESP-encap: isakmp: child_sa inf2 16:01:51.048204 IP 80.187.96.2.22174 > 192.168.178.2.4500: NONESP-encap: isakmp: child_sa inf2[IR]
The timing of the packages does not match to the ping... So the packages disapear somewhere else.
I will check Firewall-Logs on the Client as a next step...Thanks
Robert -
It all can be done with the Winblows 10 onboard VPN client. And not even Windows 10 it works for more or less ALL onboard clients in the most common OS and smartphone devices !
Take a look here:
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-opnsense-firewall-einrichten-337198.html
Maybe Google translator is your friend here but all the screenshots are more or less self explaining ! -
Hello,
sorry for the delay!
It works now perfect for me and I think it was a problem wit my mobile-connection.
It works with the Android StrongSwan-App, with the default configuration on Windows 10 (IKEv2) and with the PowerShell generated connection mentioned by @lfoerster.Thank you
Robert