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

Tue May 21 18:41:37 EDT 2013

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/
> >>
> >
>