Ben, 

You actually can do it with a port, however as you rightly mentioned it would 
be for the source port. Static PAT is always for source port translations so 
something like the following scenario should work fine. 

Real Address 10.10.10.10
Translated Address 20.20.20.20 
Port to be used 23 

access-list pnat1 permit tcp host 10.10.10.10 eq 23 any 
static (inside,outside) tcp 20.20.20.20 23 access-list pnat1 

That would allow anyone to access server 10.10.10.10 with port 23 using address 
20.20.20.20 

Let me know if you have doubts. 

Mike 

Date: Wed, 4 Jul 2012 01:02:17 +1000
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [OSL | CCIE_Security] Static Policy NAT with L4 ACL

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                                         
_______________________________________________
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