01-29-2012 02:25 AM - edited 03-11-2019 03:20 PM
I'm having several issues with IPv6 and ZBF. I've narrowed one of them to a very simple setup.
I tried 15.1(4)M in GNS2 and 15.1(4)M3 on a 1812.
The setup is
[PC] ----- [R1] ------ [R2]
R1 and R2 are interconnected by IPv6 only and there is a tunnel over that link to carry IPv4 from R2 to PC.
And I'm trying to ping PC from R2 with IPv4.
We're looking at the R1 config mainly. (the other are included for completeness)
When I try to ping the PC from R2, I get this on R1 console:
%FW-6-DROP_PKT: Dropping icmp session [::]:0 [::]:0 on zone-pair zp_vpn_to_lan class cm_icmp with ip ident 0
Which really doesn't make much sense because zone vpn and zone lan are purely IPv4 and should never see IPv6 traffic as such ...
If I remove all ZBF related config, then traffic flows without problem.
R1 config
class-map type inspect match-all cm_icmp
match protocol icmp
policy-map type inspect pm_icmp
class type inspect cm_icmp
inspect
class class-default
drop
zone security zone_wan
zone security zone_vpn
zone security zone_lan
zone-pair security zp_vpn_to_lan source zone_vpn destination zone_lan
service-policy type inspect pm_icmp
interface FastEthernet1/0
no ip address
zone-member security zone_wan
duplex auto
speed auto
ipv6 address 2001::1/64
ipv6 enable
interface FastEthernet1/1
ip address 10.1.0.1 255.255.255.0
zone-member security zone_lan
duplex auto
speed auto
interface Tunnel0
ip address 172.16.0.1 255.255.255.252
zone-member security zone_vpn
tunnel source FastEthernet1/0
tunnel mode ipv6
tunnel destination 2001::2
ip route 10.2.0.0 255.255.255.0 172.16.0.2
R2 config:
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001::2/64
ipv6 enable
interface FastEthernet1/1
ip address 10.2.0.1 255.255.255.0
duplex auto
speed auto
interface Tunnel0
ip address 172.16.0.2 255.255.255.252
tunnel source FastEthernet1/0
tunnel mode ipv6
tunnel destination 2001::1
ip route 10.1.0.0 255.255.255.0 172.16.0.1
PC config:
ifconfig eth0 10.1.0.2 netmask 255.255.255.0
route add -net default gw 10.1.0.1
Cheers,
Sylvain
01-29-2012 05:05 AM
Some debug for a single icmp echo packet from R2 to PC
R1#show debugging
policy_fw:
Policy-Firewall detailed debugging is on
Policy-Firewall events debugging is on
Policy-Firewall PAK_PATH debugging is on
*Jan 29 05:09:46.006: CCE-FW :cce_dp_named_db_inspect_classify:packet 67747180 is matched
*Jan 29 05:09:46.006: CCE-FW :cce_dp_named_db_inspect_classify:packet 67747180 is matched
*Jan 29 05:09:46.006: FIREWALL: FW CCE got packet 0x67747180 in process path
*Jan 29 05:09:46.006: FIREWALL: FW or IPS Feature object found
*Jan 29 05:09:46.006: FIREWALL: Searching for session in cls 0x69AF3B00 clsgrp 0x20000000, target 0xA0000002, cce clstype 0x2E
*Jan 29 05:09:46.006: FIREWALL: Session not found
*Jan 29 05:09:46.006: FIREWALL: Only FW session init FO found
*Jan 29 05:09:46.006: FIREWALL: Creating fso and attaching forward
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: SIS_CLOSED
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: Pak 0x67747180 IP: s=[::] (Tunnel0), d=[::] (FastEthernet1/1), len 80, proto=icmp
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: dynamic add cls in clsgrp failed for reverse FSO
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: L4 result: DROP packet 0x67747180 ([::]:0) ([::]:0) bytes 80 ErrStr = No Error
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: After Restoring L4 ICMP State: SIS_CLOSED: i_sendcnt 0 r_sendcnt 0
*Jan 29 05:09:46.006: FIREWALL sis 689C0360: L4 inspection ret_val = 1l4_result->fw_dp_insp_err_code = 0session->appl_insp_flags = 0
*Jan 29 05:09:46.010: FIREWALL sis 689C0360: fw_dp_state_object_cleanup: freeing fso. ref_count : 0
*Jan 29 05:09:46.010: FIREWALL sis 689C0360: L4 inspection returned 1
*Jan 29 05:09:46.010: %FW-6-DROP_PKT: Dropping icmp session [::]:0 [::]:0 on zone-pair zp_vpn_to_lan class cm_icmp with ip ident 0
*Jan 29 05:09:46.010: FIREWALL: FW CCE dropping pak 0x67747180 in process path
01-29-2012 11:27 AM
Is nobody using ZBF ?
This seems like a very simple situation and either :
* I'm missing something in my config ... (but if I change the tunnel to be ipv4 over ipv4 it works fine ...)
* There are _serious_ issues in cisco's firewall if it can't deal with simple case like this ...
If I'm wrong somewhere, _please_ point it out ... I just want this thing to work ...
01-29-2012 03:19 PM
Well, as it turns out, not so simple ...
I had a policy applied on the WAN side to only allow the tunnel packet. And this prevented the traffic even tought it shouldn't, but even more interesting is that even when removed, the traffic doesn't resume ... once applied, I have to reload the router for it to ever flow again. (which is why it took me a while to notice ...)
===
class-map type inspect match-all cm_ipv6_encap
match access-group name acl_ipv6_encap
policy-map type inspect pm_wan
class type inspect cm_ipv6_encap
pass
class class-default
drop
zone-pair security zp_self_to_wan source self destination zone_wan
service-policy type inspect pm_wan
zone-pair security zp_wan_self source zone_wan destination self
service-policy type inspect pm_wan
===
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide