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/
