4

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?

1

As I have not received an answer yet and did not find a solution myself I had to assume that it is simply not possible. As we are changing our cloud security provider anyway and can now work with VTIs, I will not follow up on that topic.

For now I assume it is not possible to implement as requested and accept this answer. If someone else finds an answer and posts it here I'll be happy to accept the answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.