Re: Cisco IOS Zone Based Firewall and IPv6

mocah · ‎10-04-2010

Hello,

I am trying to setup IPv6 tunnel to tunnel-broker Hurrican Electrics. IPv6 connection is working OK only if I disable zone security on WAN interface (Fe0 - IPv4 interface).

Which protocols must be alloved to and from router?

IOS version: 15.1.2T1 (Adv.ip services)

Setup:

HE (tunnel-broker) --- Internet (IPv4) ---- Cisco 1812 (Fe0 (IPv4) and interface tunnel 1 (IPv6))

Config on router:

*************************************************************************************************************

IPv4 (self to internet and internet to self)

policy-map type inspect Outside2Router-pmap
class type inspect SSHaccess-cmap
inspect
class type inspect ICMP-cmap
inspect
class type inspect IPSEC-cmap
pass
class type inspect Protocol41-cmap
pass log
class class-default
drop

**************************************************************************************************************

interface Tunnel1
description Hurricane Electric IPv6 Tunnel Broker
no ip address
zone-member security IPv6tunnel
ipv6 address 2001:47:25:105B::2/64
ipv6 enable
ipv6 mtu 1300
tunnel source FastEthernet0
tunnel mode ipv6ip
tunnel destination xxx.66.80.98

interface FastEthernet0
description WAN interface
ip address xxx.xxx.252.84 255.255.0.0
no ip redirects
no ip unreachables
no ip proxy-arp
zone-member security WAN
duplex auto
speed auto

zone-pair security IPv6Tunnel_2_WAN source IPv6tunnel destination WAN
service-policy type inspect IPv6-out-pmap
zone-pair security WAN_2_IPv6tunnel source WAN destination IPv6tunnel
service-policy type inspect IPv6-out-pmap

policy-map type inspect IPv6-out-pmap
class type inspect IPv6-internet-class
inspect
class class-default
drop

class-map type inspect match-all IPv6-internet-class
match protocol tcp
match protocol udp
match protocol icmp
match protocol ftp

ipv6 route ::/0 Tunnel1

ipv6 unicast-routing
ipv6 cef

parameter-map type inspect v6-param-map
ipv6 routing-header-enforcement loose
sessions maximum 10000
!

*************************************************************************************************************

praprama · ‎10-04-2010

Hi,

Just want to clarify a thing. Is the tunnel not coming up in the first place or is the tunnel up and you are unable to pass traffic?

Please paste the entire zone based firewall output (zones with member interfaces, zone-pairs, policy-maps and class-maps) for us to analyze.

Thanks and Regards,

Prapanch

mattkjohnson · ‎10-04-2010

Small world,

I was just about to post a forum thread with exactly the same question.

Creating a tunnel (type ipv6ip) to HE's tunnelbroker.net service.

ZBF between WAN and LAN interfaces for existing IPv4 traffic already setup.

As I understand it, IPv6 traffic will be ignored by ZBF and indeed I do see this behaviour, as I can ping the LOCAL tunnel endpoint IPv6 IP from a host on my LAN with an IPv6 address.

However, I cannot get IPv6 traffic any further (ie, up the tunnel) unless I remove the WAN interface from the ZBF configuration.

I have tried the following to get around this but to no avail:

- policy map to 'pass' IP ANY ANY to the dest of the tunnel brokers IPv4 address on a SELF to WAN zone pair

- policy map to 'pass' IP ANY ANY from the dest of the tunnel brokers IPv4 address on a WAN to SELF zone pair

- both of the policy maps above at the same time

- both of the policy maps above with inspect actions instead of pass

- both of the policy maps above but with IP proto 41 any any instead of IP any any with the IP of the remote tunnel endpoint (as proto 41 is ipv6ip)

But NONE of these work, if I ping6 ipv6.google.com I get no replies, as soon as I do a 'no zone-member security ZBF-WAN' on the WAN interface, the pings are fine.

The only other thing I could think of is where within the black box of cisco IOS does IOS actually 'create' the tunnel traffic, ie, is it from SELF zone or is it from the tunnel interface itself?

To test this I added the tunnel interface to the WAN ZBF zone (as interfaces in the same zone should be able to communicate) but this did not help either.

Have spent two days on this and am fully stumped!

Also, there don't seem to be any decent ZBF debug commands that show you each dropped packet and why they were dropped (ie which pmap/inspect class map caused the drop) if you know any please let me know

Thanks in advance,

//TrX

mattkjohnson · ‎10-04-2010

Adding full IOS config for clarity (attached). This config is not in production use so can test changes if needbe.

praprama · ‎10-04-2010

Hi,

To have the IOS produce logs when znoe based firewall drops the packet, please enable "ip inspect log drop-pkt". Then you should see logs with the details you have mentioned.

Thanks and Regards,

Prapanch

mattkjohnson · ‎10-04-2010

Thanks,

That makes sense as ZBF is still using the underlying ip inspect.

Anyway, on ping6 ipv6.google.com I get the following single line of drop log:

*Oct 5 02:21:24.740 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session :0 216.66.80.26:0 on zone-pair selftowan class cm-selftowan due to Invalid Segment with ip ident 0

Unknown L4 session, suggests my outbound Self to WAN zone does not have a classmap matching the outbound traffic type.

Also, doing a quick google (found one of your other forum posts in the result actually) suggests 'Invalid Segment with ip ident 0' issues on ZBF could be caused by a class-map matching an access-list with more than one entry.

However, as you can see from my config, the only entry I have in cm-selftowan is a 'permit ip any any' ACL.

The traffic does not seem to be getting past this cmap though and onto the specially defined cmap below it which permit's the HE.net tunnel dest address (this logic coming from the fact that 'class cm-selftowan' is listed in the drop log above)

I will try removing this cmap and just leaving the cm-selftowan-he-out cmap in place (so we know the ZBF is looking at that cmap first).

However, can you think of a reason why 'permit ip any any' wlould not be working :S? Due to this I don't have much hope that what I am about to try will work.

Back with updates soon.

mattkjohnson · ‎10-04-2010

OK, removed the cmap the packet was getting dropped on, so the current self to wan zone-pair policy map looks like this:

policy-map type inspect pm-selftowan
class type inspect cm-selftowan-he-out
inspect
class type inspect cm-dhcpwan
pass
class class-default
drop
!

class-map type inspect match-all cm-selftowan-he-out
match access-group name HETunnelOutbound

ip access-list extended HETunnelOutbound
permit 41 any any
permit ip any host 64.62.200.2
permit ip any host 66.220.2.74
permit ip any host 216.66.80.26

Now we see the same error, just on the 'new' first cmap in the pmap:

*Oct 5 02:39:31.316 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session :0 216.66.80.26:0 on zone-pair selftowan class cm-selftowan-he-out due to Invalid Segment with ip ident 0

Yet as you can see above, we are allowing proto 41 any any.

I didn't expect any other result really since the previous cmap had 'permit ip any any' but still

any ideas?

Thanks,

//TrX

EDIT: Out of curiosity after reading this post: https://supportforums.cisco.com/thread/2043222?decorator=print&displayFullThread=true

I decided to change the outbound cm-selftowan-he-out action to 'pass'.

I suddently noticed the following log:

*Oct 5 02:39:31.316 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session 216.66.80.26:0 :0 on zone-pair wantoself class cm-wantoself-he-in due to Invalid Segment with ip ident 0

Notice this is now inbound having trouble where as before was outbound.

I changed the inbound pmap policy for cmap cm-wantoself-he-in to pass also and IPv6 PACKETS ARE GETTING ICMP6 REPLIES FROM GOOGLE!

Looking at the original outbound PMAP:

policy-map type inspect pm-selftowan
class type inspect cm-selftowan
inspect
class type inspect cm-selftowan-he-out
inspect
class type inspect cm-dhcpwan
pass
class class-default
drop

cm-selftowan has always been infront of cm-selftowan-he-out, and because that is ip any any, it has been 'grabbing' the IP proto 41 packets and doing ip inspect on them (which fails as it seems ip inspect only handles a handful of proto's).

This is why setting cm-selftowan-he-out and cm-wantoself-he-in both to 'pass' instead of 'inspect' in the past has not been doing anything, because the outbound packets were never getting to the cm-selftowan-he-out cmap.

Would never have got to this without ip inspect log. Why didn't I think of just trying ip inspect logging two days ago!

Anyway, thank you, I have now restored my faith in my own knowledge of ZBF!

Hope this helps the OP too

//TrX

mocah · ‎10-06-2010

Hello Matt,

You are correct if I move "class type inspect Protocol41-cmap" to top position in policy-map type inspect Outside2Router-pmap, than icmp is working

policy-map type inspect Outside2Router-pmap
 class type inspect Protocol41-cmap
  pass log

 class type inspect SSHaccess-cmap
  inspect 
 class type inspect ICMP-cmap
  inspect 
 class type inspect IPSEC-cmap
  pass

 class class-default
  drop

I was always thinking that router checks all class maps (from highest class type to lowest) in policy-map, until it finds proper rule or reject packet if it can not find the matching rule.

mocah · ‎10-05-2010

Hello,

tunnel is up/up. I have attached config and debug messages in attachment.

sh interfaces tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Description: Hurricane Electric IPv6 Tunnel Broker
MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 89.212.252.184 (FastEthernet0), destination 216.66.80.98
   Tunnel Subblocks:
      src-track:
         Tunnel1 source tracking subblock associated with FastEthernet0
          Set of tunnels with source FastEthernet0, 2 members (includes iterators), on interface
Tunnel protocol/transport IPv6/IP
Tunnel TTL 255
Tunnel transport MTU 1480 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:34:39, output 00:05:36, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     1132 packets input, 160980 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1141 packets output, 95996 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
C1812#ping ipv6.google.com
Translating "ipv6.google.com"...domain server (192.168.10.10) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A00:1450:8004::69, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
C1812#

CiscoNut2b · ‎08-15-2011

Mocah,

I've been trying to get my tunnel up with HE.net for quite some time, but without luck. Have you made any progress in getting your ZBFW working with HE's TunnelBroker?

barmason · ‎11-05-2013

Ran into the same issue playing with HE tunnelbroker; the fix for me was simple; apply the same security zone to the tunnel interface as you do to the outside physical WAN interface.

For mine applying 'zone-member security OUTSIDE' (which is what i have on my fa4 physical) solved the problem and makes sense as the traffic is inspected as it flows between that interface pair for v6 traffic.

HTH.