Re: Zone-Based Firewall and Tunnel Interface Keepalives

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
>> 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
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _____________________________________________________________________
>>> _ _ Subscription information may be found at:
>>> 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