DMVPN spoke side IPsec peer/leftid issues


#1

Hi all,

I’ve been working on getting DMVPN/NHRP setup between two VyOS boxes – one is in AWS and the other behind my home’s NATed router on an ESX box.

Here is the basic layout:

My problem is that my ESX vyos box at home keeps sending a peer ID of the private address rather than the public address that I’ve set in leftid in /etc/dmvpn.conf. These two boxes are setup nearly identical and changing the leftid on the AWS side works correctly.

Here are relevant settings and logs:

AWS config:

interfaces {
     dummy dum0 {
         address 192.168.50.1/24
     }
     ethernet eth0 {
         address dhcp #10.10.20.31
         duplex auto
         smp_affinity auto
         speed auto
     }
     loopback lo {
     }
     tunnel tun0 {
         address 10.0.0.10/24
         encapsulation gre
         local-ip 10.10.20.31
         multicast enable
     }
 }
 protocols {
     nhrp {
         tunnel tun0 {
             cisco-authentication MYSECRET
             holding-time 300
             multicast dynamic
             redirect
         }
     }
     static {
         route 10.20.0.0/16 {
             next-hop 10.0.0.20 {
             }
         }
     }
 }
 vpn {
     ipsec {
         esp-group ESP-HUB1 {
             compression disable
             lifetime 1800
             mode tunnel
             pfs dh-group2
             proposal 1 {
                 encryption aes256
                 hash sha1
             }
             proposal 2 {
                 encryption 3des
                 hash md5
             }
         }
         ike-group IKE-HUB1 {
             key-exchange ikev2
             lifetime 3600
             proposal 1 {
                 encryption aes256
                 hash sha1
             }
             proposal 2 {
                 encryption aes128
                 hash sha1
             }
         }
         ipsec-interfaces {
             interface eth0
         }
         nat-traversal enable
         profile NHRPVPN {
             authentication {
                 mode pre-shared-secret
                 pre-shared-secret MYSECRET
             }
             bind {
                 tunnel tun0
             }
             esp-group ESP-HUB1
             ike-group IKE-HUB1
         }
     }
 }

AWS /etc/dmvpn.conf:

conn vpnprof-tunnel-tun0
        left=10.10.20.31
        leftid=1.1.1.1
        right=%any
        rekey=no
        leftprotoport=gre
        rightprotoport=gre
        ike=aes256-sha1,aes128-sha1!
        ikelifetime=3600s
        esp=aes256-sha1,3des-md5!
        keylife=1800s
        rekeymargin=540s
        type=tunnel
        pfs=yes
        pfsgroup=modp1024
        compress=no
        authby=secret
        auto=add
        keyingtries=%forever

After adding in the leftid variable I run ipsec reload as root so it’s known

AWS logs:

Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[1] 2.2.2.2 #12: responding to Main Mode from unknown peer 2.2.2.2
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[1] 2.2.2.2 #12: NAT-Traversal: Result using RFC 3947: both are NATed
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[1] 2.2.2.2 #12: Peer ID is ID_IPV4_ADDR: '192.168.1.10'
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[2] 2.2.2.2 #12: deleting connection "vpnprof-tunnel-tun0" instance with peer 2.2.2.2 {isakmp=#0/ipsec=#0}
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[2] 2.2.2.2:4500 #12: sent MR3, ISAKMP SA established
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[2] 2.2.2.2:4500 #12: cannot respond to IPsec SA request because no connection is known for 1.1.1.1/32===10.10.20.31:4500[1.1.1.1]:47/0...2.2.2.2:4500[192.168.1.10]:47/0===192.168.1.10/32
Mar 14 19:24:45 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[2] 2.2.2.2:4500 #12: sending encrypted notification INVALID_ID_INFORMATION to 2.2.2.2:4500
Mar 14 19:24:55 VyOS-AMI pluto[2761]: "vpnprof-tunnel-tun0"[2] 2.2.2.2:4500 #12: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xdc7bc1db (perhaps this is a duplicated packet)

Home config:

interfaces {
     ethernet eth1 {
         address 192.168.1.10/24
         duplex auto
         smp_affinity auto
         speed auto
     }
     loopback lo {
     }
     tunnel tun0 {
         address 10.0.0.20/24
         encapsulation gre
         local-ip 192.168.1.10
         multicast enable
     }
 }
 protocols {
     nhrp {
         tunnel tun0 {
             cisco-authentication MYSECRET
             map 10.0.0.10/24 {
                 nbma-address 1.1.1.1
                 register
             }
             multicast nhs
             redirect
             shortcut
         }
     }
     static {
         route 0.0.0.0/0 {
             next-hop 192.168.1.1 {
             }
         }
         route 192.168.50.0/24 {
             next-hop 10.0.0.10 {
             }
         }
     }
 }
 vpn {
     ipsec {
         esp-group ESP-SPOKE1 {
             lifetime 1800
             pfs dh-group2
             proposal 1 {
                 encryption aes256
                 hash sha1
             }
             proposal 2 {
                 encryption 3des
                 hash md5
             }
         }
         ike-group IKE-SPOKE1 {
             key-exchange ikev2
             lifetime 3600
             proposal 1 {
                 encryption aes256
                 hash sha1
             }
             proposal 2 {
                 encryption aes128
                 hash sha1
             }
         }
         ipsec-interfaces {
             interface eth1
         }
         nat-traversal enable
         profile NHRPVPN {
             authentication {
                 mode pre-shared-secret
                 pre-shared-secret MYSECRET
             }
             bind {
                 tunnel tun0
             }
             esp-group ESP-SPOKE1
             ike-group IKE-SPOKE1
         }
     }
 }

Home /etc/dmvpn.conf:

conn vpnprof-tunnel-tun0
        left=192.168.1.10
        leftid=2.2.2.2
        right=%any
        rekey=no
        leftprotoport=gre
        rightprotoport=gre
        ike=aes256-sha1,aes128-sha1!
        ikelifetime=3600s
        esp=aes256-sha1,3des-md5!
        keylife=1800s
        rekeymargin=540s
        type=tunnel
        pfs=yes
        pfsgroup=modp1024
        compress=no
        authby=secret
        auto=add
        keyingtries=%forever

To add left id here and be able to reinitiate a connection I had to manually hardcode the leftid into /opt/vyatta/sbin/dmvpn-config.pl line 120 as so:
my $authid = “2.2.2.2”;
#$vcVPN->returnValue(“ipsec profile $profile authentication id”);

That way after restarting OpenNHRP with “/etc/init.d/opennhrp.init restart” the value is filled in before initiating a new IPsec connection

Home logs:

Mar 15 03:27:57 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: enabling possible NAT-traversal with method 3
Mar 15 03:27:58 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: NAT-Traversal: Result using RFC 3947: both are NATed
Mar 15 03:27:58 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: Peer ID is ID_IPV4_ADDR: '1.1.1.1'
Mar 15 03:27:58 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: ISAKMP SA established
Mar 15 03:27:58 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #6: initiating Quick Mode PSK+ENCRYPT+PFS+UP {using isakmp#5}
Mar 15 03:27:58 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Mar 15 03:28:08 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: ignoring informational payload, type INVALID_MESSAGE_ID
Mar 15 03:28:28 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #5: ignoring informational payload, type INVALID_MESSAGE_ID
Mar 15 03:29:08 esx-vyos pluto[4235]: "10.0.0.20-to-10.0.0.10" #6: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

I’m able to make connections between the two machines fine so I believe I can rule out it being a firewall issue.

Right now I figure the issue is somewhere along where vyos is initiating the ipsec tunnel it’s ignoring the leftid field – but oddly it doesn’t ignore it on the hub AWS side, only on the spoke side.

I suppose something could be wrong with the strongswan code itself while reading the dmvpn.conf file but that would seem odd since the AWS side works fine.

Also, I realize the leftid will not persist without code changes so if I can get this up and running correctly I’ll make the necessary code changes to VyOS to add “id” as a variable in NHRP profiles to persist it.

Any help would be much appreciated while I waste the next week of my life troubleshooting this!

Thanks


#2

Did you ever get this working?


#3

Unfortunately I did not. I ended up just moving my VyOS box to the edge and used it as my router. That said, I’ve been talking with Timo who is in the process of upgrading some things in OpenNHRP so he may have already made some changes to fix this. If not, we could probably ask him to look into it.