Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DMVPN interesting traffic


I have currently set up a DMVPN between the hub and two spokes.

What I wanted now is to force a specific traffic (SMTP for example) to go through the tunnel and divert everything else for the WAN connection that also exists.

Can anyone tell me how I can do this?

Here is the hub config of my VPN:

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

crypto isakmp key THEKEY address

crypto isakmp invalid-spi-recovery

crypto isakmp keepalive 10 periodic



crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

mode transport


crypto ipsec profile SDM_Profile1

set transform-set ESP-3DES-SHA






interface Tunnel0

bandwidth 1000

ip address

no ip redirects

ip mtu 1400

ip nhrp authentication DMVPN_NW

ip nhrp map multicast dynamic

ip nhrp network-id 100000

ip nhrp holdtime 360

ip nhrp cache non-authoritative

ip tcp adjust-mss 1360

ip ospf network point-to-multipoint non-broadcast

ip ospf priority 20

delay 1000

tunnel source FastEthernet0/0.1

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile SDM_Profile1



Cisco Employee

Re: DMVPN interesting traffic

Hi Paulo,

Traffic being encrypted is BASED on the routing table, so anything that points to Tunnel0 is going to be encrypted.

In order to force specific traffic (e.g. SMTP), you may have to configure Policy-Based Routing (PBR) i.e. configure class-map to match specific traffic and set the next-hop to Tunnel0. For all other traffic set the next-hop to WAN interface. That way, you will only force selected traffic to Tunnel0.

Note: I haven't tried this scenario myself, but interesting Qs... pls try PBR and let us know if it works for you.

my 2 cents.



New Member

Re: DMVPN interesting traffic

Hi Yusuf,

it is nice to catch you on the net. With all the respect to you personally and your knowledge, I guess the sequence in the PBR is the other way around of what you suggested, since the default is to send the encrypted traffic to the tunnel based on its subnet/routing table, then the 1st sequence in the PBR is to match against SMTP and set its interface to the physical interface and the next PBR sequence wouldn't have a match. This way all unmatched traffic earlier will go through the tunnel.

Pls comment.


Sami salim