First, let me start by saying I love the Meraki networking stack.  It is easy and efficient to deploy and customers love it.  Occasionally, however, you find a key feature that Meraki won’t do.  In this case, Any Connect client VPN.

Any Connect is easy to deploy, it’s flexible and works on just about any client platform.   In my design, I wanted to backhaul all Any Connect client traffic into the corporate network and then treat it with the same internet edge polies as corprate users.  The Meraki MX series firewall is the source of policy enforcement so traffic will need to enter the network and then be routed through this device before going onto the wide open internet.   The prior WAN routers where ISR G2’s so I decided to pull one of them off the shelf to stand in as the Any Connect termination point.  An ISR is extremely flexible when it comes to routing tricks as well.

First, here is the desired topology and traffic flows.

As you can see the traffic is decrypted on the ISR and then takes another path to the internet through the Meraki MX.  In theory this is simple, however, in practice the problem becomes the default routing on the ISR.  More specifically the router gets its default route and that route directs traffic out the outside interface toward the internet.  The problem is that the VPN traffic decrypted on that router needs to actually follow a different default route that will take it through the Meraki MX firewall prior to going to the internet.  Because of this scenario, we will put the ISR’s internet facing interface in its own VRF, aka seperate routing instance, aka front door VRF, to terminate the tunnel but then dump the client addresses into the global routing table.  If VRF’s are new to you it might be helpful to check out this post as well.  Below I have added some IP information to better explain the design.

The 1.1.1.2 IP address lives in the INET VRF.  A common term for this is a “front door VRF” because it’s the direct interface, or front door, to the internet.  All remaining IP addresses will be configured or dynamically allocated within the global routing instance.  Depending on your topology it is also very likely your router will need to be advertising routes for the VPN clients into your corporate network to ensure full round trip connectivity.  The global routing process will also pick up a default route from the corporate network that will guide traffic through the Meraki firewall.  This default route would have confliceted with the routers default route to the interned had we not used the VRF features.

Enough theory. Let’s see the configuration.

First, the VRF, outside interface and detault route:

ip vrf INET1
interface GigabitEthernet0/0
 ip vrf forwarding INET1
 ip address 1.1.1.2 255.255.255.0
ip route vrf INET1 0.0.0.0 0.0.0.0 1.1.1.254

Next, the supporting and direct configuration of the VPN headend.

ip local pool VPN_POOL 192.168.99.1 192.168.99.254
webvpn gateway VPN_GATEWAY
ip address 1.1.1.2 port 443
 ssl trustpoint VPN_TRUSTPOINT
 vrfname INET1
 inservice
 !
webvpn context VPN_CONTEXT
 title "VPN Connectivity"
 !
aaa authentication list SSL_VPN
 gateway VPN_GATEWAY
 !
 ssl authenticate verify all
 inservice
 !
 policy group WEBVPN_GP1
   functions svc-enabled
   banner "WELCOME to the VPN"
   svc address-pool "VPN_POOL" netmask 255.255.255.0
   svc rekey method new-tunnel
   svc dns-server primary 4.2.2.2
 default-group-policy WEBVPN_GP1

The diagram refers to the fact that the remote access client subnet will need to be advertised to the rest of the network.  The clients actually show up in global routing table as static /32 routes when they connect.  This isn’t a problem as long as we remember to redistribute them into our routing protocol of choice and along to the rest of the network.  In the case of my example I am grabbing them with a prefix list inside a route-map with the redistribute static command to dump it all into EIGRP.  You will notice the prefixes are “le” options on this command.  This indicates that only prefixes of /32 are matched.  Finally, depending on the size of your client pool it may be advantageous to summarize the whole batch of clients into a single summary route for efficiency.

ip prefix-list SSL_CLIENTS seq 10 permit 192.168.19.0/24 le 32
 match ip address prefix-list SSL_CLIENTS
route-map EIGRP_DISTRIBUTE permit 10
 match ip address prefix-list SSL_CLIENTS
router eigrp 100
 network 192.168.1.0 0.0.0.255
redistribute static route-map EIGRP_DISTRIBUTE
interface GigabitEthernet0/1
 ip summary-address eigrp 100 192.168.99.0 255.255.255.0

To troubleshoot be sure to review both routing tables.  Your VRF routing table should include a default and the internet segment and likely nothing else.

R1#show ip route vrf INET1
Routing Table: INET1
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override
Gateway of last resort is 1.1.1.254 to network 0.0.0.0
S*    0.0.0.0/0 [1/0] via 1.1.1.254
      1.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, GigabitEthernet0/0
L        1.1.1.2/32 is directly connected, GigabitEthernet0/0

The global routing table will include any other internal routes you would like your users to have access to.  Since my environment is allowing everyone full access (this is a lab) you will see all of my routes listed on the VPN edge router.

R1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override
Gateway of last resort is 192.168.1.2 to network 0.0.0.0
D*EX  0.0.0.0/0 [170/5376] via 192.168.202.1, 17:50:59, GigabitEthernet0/1
      10.0.0.0/8 is variably subnetted, 13 subnets, 4 masks
D        10.0.0.0/29
           [90/3072] via 192.168.1.2, 17:50:59, GigabitEthernet0/1
D        10.10.10.10/32
           [90/130816] via 192.168.1.2,  17:50:59, GigabitEthernet0/1
D        192.168.1.0/30
           [90/26880256] via 192.168.1.2, 17:50:59, GigabitEthernet0/1

While each use case will probably be a bit different, I hope you found this information useful!  Please feel free to leave your comments or questions below.