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

Tue May 21 20:40:37 EDT 2013

Correct. Netflow will only show the encrypted data flow on the interface that the encrypted traffic is passing through. The packet has to traverse the interface to reach the crypto engine.

You could apply the same to the interface on the LAN side, hoping something actually exits. That's why I thought the debug was more useful. I think it would capture data in more situations... and it could be expanded beyond just ICMP to look at everything in more detail if something very odd were happening.

On May 21, 2013, at 6:41 PM, Martin T <m4rtntns at gmail.com> wrote:

> But still, how is the packet flow in case of IPsec? Based on the NetFlow data it's:
> 
> wire -> WAN-interface -> crypto engine -> WAN-interface -> ASIC/CPU
> 
> 
> regards,
> Martin
> 
> 2013/5/21 Martin T <m4rtntns at gmail.com>
>> 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/
>> >>
>> >
> 