I have kind of a challenge and need some advice if the configuration I want to do is actually possible. Please don't kill me, I know that the configuration is not very "nice"...
We are using DMVPN for our WAN, where a default route is coming through EIGRP running over that DMVPN instance. A frontdoor VRF is used for the tunnel endpoint, where we have a default route towards the provider.
The interfaces are:
- Gi0/0/0 (outside), VRF: inet, 0.0.0.0/0 pointing towards ISP
- Gi0/0/1 (inside), VRF: default, 0.0.0.0/0 pointing towards DMVPN hub
- Tun0 (DMVPN), VRF: default
Traffic is coming in through the inside interface and is routed through the tunnel towards the DMVPN hub. To implement Direct Internet Access on this site, we work together with a cloud security provider to do the filtering of our web traffic. To do that, we need to establish a tunnel to that provider, sending only web traffic through that tunnel. The security provider only supports policy-based tunnels (crypto map, no VTI).
The crypto map can be defined, that is not an issue, and needs to be applied to the egress interface. I however doubt, without trying though, that a crypto map can be applied to the tunnel interface.
The alternative solution now is to implement Policy Based Routing to put the web traffic to the other VRF and apply the crypto map to Gi0/0/0, like that:
ip access-list extended DIA-OUT
permit tcp any any eq 80
permit tcp any any eq 443
ip access-list extended DIA-IN
permit tcp any eq 80 any
permit tcp any eq 443 any
ip access-list extended TEN
permit ip any 10.0.0.0 0.255.255.255
route-map DIA-OUT deny 10
match ip address TEN
route-map DIA-OUT permit 20
match ip address DIA-OUT
set vrf frontdoor
! if that does not work
! set ip next-hop recursive vrf inet-public 8.8.8.8
! As no specific route for 8.8.8.8 exists, the default route will
! be used. Not sure if the crypto map applies then, though
route-map DIA-IN permit 10
match ip address DIA-IN
set global
crypto map DIA_CRYPTO_MAP 100 ipsec-isakmp
set peer vpn.mycloudprovider.com dynamic
set transform-set MY_SET
set isakmp-profile MY_PROFILE
match address DIA-OUT
interface GigabitEthernet 0/0/0
description outside
ip vrf frontdoor
ip address dhcp
ip policy route-map DIA-IN
! unsure if the crypto map applies here
crypto map DIA_CRYPTO_MAP
interface GigabitEthernet 0/0/1
description inside
ip address <inside-ip> 255.255.255.0
ip policy route-map DIA-OUT
ip vrf receive frontdoor
(Some more info on the use of ip vrf receive can be found here)
On the outside interface, there only should be three different types of traffic:
- IPSec encapsulated DMVPN traffic with the public IP as source IP
- Web Traffic on port 80, 10/8 as source
- Web Traffic on port 443, 10/8 as source
No NAT is configured, and probably I will add an ACL to drop web traffic if the tunnel is down. Even though this is untested, I am somehow confident it should work (if you have a better approach, or think that the solution described above does not work, please let me know :=) ). The only thing I am unsure about is if the PBR on Gi0/0/0 will work on the VPN traffic. Let's see...
Now the real problem:
The DIA-OUT route-map redirects the traffic to the frontdoor VRF, no matter if the tunnel is up or not. I would somehow like to make sure that this only happens if the tunnel is actually up. Otherwise, the traffic is forwarded through DMVPN, following the default route.
Now, even if I could track the IPSec SA, this is kind of a chicken and egg problem. The tunnel is only built of some traffic is actually hitting the crypto map.
I cannot use reliable PBR (verify reachability) as I don't know the next hop (technically there is none as I use the crypto map). I could use a combination of IP SLA and track to check reachability through the tunnel, however I cannot influence the PBR decision based on a track object. match track does not work to my knowledge.
Any idea how to do that reliably?
