Meraki to Cisco VPN

There are several scenarios where a site to site VPN between a Meraki MX device and a Cisco IOS device is needed.

Meraki calls these Non-Meraki VPN Peers.

 

The instructions for setting this up are here  but it does not appear to work. Or rather, the VPN shows as alive, but traffic doesn’t seem to flow

In this example, the Cisco887VA router (192.168.73.1/24) needs to be able to speak to a Meraki (10.10.50.1/24)

 

version 15.6
!
hostname MyCisco887
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
no logging console
!
no aaa new-model
ethernet lmi ce
!
no ip source-route

!
ip dhcp excluded-address 192.168.73.1 192.168.73.50
ip dhcp excluded-address 192.168.73.101 192.168.73.254
!
ip dhcp pool sdm-pool
import all
network 192.168.73.0 255.255.255.0
default-router 192.168.73.1
dns-server 8.8.8.8
lease 0 2

!
!
!
ip domain name astaris.local
ip name-server 8.8.8.8
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
license udi pid C887VA-K9 sn [SERIALNUMBER]
!
!
username [USERNAME] privilege 15 secret 5 [PASSWORD]
!
!
controller VDSL 0
!
!
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key meraki address [WAN ADDRESS OF MERAKI]

[START:NOTE: the preshared key in this case is just “meraki”. You can choose other, stronger, keys. But there does seem to be an issue, where if you choose a key with anything more complex than a-z, A-Z, 0-9 then it doesn’t work. So having ! or & or in your key causes it to fail.

The group, lifetime etc should all match what has been set in the Meraki dashboard END:NOTE]
!
!
crypto map 887-isakmp 1 ipsec-isakmp
set peer [WAN ADDRESS OF MERAKI]
set transform-set ESP-3DES-SHA
match address outgoing_to_MX
!
!
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface Ethernet0
no ip address
!
interface Ethernet0.101
encapsulation dot1Q 101
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface Vlan1
ip address 192.168.73.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Dialer0
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname [DSL INTERNET USERNAME]
ppp chap password 0 [DSL INTERNET PASSWORD]
no cdp enable
crypto map 887-isakmp
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip nat inside source list 101 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip ssh version 2
!
ip access-list extended outgoing_to_MX
permit ip 192.168.73.0 0.0.0.255 10.10.50.0 0.0.0.255
!
!
snmp-server community [SNMP PASSWORD] RO
!
access-list 100 permit ip host [REMOTE MANAGEMENT IP] any
access-list 100 permit ip 192.168.73.0 0.0.0.255 any

[START:NOTE access list 100 is applied to the console / vty lines. ie. who can ssh into the router. In this case any local device and anything from the external MANAGEMENT IP]

access-list 101 deny ip 192.168.73.0 0.0.0.255 10.10.50.0 0.0.0.255

[START:NOTE. We probably don’t need to explicitly say “do NOT send traffic for the Meraki side LAN out of the Dialer interface”, but it should stop the Cisco making an unexpected decision END:NOTE]

access-list 101 permit ip 192.168.73.0 0.0.0.255 any
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
no vstack
!
line con 0
exec-timeout 0 0
login local
no modem enable
line aux 0
line vty 0 4
access-class 100 in
exec-timeout 0 0
privilege level 15
password 7 [PASSWORD]
logging synchronous
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
ntp server uk.pool.ntp.org
!
end

 

The thing about IOS VPN’s is that they only come alive if there is interesting / relevant traffic. So running a ping from the Cisco to the Meraki should be enough to bring it alive and pass traffic.

However, from the Cisco, just doing “ping 10.10.50.1” doesn’t get a response. Doesn’t work.

Why doesn’t it work?

It’s because the Cisco needs to be sending the pings from the correct IP address / source. And by default it’s not. My assumption was that it would send the pings from 192.168.73.1. But it needs to be explicitly told this.

“ping 10.10.50.1 source 192.168.73.1” does work. First ping doesn’t make it as it takes a moment for the VPN tunnel to wake up – but the rest are fine.

I should probably look up what address the Cisco sends pings from by default. My guess is that for known local subnets it’s the IP on that subnet, for everything else it’s the interface that the default route is throwing everything at (in this case the WAN IP obtained on the Dialer interface)

 

The frustrating thing about this is that because you’d be doing testing from the router to make sure this worked, unless you add the “source” bit, it won’t seem to work. But had you been running the test from a desktop on, say, 192.168.73.50 it would have worked.

 

There are probably other ways to do this. Probably should have additional restrictions in the access lists. Probably should have vty sessions time out etc. General hardening of the above config. But as a proof of concept and the “Can we get it to work from our test bench?” this will do just fine.