RE: Zone-Based Firewall and Tunnel Interface Keepalives

Interfaces that are not in a zone cannot talk to interfaces that are in a zone. Basically your physical link is not participating in ZBPF, while your tunnel interface is. I haven't seen this specific problem before, but I would speculate that there's a problem with the classifier's order of operations for the tunnel and ZBPF. The tunnel keepalive comes in the physical interface which is not part of a zone, which means that it cannot forward to the logical tunnel internal, which causes the tunnel to drop. If the ZBPF classifier happened after the GRE keepalive internal switching then this problem wouldn't happen.

By putting the physical link in the same zone as the tunnel, traffic is not inspected between them. In other words traffic between two interfaces in the same zone can forward without needing additional rules. Disabling the keepalives works because that just avoids the problem to begin with, and then creating specific inspection rules has basically the same effect as having the tunnel and the physical link in the same zone.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com
 
Internetwork Expert, Inc.
http://www.INE.com

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Keller Giacomarro
Sent: Saturday, October 27, 2012 3:05 AM
To: CCIE GroupStudy; CCIE IPExpert OSL
Subject: Zone-Based Firewall and Tunnel Interface Keepalives

I ran into something in a practice lab that has me scratching my head. The
situation was like this...

CE1 ----- PE1 ---- <ipv4 cloud> ---- PE2 ----- CE2

PE1 and PE2 are running MPLS via a GRE tunnel across the IPv4 cloud. They
are exchanging customer routes between CE1 and CE2 via MP-BGP.

The task was to create a ZBF on PE1 that blocked some things and allowed
others. Seemed simple enough. I did my class-maps, policy-maps, zones,
and zone-pairs as normal. The trouble came when I applied my ZBF to the
interfaces.

PE1:
interface tunnel 0
! mpls GRE tunnel to PE2
keepalive 10 3
zone-member sec vpn
!
interface s0/0
! serial link to CE1
zone-member sec outside

PE2:
interface tunnel 0
keeaplive 10 3

Everything worked fine...for 30 seconds or so. PE2 drops its tunnel. A
'debug tunnel keepalive' shows that PE2 is not getting responses to its
keepalives. PE1's keepalives are normal, and the tunnel stays up even
though the other side is down.
From PE2, I can ping the physical interface on PE1 fine. It's just the
keepalives that are dropping.

The fix is to do one of three things...
PE1:
interface tun 0
no keepalive
! tunnel stays up and traffic passes correctly both over the tunnel and to
the underlying physical interface

OR

PE1:
interface f0/0
! ipv4 cloud interface
zone-member sec vpn
! adds the underlying tunnel physical interface to the same zone, possibly
having other side-effects

OR

PE1:
zone sec physical
!
zone-pair sec vpn-to-physical source vpn destination physical
service-policy type inspect pm-permit-any
zone-pair sec physical-to-vpn source physical destination vpn
service-policy type inspect pm-permit any
!
interface f0/0
zone-member sec physical
! create a new zone for the physical interface and allow traffic to pass
between it and the vpn zone on the tunnel

My question is...WHY? Why does the physical interface for the tunnel need
to be in the same ZBF zone or one that is allowed to communicate with the
tunnel's zone? And why does it only affect keepalives? I can ping the
interfaces fine, it's only keepalives that drop.

Without the pinging caveat, I would think we need to think of the
interfaces like this...

Router (Self Zone) ----- Tunnel (VPN Zone) ---- Interface (Physical Zone)
---- <outside>

Requiring us to allow the traffic to pass through each of these zones as it
enters/exits the router. But the ping things messes me up! Any insight as
to how this really works would be appreciated!

Keller Giacomarro
keller.g_at_gmail.com

Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 30 2012 - 14:22:09 ART