Re: Zone-Based Firewall and Tunnel Interface Keepalives

In my case, disabling keepalives at the non-ZBF end was a possible
solution. The keepalives from the ZBF to non-ZBF router worked fine (and
kept the tunnel up even if the far-side was down), but keepalives from the
non-ZBF router to the ZBF router would fail. I mis-typed in the original
email, although I actually disabled it on both sides.

So, this caveat appears to only affect keepalives destined for the ZBF
router.

-Keller
On Oct 31, 2012 1:01 PM, "Carlos G Mendioroz" <tron_at_huapi.ba.ar> wrote:

> I was referring to Keller's initial comment, which stated that turning
> them off at PE1 solved the issue. If it is what you say, it should be
> turning them off at PE2.
>
> -Carlos
>
> Brian McGahan @ 31/10/2012 14:55 -0300 dixit:
>
>> Keepalives are off by default, so as long as you don't enable them it's
>> fine.
>>
>>
>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>> bmcgahan_at_INE.com
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com
>>
>>
>>
>> -----Original Message-----
>> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
>> Sent: Wednesday, October 31, 2012 12:45 PM
>> To: Brian McGahan
>> Cc: Keller Giacomarro; CCIE GroupStudy
>> Subject: Re: Zone-Based Firewall and Tunnel Interface Keepalives
>>
>> Yep, it sounds like this is it.
>> On a minor typo then, for this to work (option 1) you have to disable
>> keepalives on PE2, not PE1, because those are the ones not being replied
>> to, right ?
>>
>> -Carlos
>>
>> Brian McGahan @ 31/10/2012 14:32 -0300 dixit:
>>
>>> It does sound like a bug, or at least an undesired behavior, but based
>>> on the fact that putting the physical interface in the same zone fixes the
>>> problem then that has to be the culprit. Most likely it's just a
>>> programming oversight that they didn't take into account that the tunnel
>>> keepalives return from the physical link and not the tunnel, which causes
>>> them to be blocked by the ZBPF.
>>>
>>> Take a look at "GRE Tunnel Keepalives" at:
>>> http://www.cisco.com/en/US/**tech/tk827/tk369/technologies_**
>>> tech_note0918<http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note0918>
>>> 6a008048cffc.shtml#t5
>>>
>>> Specifically:
>>>
>>> "For GRE keepalives, the sender pre-builds the keepalive response packet
>>> inside the original keepalive request packet so that the remote end only
>>> needs to do standard GRE decapsulation of the outer GRE IP header and then
>>> forward the inner IP GRE packet. This mechanism causes the keepalive
>>> response to forward out the physical interface rather than the tunnel
>>> interface. This means that the GRE keepalive response packet is not
>>> affected by any output features on the tunnel interface, such as 'tunnel
>>> protection ...', QoS, and so forth. )."
>>>
>>> This is what's causing ZBPF to drop it, because the tunnel is in a zone,
>>> while the physical link is not in the zone, so the responses can't come in
>>> on the tunnel and then return on the physical link. It definitely is a
>>> weird behavior though.
>>>
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security) bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
>>> Sent: Wednesday, October 31, 2012 5:13 AM
>>> To: Keller Giacomarro
>>> Cc: Brian McGahan; CCIE GroupStudy
>>> Subject: Re: Zone-Based Firewall and Tunnel Interface Keepalives
>>>
>>> Hmm, it does not make sense to me. It sounds a lot like a bug.
>>>
>>> If ZBF does support tunnel interfaces, it should know that packets that
>>> are related to the tunnel are for the tunnel and not for the physical
>>> interface (it seems it knows that much), and that tunnel supervision is
>>> also part of the tunnel stuff (oops, they forgot).
>>>
>>> Having to explicitly allow them is like to having to explicitly allow
>>> GRE. After all, is not the same thing ?
>>>
>>> -Carlos
>>>
>>>
>>> Keller Giacomarro @ 31/10/2012 02:48 -0300 dixit:
>>>
>>>> Got it. That is kind of what I was thinking, but what you're saying
>>>> makes sense. As far as ZBF is concerned, the keepalives pass through
>>>> the physical interface before reaching the tunnel interface, so we
>>>> have to have some sort of mechanism in place to allow that traffic.
>>>>
>>>> I would say the best option is a separate zone for the physical
>>>> interface, with zone-pairs to allow from physical-zone<->tunnel-zone.
>>>> In my case, I wanted to filter differently on the tunnel versus the
>>>> actual physical interface.
>>>>
>>>> Keller Giacomarro
>>>> keller.g_at_gmail.com
>>>>
>>>>
>>>> On Tue, Oct 30, 2012 at 2:22 PM, Brian McGahan <bmcgahan_at_ine.com>
>>>> wrote:
>>>>
>>>> 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
>>>>>
>>>>> ______________________________**______________________________**
>>>>> ________
>>>>> _ __ Subscription information may be found at:
>>>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>>>
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> ______________________________**______________________________**
>>>> _________
>>>> _ _ Subscription information may be found at:
>>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>
>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 31 2012 - 19:33:31 ART