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 <[email protected]> > 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/
