We need to consider image used in the CCIE lab.

With regards
Kings

On Tue, Jul 3, 2012 at 8:32 PM, Ben Shaw <[email protected]> wrote:

> I'm using 8.0(4)23
>
> ASA1/c1# show version
>
> Cisco Adaptive Security Appliance Software Version 8.0(4)23 <context>
> Device Manager Version 6.1(5)51
>
> I'm not using 8.0(3) but if that error appears on that version I would
> expect it would appear in 8.0(4) also considering it is later version.
>
>
>
>
> On Wed, Jul 4, 2012 at 12:58 AM, Kingsley Charles <
> [email protected]> wrote:
>
>> What image are you using?
>>
>> Use 8.0.3 and you will see that it will not be allowed to be configured
>> in the first place. The following error will be thrown.
>>
>> asa1(config)# static (inside,outside) 20.10.30.40 access-list tel
>> ERROR: Protocol mismatch between the static and access-list
>>
>>
>> With regards
>> Kings
>>
>>
>> On Tue, Jul 3, 2012 at 7:20 PM, Ben Shaw <[email protected]> wrote:
>>
>>> Hi Guys,
>>>
>>> I'm a bit confused as it seems to me you are agreeing with each other
>>> but yet saying different things. Kings says matching on protocol can't be
>>> done with static policy NAT and Bruno seems to say it can.
>>>
>>> I now with some other forms of policy NAT if I try and use an ACL with
>>> ports defined I get an error message that a port based ACL can't be used. I
>>> don't get that error when I use an ACL with ports with static NAT and when
>>> I check the NAT configuration between interfaces as shown below the
>>> particular configuration seems to be applied just as I want it to be
>>>
>>> ASA1/c1(config)# access-list acl1 extended permit tcp host 10.1.1.1 host
>>> 10.4.4.4 eq telnet
>>> ASA1/c1(config)# static (inside,outside) 192.168.6.61  access-list acl1
>>>
>>> ASA1/c1# show nat inside outside
>>>
>>>   match tcp inside host 10.1.1.1 outside host 10.4.4.4 eq 23
>>>     static translation to 192.168.6.61/50961
>>>
>>>     translate_hits = 0, untranslate_hits = 0
>>>
>>> So according to the output above the command did 'take' and traffic from
>>> 10.1.1.1 to 10.4.4.4:23 is being SNAT'd to 192.168.6.61. Now I'll agree
>>> that I did not see the firewall operating in this way and the NAT operation
>>> did not seem to actually work but why would it 1) accept my static command
>>> with a port based ACL if it couldn't (especially when in other NAT
>>> statements it will return an error) and 2) show entries in the "show nat
>>> inside outside" command that seem to confirm that it will translate the
>>> traffic I want it to?
>>>
>>> Thanks
>>> Ben
>>>
>>>
>>>
>>> On Mon, Jul 2, 2012 at 9:31 PM, Bruno Silva <[email protected]>wrote:
>>>
>>>> What Kings is saying is correct, you can only use an access-list
>>>> matching TCP when you are going to match the protocol on the static
>>>> translation.
>>>>
>>>>
>>>> 2012/7/2 Kingsley Charles <[email protected]>
>>>>
>>>>> The following is incorrect. With static policy rule, you can't use
>>>>> destination port numbers. You can do it only with policy nat (nat/global
>>>>> commands)
>>>>>
>>>>>
>>>>> access-list acl1 extended permit tcp host 10.1.1.1 host 10.4.4.4 eq
>>>>> telnet
>>>>> static (inside,outside) 192.168.6.61 acl1
>>>>>
>>>>>
>>>>> With regards
>>>>> Kings
>>>>>
>>>>> On Mon, Jul 2, 2012 at 2:28 PM, Ben Shaw <[email protected]> wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> one of the requirements in Yusuf's second Lab is to source NAT the
>>>>>> address 10.1.1.1 to 192.168.6.61 for telnet connections to 10.4.4.4. To 
>>>>>> do
>>>>>> so I configured the following
>>>>>>
>>>>>> access-list acl1 extended permit tcp host 10.1.1.1 host 10.4.4.4 eq
>>>>>> telnet
>>>>>> static (inside,outside) 192.168.6.61 acl1
>>>>>>
>>>>>> However this did not translate the source address and the connection
>>>>>> was allowed to pass to 10.4.4.4 using the untranslated source address of
>>>>>> 10.4.4.4. I performed a packet tracer and got the following output:
>>>>>>
>>>>>>
>>>>>> ASA1/c1# packet-tracer input inside tcp 10.1.1.1 50000 10.4.4.4 telnet
>>>>>> <snip>
>>>>>> Phase: 9
>>>>>> Type: NAT
>>>>>> Subtype: host-limits
>>>>>> Result: ALLOW
>>>>>> Config:
>>>>>> static (inside,outside) 192.168.6.61  access-list acl1
>>>>>>   match tcp inside host 10.1.1.1 outside host 10.4.4.4 eq 23
>>>>>>     static translation to 192.168.6.61/33135
>>>>>>     translate_hits = 0, untranslate_hits = 0
>>>>>> Additional Information:
>>>>>> <snip>
>>>>>> Result:
>>>>>> input-interface: inside
>>>>>> input-status: up
>>>>>> input-line-status: up
>>>>>> output-interface: outside
>>>>>> output-status: up
>>>>>> output-line-status: up
>>>>>> Action: allow
>>>>>> ASA1/c1#
>>>>>>
>>>>>>
>>>>>> From this output it looks as though the  translation will work as
>>>>>> desired but when I try actually perform the connection I get the 
>>>>>> following:
>>>>>>
>>>>>>
>>>>>> R1#show ip interface brief | i Loopback0
>>>>>> Loopback0                  10.1.1.1        YES NVRAM
>>>>>> up                    up
>>>>>> R1#telnet 10.4.4.4 /source-interface loopback 0
>>>>>> Trying 10.4.4.4 ... Open
>>>>>> User Access Verification
>>>>>> Password:
>>>>>> R4>who
>>>>>>     Line       User       Host(s)              Idle       Location
>>>>>>    0 con 0                idle                 01:17:56
>>>>>> * 98 vty 0                idle                 00:00:00 10.1.1.1
>>>>>>   Interface    User               Mode         Idle     Peer Address
>>>>>> R4>
>>>>>>
>>>>>>
>>>>>> However, when I change the ACL and match just the IP address like this
>>>>>>
>>>>>>
>>>>>> access-list acl2 extended permit ip host 10.1.1.1 host 10.4.4.4 log
>>>>>> static (inside,outside) 192.168.6.61  access-list acl2
>>>>>>
>>>>>>
>>>>>> everything seems to work fine as show below:
>>>>>>
>>>>>>
>>>>>> R1#telnet 10.4.4.4 /source-interface loopback 0
>>>>>> Trying 10.4.4.4 ... Open
>>>>>> User Access Verification
>>>>>> Password:
>>>>>> R4>who
>>>>>>     Line       User       Host(s)              Idle       Location
>>>>>>    0 con 0                idle                 01:21:44
>>>>>> * 98 vty 0                idle                 00:00:00 192.168.6.61
>>>>>>   Interface    User               Mode         Idle     Peer Address
>>>>>> R4>
>>>>>>
>>>>>>
>>>>>> I was quite certain that policy NAT allows NAT decisions to be based
>>>>>> on both IP addresses and ports but the use of ports seems to be causing
>>>>>> issues here. Can any enlighten me as to why this isn't working with TCP
>>>>>> ports defined in the ACL?
>>>>>>
>>>>>> Thanks
>>>>>> Ben
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bruno Silva
>>>> Network Consultant
>>>> Cisco CCNA/CCDA/CCNP/CCDP/CCSP Certified
>>>> Arcsight Professional Certified - ACIA/ACSA
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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