Very simple ZBF not working (IPv6)

sylvain.munaut · ‎01-29-2012

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

sylvain.munaut · ‎01-29-2012

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

sylvain.munaut · ‎01-29-2012

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

sylvain.munaut · ‎01-29-2012

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

===