Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IKEv2 to Windows10

    Scheduled Pinned Locked Moved IPsec
    11 Posts 3 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      killrob
      last edited by

      Hello,

      I try to configure remote access for Windows 10 with the integrated vpn-client.
      I had this allready running with strongswan on a Linux Ubuntu Firewall. So I'm shure it works :-)
      My configuration is like this:
      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: 0.0.0.0/0|/0 === dynamic TUNNEL, dpdaction=clear

      The Windows-Client can establish the tunnel (Phase1 & Phase 2):
      con-mobile[1]: ESTABLISHED 5 seconds ago, 192.168.178.2[C=DE, STXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]...80.187.96.104[10.28.68.95]
      con-mobile[1]: Remote EAP identity: ROB\Rob
      con-mobile[1]: IKEv2 SPIs: 53c66d0549f6fbff_i d19bde05f5eea884_r*, public key reauthentication in 7 hours
      con-mobile[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
      con-mobile{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cd0ccfe5_i 191156ba_o
      con-mobile{1}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 43 minutes
      con-mobile{1}: 0.0.0.0/0|/0 === 192.168.48.1/32|/0

      But now it is not able to send packages thru the tunnel. I can't ping the server and the servers can't ping the client.
      In the firewall logs I can not find any dropped packages.
      The byte-count for the connections (in & out) is stable on 0

      The Byte count on the client is increasing. Receive count is stable at 0

      Any suggestion is wellcome...

      Thanks
      Robert

      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @killrob
        last edited by Konstanti

        @killrob

        Hello
        show me the settings
        /etc/strongswan/ipsec.conf
        and the output of the command
        strongswan statusall
        when the client is connected

        here 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
        
        1 Reply Last reply Reply Quote 0
        • K
          killrob
          last edited by killrob

          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

          K 1 Reply Last reply Reply Quote 0
          • K
            Konstanti @killrob
            last edited by

            @killrob
            I can't see that the client is connected

            Security Associations (0 up, 0 connecting):
            
            1 Reply Last reply Reply Quote 0
            • K
              killrob
              last edited by

              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

              K 1 Reply Last reply Reply Quote 0
              • K
                Konstanti @killrob
                last edited by Konstanti

                @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?

                1 Reply Last reply Reply Quote 0
                • K
                  killrob
                  last edited by

                  I think so..
                  2019-12-05 154050.png

                  ...and even if not, should the counter of the tunnel be increase by the dropped pkgs?
                  ...and I can't find anything in the logs

                  Wireshark on the client schows a lot of action to find the DomainControllers...

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    Konstanti @killrob
                    last edited by Konstanti

                    @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.43

                    tcpdump: 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
                    
                    K 1 Reply Last reply Reply Quote 0
                    • K
                      killrob @Konstanti
                      last edited by

                      @Konstanti

                      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

                      1 Reply Last reply Reply Quote 0
                      • L
                        lfoerster
                        last edited by lfoerster

                        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 !

                        1 Reply Last reply Reply Quote 0
                        • K
                          killrob
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.