Some months ago, I got in contact with one of my old colleagues and friend. Our discussion led to trying to decide what to do next with our home labs. He mentioned that he has a small block of provider assigned public IPv4 addresses. We got what seemed like a crazy idea – “Let’s do a DMVPN between our houses!”. Since he has static IPs, his router would act as the hub and mine would be a spoke behind at least 1 NAT.
It wasn’t until we started trying to implement this thing that I realized I had an issue. My lab is in my home office and my ISP provided modem and router/WAP are in a different room. For a myriad of reasons I did not want to run a cable through the house to connect my lab to the ISP gear. Eureka! Maybe I can use a Raspberry Pi as a wireless link! The trick is configuring the Pi to NAT traffic received on its Eth0 interface to its WLAN0 address. With the Pi doing NAT my ISP router/WAP thinks my home lab is directly connected. It feels like a hack, but it works. We were able to get a phase 1 DMVPN to work with the spoke behind double NAT. After tinkering with this for a few weeks we got bored, stopped working on the DMVPN and erased our configs. Weeks later I told some others about this experiment, and they were interested in joining in. We restored the original hub and spoke.
After the excitement of seeing IPsec/DMVPN reestablished our setup has evolved. We’re using eBGP to advertise summary routes for our internal lab subnets. My DMVPN router is configured with Zone Based Firewall (ZBFW), NTP sync with my time server, and several other features. I’m currently using OSPFv2 in my internal network. I’m considering revising my internal routing to use OSPF or IS-IS for loopback reachability and iBGP route reflection. The link from my DMVPN router to the Pi is using untagged frames for VPN traffic and an 802.1Q tagged sub interface for services such as NTP and SSH for automation. The DMVPN router and Pi are peering with iBGP across the tagged link. The tagged and untagged router interfaces are in their own ZBFW security zones.
An online chat room was started, and one member got their lab connected to the hub yesterday. We’re hoping to increase this to a few more spokes. There are also plans to stand up a 2nd hub router to try out IPv6 DMVPN over IPv4 underlay. We decided not to dual stack tunnels to make the design more challenging. I am going to attempt sourcing my IPv4 and IPv6 tunnels from the same router. We have also discussed trying dual hubs behind a load balancer.
Config Snippets
interface Tunnel10
description DMVPN TUNNEL
bandwidth 20000
ip address 172.16.0.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication $key
ip nhrp map 172.16.0.1 $hub public IP
ip nhrp map multicast $hub public IP
ip nhrp network-id 1
ip nhrp holdtime 400
ip nhrp nhs 172.16.0.1
zone-member security TUNNEL
ip tcp adjust-mss 1360
delay 1000
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key $key
tunnel protection ipsec profile DMVPN_IPSEC_PROFILE
router ospf 1
auto-cost reference-bandwidth 1000
area 0 authentication message-digest
passive-interface GigabitEthernet0/0
network 172.29.1.0 0.0.0.7 area 0
network 172.29.254.1 0.0.0.0 area 0
default-information originate always metric-type 1
!
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.0.1 remote-as 65000
neighbor 172.29.0.5 remote-as 65001
!
address-family ipv4
network 172.29.0.0
aggregate-address 172.29.0.0 255.255.0.0 summary-only
neighbor 172.16.0.1 activate
neighbor 172.16.0.1 route-map DMVPN_BGP_IN_RM in
neighbor 172.16.0.1 route-map DMVPN_BGP_OUT_RM out
neighbor 172.29.0.5 activate
neighbor 172.29.0.5 next-hop-self
neighbor 172.29.0.5 route-map DMVPN_BGP_OUT_RM out
exit-address-family
!
Rough Diagram
