Let us know. I've too much going on to lab it up this week. Having to catch up 
from being out from labbing last week.

Regards,
Jay McMickle CCIEx2 #35355 (R/S,Sec)
Sent from my iPhone

On May 1, 2013, at 11:44 PM, Mike Rojas <[email protected]> wrote:

> Hi Jason,
> 
> 
> Pretty much the same thing. What is killing it is the NAT...im pretty sure 
> that is going to work as soon as i configure the double NAT
> 
> Sent from my iPhone
> 
> On May 1, 2013, at 10:37 PM, "Jay McMickle" <[email protected]> wrote:
> 
>> I've never ran across this, but interesting in fact.
>>  
>> What I remember (from a non-nat situation), and what you didn't put below, 
>> is the class-map. What does your class-map have in it?  The service-policy 
>> looks like you are calling an ACL.
>>  
>> What if you were to get less restrictive with your ACL, and remove the 
>> possibility of an ASA 8.4+ NAT issue, and use a different class map?  This 
>> would remove the host restriction and just check on the BGP port.
>>  
>> class-map BGP
>>  match port tcp eq bgp
>>  
>> The rest is the same.
>>  
>> Let us hear back.
>>  
>>  
>> Regards,
>> Jay McMickle- 2x CCIE #35355 (R&S,Sec)
>>  
>> 
>> From: Mike Rojas <[email protected]>
>> To: Jason Madsen <[email protected]> 
>> Cc: "[email protected]" <[email protected]> 
>> Sent: Wednesday, May 1, 2013 11:05 PM
>> Subject: Re: [OSL | CCIE_Security] ASA BGP Auth Passing through
>> 
>> That's the issue. I remember i had to put a Nat0 on the old v3 lab.. Ill 
>> configure a manual NAT tomorrow on my lab and test out. Pretty much I think 
>> thats the issue.
>> 
>> Sent from my iPhone
>> 
>> On May 1, 2013, at 9:31 PM, "Jason Madsen" <[email protected]> wrote:
>> 
>>> Hi Mike,
>>> 
>>> I don't believe you can use NAT here as the BGP source address is built 
>>> into the MD5 hash. 
>>> 
>>> 
>>> Jason
>>> 
>>> 
>>> On Wed, May 1, 2013 at 9:07 PM, Mike Rojas <[email protected]> wrote:
>>> Hi, 
>>> 
>>> I am having troubles with BGP passing through with authentication. I 
>>> configured the routers as follow (Since the Initial configs are not ready, 
>>> but based on the exercise you kind of know where it is going :)) 
>>> 
>>> R1 
>>> router bgp 14
>>>  no synchronization
>>>  bgp log-neighbor-changes
>>>  network 11.11.11.0
>>>  neighbor 200.100.34.254 remote-as 14
>>>  neighbor 200.100.34.254 password cisco
>>>  no auto-summary
>>> 
>>> R4
>>> router bgp 14
>>>  no synchronization
>>>  bgp log-neighbor-changes
>>>  network 4.4.4.4
>>>  neighbor 200.100.34.1 remote-as 14
>>>  neighbor 200.100.34.1 password cisco
>>>  no auto-summary
>>> 
>>> Now, in order to allow this across the ASA, I configured the following: 
>>> 
>>> access-list BGP extended permit tcp any host 192.168.103.1 eq bgp
>>> access-list BGP extended permit tcp host 192.168.103.1 any eq bgp
>>> 
>>> tcp-map BGP
>>>   tcp-options range 19 19 allow
>>> 
>>> policy-map global_policy
>>>     class BGP
>>>        set connection random-sequence-number disable
>>>           set connection advanced-options BGP
>>> 
>>> If I do the show service-policy flow: 
>>> 
>>> ASA003(config)# sh service-policy flow tcp host 200.100.34.254 host 
>>> 192.168.103.1 eq 179
>>> 
>>> Global policy:
>>>   Service-policy: global_policy
>>>     Class-map: BGP
>>>       Match: access-list BGP
>>>         Access rule: permit tcp any host 192.168.103.1 eq bgp
>>>       Action:
>>>         Input flow:  set connection random-sequence-number disable
>>>   set connection advanced-options BGP
>>>     Class-map: class-default
>>>       Match: any
>>>       Action:
>>>         Output flow:
>>> Interface outside:
>>>   Service-policy: outside
>>>     Class-map: IPS
>>>       Match: access-list IPS
>>>         Access rule: permit ip any any
>>>       Action:
>>>         Input flow:  ips inline fail-open
>>>     Class-map: class-default
>>>       Match: any
>>>       Action:
>>> 
>>> Here is the NAT: 
>>> 
>>> NAT from inside:192.168.103.1 to outside:200.100.34.1
>>>     flags s idle 0:00:23 timeout 0:00:00
>>> 
>>> However, the connection always stays like this: 
>>> 
>>> TCP outside  200.100.34.254:52812 inside  192.168.103.1:179, idle 0:00:00, 
>>> bytes 0, flags SaAB
>>> 
>>> I took captures on the ASA and I am able to see that the Option 19 is 
>>> passing correctly, but on the Router 1 I only see: 
>>> *May  2 02:04:16.383: %TCP-6-BADAUTH: Invalid MD5 digest from 
>>> 200.100.34.254(55025) to 192.168.103.1(179)
>>> 
>>> If I remove authentication, the Adjacency comes up instantly. I reloaded 
>>> the routers just in case. No go. 
>>> 
>>> Any help would be appreciated. 
>>> 
>>> Mike. 
>>> 
>>> 
>>> _______________________________________________
>>> For more information regarding industry leading CCIE Lab training, please 
>>> visit http://www.ipexpert.com/
>>> 
>>> Are you a CCNP or CCIE and looking for a job? Check out 
>>> http://www.platinumplacement.com/
>> 
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please 
>> visit www.ipexpert.com
>> 
>> Are you a CCNP or CCIE and looking for a job? Check out 
>> www.PlatinumPlacement.com
>> 
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to