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 <[email protected]>: > 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 <[email protected]>: >> On , [email protected] 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 [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
