DMVPN Tunnel Encryption Evidence

Answered Question
Feb 19th, 2010

I have been configuring VPN's for a short time and Im trying to get a better

understanding of the mechanics.

I configured DMVPN between an HQ router and two branches. Im running eigrp between the routers through the gre tunnel interfaces. I can see eigrp neighbors via the tunnel which is good. The part Im trying to understand is, I have not created any ACL's and I seem to be forming eigrp neighbor relationships through the tunnels. If I ping or telnet from the HQ router to one of the branches I presume Im going through the tunnel and the traffic is encrypted. I would like to be able to prove this and see evidence.

Do I have to have ACL's configured to tell the router what to encrypt?? Or the fact that the tunnel has a crypto profile applied does that take care of it??

I did a test and telneted from HQ to Branch 1 using private addresses that were being routed through the tunnel and then entered the command

sh crypto ipsec sa. My telnet source address is the loopback of the router which is 172.22.3.1 I though I would see 172.22.3.1 or 172.22.1.1 in the command out put below and I dont which make me wonder if the traffic is being encrypted. May be my configs are incorrect or I need a different show command?

I have attached my router configs also. If anyone could help me understand a little more it would be appreciated.

Andy

lab-HQ-rtr#telnet 172.22.1.1 this is Branch1rtr
Trying 172.22.1.1 ... Open


User Access Verification

Username: andrewb
Password:

lab-branch1-rtr#sh crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 50.50.50.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (50.50.50.1/255.255.255.255/47/0) ***Thought I would see the src and dst address of the telnet**

   remote ident (addr/mask/prot/port): (50.50.50.3/255.255.255.255/47/0)
   current_peer 50.50.50.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 14307, #pkts encrypt: 14307, #pkts digest: 14307
    #pkts decaps: 14286, #pkts decrypt: 14286, #pkts verify: 14286
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 24, #recv errors 0

     local crypto endpt.: 50.50.50.1, remote crypto endpt.: 50.50.50.3
     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0
     current outbound spi: 0x61D48BA8(1641319336)

     inbound esp sas:
      spi: 0x555FD9F(89521567)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Transport, }
        conn id: 2037, flow_id: Onboard VPN:37, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4598507/3044)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x61D48BA8(1641319336)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Transport, }
        conn id: 2038, flow_id: Onboard VPN:38, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4598507/3033)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
lab-branch1-rtr#

lab-HQ-rtr#sh ip route
C       50.50.50.0 is directly connected, Serial0/0/0
     172.22.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       172.22.3.1/32 is directly connected, Loopback0
D       172.22.2.1/32 [90/2944000] via 192.168.254.2, 21:18:04, Tunnel0
D       172.22.1.1/32 [90/2944000] via 192.168.254.1, 21:19:00, Tunnel0
D       172.22.64.32/27 [90/2816256] via 192.168.254.2, 21:18:04, Tunnel0
                        [90/2816256] via 192.168.254.1, 21:18:04, Tunnel0
     10.0.0.0/24 is subnetted, 5 subnets
D       10.10.10.0 [90/2816256] via 192.168.254.1, 21:19:00, Tunnel0
D       10.10.20.0 [90/2816256] via 192.168.254.1, 21:19:00, Tunnel0
D       10.10.30.0 [90/2816256] via 192.168.254.2, 21:18:04, Tunnel0
D       10.10.40.0 [90/2816256] via 192.168.254.2, 21:18:04, Tunnel0
D       10.10.50.0 [90/2816256] via 192.168.254.1, 21:19:02, Tunnel0
C    192.168.254.0/24 is directly connected, Tunnel0
C    192.168.1.0/24 is directly connected, FastEthernet0/0

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
50.50.50.3      50.50.50.2      QM_IDLE           1002    0 ACTIVE
50.50.50.3      50.50.50.1      QM_IDLE           1001    0 ACTIVE

I have this problem too.
0 votes
Correct Answer by Lei Tian about 6 years 9 months ago

Hi Andy,

DMVPN will use routing to control what traffic will be encrypted. You can add ACL like the regular crypto-map to specify interest traffic, but that is not must to have.

When traffic leave the router, it will do the routing lookup first; if the next-hop is pointing to your tunnel interface then the traffic will be encapsulated and encrypted; if the next-hop is pointing to some other interface, the traffic will leave the router w/o encryption.

isakmp SAs are built between your tunnel endpoints, as you see from the output of "show crypto isakmp sa". You can verify traffic been encrypted or not by looking the
    #pkts encaps: 14307, #pkts encrypt: 14307, #pkts digest: 14307
    #pkts decaps: 14286, #pkts decrypt: 14286, #pkts verify: 14286

If you really want to see the packet, you can SPAN the traffic to a monitor station.

HTH,

Lei Tian

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Lei Tian Fri, 02/19/2010 - 11:36

Hi Andy,

DMVPN will use routing to control what traffic will be encrypted. You can add ACL like the regular crypto-map to specify interest traffic, but that is not must to have.

When traffic leave the router, it will do the routing lookup first; if the next-hop is pointing to your tunnel interface then the traffic will be encapsulated and encrypted; if the next-hop is pointing to some other interface, the traffic will leave the router w/o encryption.

isakmp SAs are built between your tunnel endpoints, as you see from the output of "show crypto isakmp sa". You can verify traffic been encrypted or not by looking the
    #pkts encaps: 14307, #pkts encrypt: 14307, #pkts digest: 14307
    #pkts decaps: 14286, #pkts decrypt: 14286, #pkts verify: 14286

If you really want to see the packet, you can SPAN the traffic to a monitor station.

HTH,

Lei Tian

networkwise Fri, 02/19/2010 - 13:10

Thankyou for the clarification I thought that may be the case but I was not sure.

Thnaks Lei ,

Andy

Actions

This Discussion