[c-nsp] ICMP "echo reply" packages received over IPsec tunnel don't reach IOS ping utility

Tue May 21 08:18:10 EDT 2013

Err..I had VLAN associated with a physical interface which was down so
192.168.157.1 was not in the routing table, but as 192.168.157.1/24
was associated with an VLAN-interface, I was allowed to use the
192.168.157.1 as a source IP in "ping 192.168.136.2 source
192.168.157.1 repeat 4" command. In a nutshell, as 192.168.157.0/24
was not in the routing table, ICMP packets with src IP 192.168.136.2
and dst IP 192.168.157.1 were dropped by the Cisco router.

regards,
Martin

2013/5/21, Martin T <m4rtntns at gmail.com>:
> Thanks for the replies!
>
> <<Enable ip flow ingres and ip flow egres on the c1841 to see the
> pakets with s hip cache <<flow (you need globally ip cef, of course),
> esp. src and dst ip addresses.
>
> I enabled inbound and outbound NetFlow on WAN interface on Cisco
> router with "ip flow ingress" and "ip flow egress" commands under
> Fa0/0 interface configuration. If I execute "ping 192.168.136.2 source
> 192.168.157.1 repeat 4" then I will see 4 packets from ZyXEL router
> with IP protocol number 50(0x32, ESP), src port 46260 and destination
> port 2964 in "sh ip cache Fa0/0 flow" output. In addition, there will
> be 4 ICMP packets from 192.168.136.2:
>
> SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP
> Pkts
> Fa0/0         192.168.136.2   Fa0/0*        192.168.157.1   01 0000 0000
> 4
>
> I guess that asterisk after the interface name(Fa0/0*) means that it's
> outbound direction? This should indicate that encrypted ESP packet is
> received by Fa0/0 from wire, successfully processed by crypto engine
> and finally an ICMP packet is sent out to CPU for further processing
> from Fa0/0?
>
>
> <<Something else to try as well: Create an access-list to define the
> traffic patterns you are
> <<looking to validate. Then use debug ip packet referencing that
> access-list to watch the <<packets in real time. If you make the
> access-list broad enough to capture all ICMP types <<for the
> source/destination, you could validate what you're receiving back in
> response to <<the ICMP echo request.
>
> Isn't that the same as "debug ip icmp"? AFAIK "debug ip icmp" debugs
> all ICMP types. When I enable debugging with "debug ip icmp" and
> execute "ping 192.168.136.2 source 192.168.157.1 repeat 4" I do not
> see any packages logged to terminal:
>
> r1#show debugging
> Generic IP:
>   ICMP packet debugging is on
>
> r1#ping 192.168.136.2 source 192.168.157.1 repeat 4
>
> Type escape sequence to abort.
> Sending 4, 100-byte ICMP Echos to 192.168.136.2, timeout is 2 seconds:
> Packet sent with a source address of 192.168.157.1
> ....
> Success rate is 0 percent (0/4)
> r1#
> r1#
>
> ..while if I execute "ping 8.8.8.8" I do see ICMP messages logged to
> terminal. Same is true if I send for example ICMP timestamp(type 13)
> or ICMP Host administratively prohibited(type 3 code 10) messages to
> Cisco router.
>
>
> regards,
> Martin
>
> 2013/5/21, Vinny Abello <vinny at abellohome.net>:
>> On , cnsp at marenda.net wrote:
>>>> Hi,
>>>>
>>>> I have an IPsec tunnel between Cisco 1841 and ZyXEL routers over
>>>> public
>>>> Internet. I do not have access to ZyXEL router. According to "show
>>>> crypto session" IPsec tunnel is up and active. This IPsec tunnel
>>>> connects 192.168.157.0/24 and 192.168.136.0/24 networks over the
>>>> Internet. Now if I send an ICMP "echo request" message from Cisco
>>>> router to ZyXEL router, I will not receive an ICMP "echo reply":
>>>>
>>>> r1#ping 192.168.136.2 source 192.168.157.1 repeat 1
>>>>
>>>> Type escape sequence to abort.
>>>> Sending 1, 100-byte ICMP Echos to 192.168.136.2, timeout is 2
>>>> seconds:
>>>> Packet sent with a source address of 192.168.157.1 .
>>>> Success rate is 0 percent (0/1)
>>>> r1#
>>>>
>>>> ..but for some reason "packets in" and "packets out" counters in "sh
>>>> crypto engine accelerator statistic" output are incremented by two.
>>>> This should indicate that router received the ICMP "echo reply" and
>>>> it
>>>> was processed by onboard VPN module. If I ping an IP address in
>>>> 192.168.136.0/24 network, which is not configured(for example
>>>> 192.168.136.123), then "packets in" and "packets out" counters in "sh
>>>> crypto engine accelerator statistic" are incremented by one. In
>>>> addition, if I configure an ACL to WAN interface on Cisco router, I
>>>> can
>>>> see ingress ESP packets from this particular ZyXEL router. As I said,
>>>> its on Cisco 1841 router and I'm using onboard hardware VPN module.
>>>> IOS
>>>> image is c1841-advsecurityk9-mz.124-24.T6.bin. I checked the open
>>>> caveats and bugs for this particular IOS, but did not find anything.
>>>>
>>>> Any ideas what might cause such behavior? Or am I doing something
>>>> wrong?
>>>
>>> Enable ip flow ingres and ip flow egres on the c1841 to see
>>> the pakets with s hip cache flow (you need globally ip cef, of
>>> course),
>>> esp. src and dst ip addresses.
>>>
>>> Perhaps the zyxel NATtes the paket to the remote router,
>>> Or sends an icmp admin. Prohibited back thru the vpn tunnel ?
>>
>> Something else to try as well: Create an access-list to define the
>> traffic patterns you are looking to validate. Then use debug ip packet
>> referencing that access-list to watch the packets in real time. If you
>> make the access-list broad enough to capture all ICMP types for the
>> source/destination, you could validate what you're receiving back in
>> response to the ICMP echo request.
>>
>>> BTW, you could not ping a PIX'es LAN Interface thru vpn-tunnel,
>>> While it works fine between two cisco routers.
>>
>> You can if you use the "management-access <ifname>" command. This is
>> very handy for monitoring purposes. This also allows management of the
>> device through a VPN tunnel if permitted. In addition, this allows you
>> to source a packet from that firewall interface to trigger a tunnel to
>> come up if it's part of the encryption domain. I've even seen it used
>> creatively to bring dynamic tunnels up by configuring an NTP server
>> across a tunnel. :) Not that any of this has anything to do with the
>> ZyXEL of course...
>>
>> -Vinny
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>