Project

General

Profile

Issue #2590

Site to Site VPN Phase Two not Coming up, and IKE_SA deletes on re-authentication.

Added by TeeJay OPA over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.5.3
Resolution:
No change required

Description

Here is my scenario.
I am trying to access resources on endpoint 41.206.4.75 from that requires a site to site vpn to peer 41.220.79.242
I am running StrongSwan 5.5.3 on CentOS 7. The other company runs a window set up with Cisco devices.

The IKE Phase of the VPN seems to be up and connected.
But not seeing anything about Phase two, no Child_SA, nothing about ESP.

ipsec.conf

conn %default
        rekeymargin=3m
        keyingtries=3
        keyexchange=ikev1
        authby=secret

conn site-site
        left=173.44.45.44
        leftsubnet=192.168.2.0/24
        right=41.220.79.242
        rightid=41.220.79.242
        rightsubnet=10.2.0.0/24
        rightsourceip=10.42.42.0/24
        ike=aes128-md5-modp1024,3des-md5-modp1024!
        esp=3des-sha1,aes128-md5,aes128-sha1,3des,3des-md5
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        auto=start
        type=tunnel

=========================================

strongswan statusall

Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.10.0-693.11.6.el7.x86_64, x86_64):
  uptime: 6 minutes, since Mar 14 10:28:49 2018
  malloc: sbrk 1622016, mmap 0, used 512480, free 1109536
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp unity
Virtual IP pools (size/online/offline):
  10.42.42.0/24: 254/0/0
Listening IP addresses:
  173.44.45.44
Connections:
  kelvic-mtn:  173.44.45.44...41.220.79.242  IKEv1, dpddelay=30s
  kelvic-mtn:   local:  [173.44.45.44] uses pre-shared key authentication
  kelvic-mtn:   remote: [41.220.79.242] uses pre-shared key authentication
  kelvic-mtn:   child:  192.168.2.0/24 === 10.2.0.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
  kelvic-mtn[1]: ESTABLISHED 6 minutes ago, 173.44.45.44[173.44.45.44]...41.220.79.242[41.220.79.242]
  kelvic-mtn[1]: IKEv1 SPIs: 43cc5f77aa48bbc1_i* 9748fb98f4d0ba94_r, pre-shared key reauthentication in 2 hours
  kelvic-mtn[1]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
  kelvic-mtn[1]: Tasks queued: QUICK_MODE

================================================================================

However it seem this IKE Security Association Disconnect upon re-authentication, because when I check back after a couple of hours,

strongswan statusall

Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.10.0-693.11.6.el7.x86_64, x86_64):
  uptime: 13 hours, since Mar 13 16:50:29 2018
  malloc: sbrk 1622016, mmap 0, used 503344, free 1118672
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp unity
Virtual IP pools (size/online/offline):
  10.42.42.0/24: 254/0/0
Listening IP addresses:
  173.44.45.44
Connections:
  kelvic-mtn:  173.44.45.44...41.220.79.242  IKEv1, dpddelay=30s
  kelvic-mtn:   local:  [173.44.45.44] uses pre-shared key authentication
  kelvic-mtn:   remote: [41.220.79.242] uses pre-shared key authentication
  kelvic-mtn:   child:  192.168.2.0/24 === 10.2.0.0/24 TUNNEL, dpdaction=restart
Security Associations (0 up, 0 connecting):
  none

----------------------------

ip address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3c:9b:8b:1a brd ff:ff:ff:ff:ff:ff
    inet 173.44.45.44/27 brd 173.44.45.63 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3cff:fe9b:8b1a/64 scope link 
       valid_lft forever preferred_lft forever


iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  


ip route show table all

default via 173.44.45.33 dev eth0 proto static metric 100 
173.44.45.32/27 dev eth0 proto kernel scope link src 173.44.45.44 metric 100 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 173.44.45.32 dev eth0 table local proto kernel scope link src 173.44.45.44 
local 173.44.45.44 dev eth0 table local proto kernel scope host src 173.44.45.44 
broadcast 173.44.45.63 dev eth0 table local proto kernel scope link src 173.44.45.44 
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101 
unreachable ::/96 dev lo metric 1024 error -113 
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113 
unreachable 2002:a00::/24 dev lo metric 1024 error -113 
unreachable 2002:7f00::/24 dev lo metric 1024 error -113 
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 
unreachable 2002:ac10::/28 dev lo metric 1024 error -113 
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 
unreachable 2002:e000::/19 dev lo metric 1024 error -113 
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113 
fe80::/64 dev eth0 proto kernel metric 256 
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101 
local ::1 dev lo table local proto none metric 0 
local fe80::216:3cff:fe9b:8b1a dev lo table local proto none metric 0 
ff00::/8 dev eth0 table local metric 256 
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101 


I am a rookie when it come to all this.
1. How do I get the Child_SA up and running (I am not seeing any error in the logs)
2. And also how do i prevent it from disconnecting after the re-authentication at a later time.

Please find attached a copy of my Charon.log, ipsec.conf, strongswan.conf.

Thanks

strongswan.conf (698 Bytes) strongswan.conf TeeJay OPA, 14.03.2018 10:43
ipsec.conf (628 Bytes) ipsec.conf TeeJay OPA, 14.03.2018 10:43
charon.log (81.6 KB) charon.log TeeJay OPA, 14.03.2018 10:45
charon.log (17.2 KB) charon.log TeeJay OPA, 16.03.2018 09:47
ipsec.conf (545 Bytes) ipsec.conf TeeJay OPA, 16.03.2018 09:49

History

#1 Updated by Tobias Brunner over 7 years ago

  • Category changed from ikev1 to configuration
  • Status changed from New to Feedback
  • Priority changed from Immediate to Normal
rightsourceip=10.42.42.0/24

Don't set this. The left|rightsourceip options are only used for virtual IPs, which are of no use in site-to-site setups.

dpdaction=restart
auto=start

For site-to-site scenarios using auto=route and dpdaction=clear will result in more stable tunnels.

However it seem this IKE Security Association Disconnect upon re-authentication, because when I check back after a couple of hours,

There is nothing about this in the log.

1. How do I get the Child_SA up and running (I am not seeing any error in the logs)

I think this is caused by the rightsourceip option. The daemon waits for the other end to initiate a mode config exchange so it can assign a virtual IP to it. Try removing that option.

2. And also how do i prevent it from disconnecting after the re-authentication at a later time.

Check the log when this happens again. But with trap policies (auto=route) the connection would get recreated anyway when there is matching traffic.

#2 Updated by TeeJay OPA over 7 years ago

Hello Tobais.

Thanks for your response.

When i remove rightsourceip from my configuration.

I know see an received INVALID_ID_INFORMATION error notify in my log file when I try do strongswan up conn-name.
I found a reference to it here https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Phase_2_Network_Mismatch
But I have no clue on how to solve this. Any recommendations please.

Fri, 2018-03-16 08:14 05[ENC] <kelvic-mtn|1> generating QUICK_MODE request 3570185755 [ HASH SA No ID ID ]
Fri, 2018-03-16 08:14 05[NET] <kelvic-mtn|1> sending packet: from 173.44.45.44[500] to 41.220.79.242[500] (268 bytes)
Fri, 2018-03-16 08:14 06[NET] <kelvic-mtn|1> received packet: from 41.220.79.242[500] to 173.44.45.44[500] (316 bytes)
Fri, 2018-03-16 08:14 06[ENC] <kelvic-mtn|1> parsed INFORMATIONAL_V1 request 1106609357 [ HASH N(INVAL_ID) ]
Fri, 2018-03-16 08:14 06[IKE] <kelvic-mtn|1> *received INVALID_ID_INFORMATION error notify*
Fri, 2018-03-16 08:14 06[CHD] <kelvic-mtn|1> CHILD_SA kelvic-mtn{2} state change: CREATED => DESTROYING
Fri, 2018-03-16 08:14 07[NET] <kelvic-mtn|1> received packet: from 41.220.79.242[500] to 173.44.45.44[500] (76 bytes)
Fri, 2018-03-16 08:14 07[ENC] <kelvic-mtn|1> parsed INFORMATIONAL_V1 request 3163712214 [ HASH D ]
Fri, 2018-03-16 08:14 07[IKE] <kelvic-mtn|1> received DELETE for IKE_SA kelvic-mtn[1]
Fri, 2018-03-16 08:14 07[IKE] <kelvic-mtn|1> deleting IKE_SA kelvic-mtn[1] between 173.44.45.44[173.44.45.44]...41.220.79.242[41.220.79.242]
Fri, 2018-03-16 08:14 07[IKE] <kelvic-mtn|1> IKE_SA kelvic-mtn[1] state change: ESTABLISHED => DELETING
Fri, 2018-03-16 08:14 07[IKE] <kelvic-mtn|1> IKE_SA kelvic-mtn[1] state change: DELETING => DELETING
Fri, 2018-03-16 08:14 07[IKE] <kelvic-mtn|1> IKE_SA kelvic-mtn[1] state change: DELETING => DESTROYING
ipsec.conf

config setup
    uniqueids=yes
    charondebug="all" 

conn %default
        rekeymargin=3m
        keyingtries=3
        keyexchange=ikev1
        authby=secret

conn kelvic-mtn
        left=173.44.45.44
        leftsubnet=192.168.2.0/24
        right=41.220.79.242
        rightid=41.220.79.242
        rightsubnet=10.2.0.0/24
        ike=aes128-md5-modp1024,3des-md5-modp1024!
        esp=3des-sha1,aes128-md5,aes128-sha1,3des,3des-md5!
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        auto=route
        type=tunnel
strongswan statusall

Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.10.0-693.11.6.el7.x86_64, x86_64):
  uptime: 33 minutes, since Mar 16 09:20:31 2018
  malloc: sbrk 1622016, mmap 0, used 508864, free 1113152
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp unity
Listening IP addresses:
  173.44.45.44
Connections:
  kelvic-mtn:  173.44.45.44...41.220.79.242  IKEv1, dpddelay=30s
  kelvic-mtn:   local:  [173.44.45.44] uses pre-shared key authentication
  kelvic-mtn:   remote: [41.220.79.242] uses pre-shared key authentication
  kelvic-mtn:   child:  192.168.2.0/24 === 10.2.0.0/24 TUNNEL, dpdaction=clear
Routed Connections:
  kelvic-mtn{1}:  ROUTED, TUNNEL, reqid 1
  kelvic-mtn{1}:   192.168.2.0/24 === 10.2.0.0/24
Security Associations (0 up, 0 connecting):
  none

And also the connection is automatically routed, but i have to run strongswan up conn-name before it attempts to create the security association. How can the connection be established without having to run strongswan up .

Thanks

#3 Updated by Tobias Brunner over 7 years ago

But I have no clue on how to solve this. Any recommendations please.

The configuration (left|rightsubnet) has to match the other end's exactly. Since you configured 10.42.42.0/24 before maybe that's what should be in rightsubnet.

And also the connection is automatically routed, but i have to run strongswan up conn-name before it attempts to create the security association. How can the connection be established without having to run strongswan up .

It is triggered by matching traffic (i.e. packets with a source address in leftsubnet and a destination address in rightsubnet).

#4 Updated by TeeJay OPA over 7 years ago

So I was able to Solve this.

First the Problem was caused because the other side of the connection are not using a similar technology. They do not have the Left and Right Subnet configuration like we on the left Side with Strongswan.
They use and ACL like this on there gateway.

access-list companyName extended permit ip host 41.206.4.75 host 173.44.45.44
access-list companyName extended permit ip host 41.220.77.137 host 173.44.45.44

So the ipsec.conf should be like this instead


conn %default
    rekeymargin=3m
        keyingtries=3
        keyexchange=ikev1
        authby=secret

conn conn-name-1
        left=173.44.45.44
        leftsubnet=173.44.45.44                          #correct local subnet ID
        right=41.220.79.242                                  #gateway address
        rightsubnet=41.206.4.75/32                      #The destination you are trying to reach
        ike=aes128-md5-modp1024,3des-md5-modp1024!
        esp=3des-sha1,aes128-md5,aes128-sha1,3des,3des-md5!
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        auto=start                                      #bring up this connection when strongswan starts
        type=tunnel
conn conn-name-2
        left=173.44.45.44
        leftsubnet=173.44.45.44                             #correct local subnet ID
        right=41.220.79.242                                    #gateway address
        rightsubnet=41.220.77.137/32                    #another destination you are trying to reach
        ike=aes128-md5-modp1024,3des-md5-modp1024!
        esp=3des-sha1,aes128-md5,aes128-sha1,3des,3des-md5!
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        auto=start                                      #bring up this connection when strongswan starts
        type=tunnel

Another thing i did is to write a script that telnets the endpoint at a 15 minutes interval. That keeps the connection open and solves the problem of it disconnecting after reauthentication timeout.

Thanks for your support.

#5 Updated by Tobias Brunner over 7 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required