Cisco IPsec Easy VPN Configuration

[ReneMolenaar]

Hello Dinesh,

Without going into too much detail of this specific topology, let me give some examples and tools of how to troubleshoot a problem like this. Once you know how to deal with this, you can fix any topology. Like Lazaros mentioned, you should:

@lagapidis

Now you’re unable to ping from the VPN client to the web server, but you don’t know up to where the packet is going. Check to see how far the packet gets, to see if it actually reaches the web server and fails on the return, or if it never reaches it at all. Check all devices in between to see where the packet fails.

Finally, check your NAT rules. Specifically, when you ping, check your translations and make sure that the address isn’t being translated in error before trying to be sent.

I’ll use this example topology. Four routers with EIGRP, full reachability:

Traceroute

Doing a trace is a good way to start. A single probe is fine:

R1#traceroute 4.4.4.4 probe 1          
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.12.2 3 msec
  2 192.168.23.3 5 msec
  3 192.168.34.4 6 msec

In my case, I’m making it to R4 but If you see it stop somewhere, you’ll know which device to check first.

Check routing:

You can verify routing by checking the routing table or CEF. Check this on all routers in between the source and destination and for both the source and destination:

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "eigrp 1", distance 90, metric 130816, type internal
  Redistributing via eigrp 1
  Last update from 192.168.12.1 on GigabitEthernet0/1, 00:49:46 ago
  Routing Descriptor Blocks:
  * 192.168.12.1, from 192.168.12.1, 00:49:46 ago, via GigabitEthernet0/1
      Route metric is 130816, traffic share count is 1
      Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

R2#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "eigrp 1", distance 90, metric 131072, type internal
  Redistributing via eigrp 1
  Last update from 192.168.23.3 on GigabitEthernet0/2, 00:00:07 ago
  Routing Descriptor Blocks:
  * 192.168.23.3, from 192.168.23.3, 00:00:07 ago, via GigabitEthernet0/2
      Route metric is 131072, traffic share count is 1
      Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Or a CEF check is quicker:

R2#show ip cef 1.1.1.1
1.1.1.1/32
  nexthop 192.168.12.1 GigabitEthernet0/1

R2#show ip cef 4.4.4.4
4.4.4.4/32
  nexthop 192.168.23.3 GigabitEthernet0/2

Check packets:

If your packets are dropped, you’ll need to figure out whether a device forwarded or dropped a packet. On a router, you have multiple options. A very quick way is to check the outgoing packets on an interface:

R2#show interfaces GigabitEthernet 0/2 | include packets output
     331 packets output, 30932 bytes, 0 underruns

That’s OK for a lab where you have a host connected to an interface without any other traffic, but otherwise not specific enough. If you want a detailed look, you could enable a debug or an access-list that permits everything but logs packets. For example, the debug:

R2(config)#access-list 100 permit ip host 1.1.1.1 host 4.4.4.4

R2#debug ip packet 100
IP packet debugging is on for access list 100

And here’s a “COUNTER” access-list:

R2(config)#ip access-list extended COUNTER                    
R2(config-ext-nacl)#permit ip any host 4.4.4.4 log 
R2(config-ext-nacl)#permit ip any any              

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#ip access-group COUNTER out 

If you only enable the debug on a router in between your source and destination (like R2) then you won’t see anything because the router uses CEF. Because of the ACL, you’ll see the debug messages because the router checks these packets.

Otherwise, you’ll have to disable CEF on the interface to see the debug. Do a quick ping from R1 to R4:

R1#ping 4.4.4.4 source 1.1.1.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 7/7/7 ms

Here’s the debug output:

R2#
IP: s=1.1.1.1 (GigabitEthernet0/1), d=4.4.4.4, len 100, input feature
    ICMP type=8, code=0, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 1.1.1.1 dst 4.4.4.4
FIBfwd-proc: packet routed by adj to GigabitEthernet0/2 192.168.23.3
FIBipv4-packet-proc: packet routing succeeded
IP: s=1.1.1.1 (GigabitEthernet0/1), d=4.4.4.4 (GigabitEthernet0/2), len 100, output feature
    ICMP type=8, code=0, Access List(52), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=1.1.1.1 (GigabitEthernet0/1), d=4.4.4.4 (GigabitEthernet0/2), g=192.168.23.3, len 100, forward
    ICMP type=8, code=0
IP: s=1.1.1.1 (GigabitEthernet0/1), d=4.4.4.4 (GigabitEthernet0/2), len 100, sending full packet
    ICMP type=8, code=0

This gives me a detailed output of what is going on with the packet. Here’s the access-list output:

R2#show logging | include COUNTER
*May 14 17:45:36.007: %SEC-6-IPACCESSLOGDP: list COUNTER permitted icmp 1.1.1.1 -> 4.4.4.4 (0/0), 1 packet

In the access-lists I used, I only check the traffic from the source to the destination. You can also add a permit statement for the traffic from 4.4.4.4 > 1.1.1.1 to see the return traffic. These two options help to figure out what a router is doing with your packet.

NAT Debug:

Any “services” like NAT, PBR, QoS, access-lists, etc. can mess up your packets or traffic patterns. You can use a bunch of show commands but a debug gives you an insight what the router is doing. We don’t have NAT right now but let me enable it on R3 for traffic from 1.1.1.1 > 4.4.4.4:

R3(config)#ip access-list extended R1_L0_R4_L0
R3(config-ext-nacl)#permit ip host 1.1.1.1 host 4.4.4.4

R3(config)#int gi0/2
R3(config-if)#ip nat inside

R3(config)#int gi0/3
R3(config-if)#ip nat outside

R3(config)#ip nat inside source list R1_L0_R4_L0 interface gi0/3 overload 

Let’s do a quick ping:

R1#ping 4.4.4.4 source 1.1.1.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 13/13/13 ms

Here’s the NAT table:

R3#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.34.3:18   1.1.1.1:18         4.4.4.4:18         4.4.4.4:18

That’s nice for a small lab but in a production network, you’ll see dozens of translations. You can debug NAT as well:

R3(config)#access-list 1 permit host 4.4.4.4

R3#debug ip nat 1
IP NAT debugging is on for access list 1

Now do another ping:

R1#ping 4.4.4.4 source 1.1.1.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 13/13/13 ms

And you’ll see what R3 does with the packet:

R3#
 mapping pointer available mapping:0
NAT: [0] Allocated Port for 1.1.1.1 -> 192.168.34.3: wanted 21 got 21
NAT*: i: icmp (1.1.1.1, 21) -> (4.4.4.4, 21) [142]
NAT*: s=1.1.1.1->192.168.34.3, d=4.4.4.4 [142]
NAT*: o: icmp (4.4.4.4, 21) -> (192.168.34.3, 21) [142]
NAT*: s=4.4.4.4, d=192.168.34.3->1.1.1.1 [142]

This can be useful when you have many NAT rules. Checking the things above should help with answers to questions like these:

@vishaul

if I am interpreting it correctly, from the remote access user the packet is going to the switch then back to the router.
If that’s the case then the switch is not forwarding the packet to the web server, unless I am mistaking it there.

@vishaul

I am not sure why the remote access user cannot ping 192.168.5.1 - VLAN 5 on the switch. OSPF is configured to advertise that network.

@vishaul

f NAT is affecting the connection, and I remove the NAT entry, then I am thinking I would not be able to access the web server when the VPN is not connected.

I hope this helps!

Rene