cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3706
Views
0
Helpful
4
Replies

Interesting traffic not entering tunnel

Hello All,

I am trying to set up a VPN between our Router(iS5 Raptor) and Cisco. I can see that the IPSec tunnel is up but traffic is not pushed into the tunnel on the Cisco side. I do not have any NAT.

 

My setup is given below:

(PC1) 192.168.9.3 -- 192.168.9.1 (Router 1) 172.16.31.1 --- 172.16.31.3 (Router 2) 172.16.21.3 --- 172.16.21.1 (CISCO) 10.10.9.1 -- 10.10.9.3 (PC2)

 

Tunnel between 172.16.31.1 == 172.16.21.1

Ping form PC2 (10.10.9.3) to 192.168.9.3 (PC1)

The  packets reach Cisco (Src: 10.10.9.3, Dest: 192.168.9.3: Interesting traffic)

But instead of being pushed into the tunnel, they end up on the default route.

I am expecting to see an ESP packet pushed into the tunnel for the ic

 

I'm guessing that some routing config is missing. But cannot figure it out.

 

Would highly appreciate if someone can point out the mistake in my configuration.

 

Thanks for looking at my query.

 

Details below:

The IPSec tunnel is up:

Switch#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.16.21.1     172.16.31.1     QM_IDLE           1012 ACTIVE
IPv6 Crypto ISAKMP SA
Switch#
Switch#show crypto ipsec sa
interface: GigabitEthernet1/0/1
    Crypto map tag: MYMAP, local addr 172.16.21.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.10.9.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.9.0/255.255.255.0/0/0)
   current_peer 172.16.31.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: 172.16.21.1, remote crypto endpt.: 172.16.31.1
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1/0/1
     current outbound spi: 0xCF9D0023(3483172899)
     PFS (Y/N): Y, DH group: group5
     inbound esp sas:
      spi: 0x7BB8648(129730120)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 7, flow_id: 7, sibling_flags 80000040, crypto map: MYMAP
        sa timing: remaining key lifetime (k/sec): (4151847/1277)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0xCF9D0023(3483172899)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 8, flow_id: 8, sibling_flags 80000040, crypto map: MYMAP
        sa timing: remaining key lifetime (k/sec): (4151847/1277)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)
     outbound ah sas:
     outbound pcp sas:
Switch#
My cisco configuration is given below:
 
# VPN config
en
conf t
crypto isakmp policy 10
encr aes 128
hash sha256
authentication pre-share
group 5
lifetime 3600
exit
crypto isakmp key presharedkey address 172.16.31.1
crypto ipsec transform-set TRAN esp-aes 128 esp-sha-hmac
 mode tunnel
exit
crypto map MYMAP 10 ipsec-isakmp
 set peer 172.16.31.1
set transform-set TRAN
 match address 100
exit
access-list 100 permit ip 10.10.9.0 0.0.0.255 192.168.9.0 0.0.0.255
interface gig 1/0/1
crypto map MYMAP
ip route 0.0.0.0 0.0.0.0 172.16.21.3
 
 

 

1 Accepted Solution

Accepted Solutions

The issue was a routing issue on the Cisco router. I found a previous post which pointed to the resolution:

 

https://community.cisco.com/t5/vpn/ipsec-vpn-on-2801-tunnel-up-but-one-way-traffic-decaps-only-no/td-p/3001620

 

The resolution in my case was the following route:

 

ip route 192.168.9.0 255.255.255.0 gi 1/0/1

 

This forces traffic towards the gi 1/0/1 and th

View solution in original post

4 Replies 4

Hi,

You can tell from your output that the cisco router is encrypting traffic, but not decrypting. Therefore you should check the configuration on the other router. Confirm whether on not traffic is received, whether traffic could be natted, check routing, check the crypto ACL etc.

 

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

 

HTH

Good morning,

Thanks for your response.

My mistake. I did not explain the issue good enough.

Doing a ping from the Cisco router with a proper source works great. The packets are encrypted and decrypted as expected.

The problem is when PC2(10.10.9.3) sends a ping request to 192.168.9 over the tunnel. Cisco router receives the packet as it is the default GW for PC2. But instead of pushing it into the tunnel it sends it to it's default GW 172.16.21.3.  I can see unencrypted pings coming to 172.16.21.3.

Would highly appreciate some pointers which will allow the Cisco router to push routed traffic coming in from end device into the tunnel.

 

The routes on my Cisco routers are as follows:

S*    0.0.0.0/0 [1/0] via 172.16.21.3
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.10.9.0/24 is directly connected, GigabitEthernet1/0/2
L        10.10.9.1/32 is directly connected, GigabitEthernet1/0/2
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.21.0/24 is directly connected, GigabitEthernet1/0/1
L        172.16.21.1/32 is directly connected, GigabitEthernet1/0/1
S        172.16.31.0/24 [1/0] via 172.16.21.3
Switch#

 

Some logs of correct encryption/decryption:

Counter values at start:

Switch#show crypto ipsec sa
interface: GigabitEthernet1/0/1
    #pkts encaps: 35, #pkts encrypt: 35, #pkts digest: 35
    #pkts decaps: 20, #pkts decrypt: 20, #pkts verify: 20
 
Do a ping:
Switch#ping 192.168.9.1 source 10.10.9.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.9.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.9.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
Switch#
 
Check counters: This is good and correct. Encryption decryption happens as expected.
Switch#show crypto ipsec sa
interface: GigabitEthernet1/0/1
    Crypto map tag: MYMAP, local addr 172.16.21.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.10.9.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.9.0/255.255.255.0/0/0)
...
    #pkts encaps: 40, #pkts encrypt: 40, #pkts digest: 40
    #pkts decaps: 25, #pkts decrypt: 25, #pkts verify: 25
 
Problem scenario:
Now: I ping from 10.10.9.3 and the packets are not pushed into the tunnel. They end up unencrypted on the default route of the Cisco router.

 

The issue was a routing issue on the Cisco router. I found a previous post which pointed to the resolution:

 

https://community.cisco.com/t5/vpn/ipsec-vpn-on-2801-tunnel-up-but-one-way-traffic-decaps-only-no/td-p/3001620

 

The resolution in my case was the following route:

 

ip route 192.168.9.0 255.255.255.0 gi 1/0/1

 

This forces traffic towards the gi 1/0/1 and th

Hello All,

The solution for some reason is not working anymore.

Cisco router is sending out an ARP for the interesting traffic on the default route of the interface.

 

who has 192.168.9.3 tell 172.16.21.1 <-- This is comes out on the middle router.

 

Something does not seem right here. The ICMP request should just enter the tunnel, I think without triggering an ARP.

Am not getting anywhere. Any inputs would be highly appreciated.

Tx.