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=%foreverAfter 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=%foreverTo 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 proposalI’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