cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
433
Views
0
Helpful
3
Replies

PAT Help!

jodilovell
Level 1
Level 1

Hi all,

Apologies if this is a newbie question...

We have a range of IP's on a LAN that need to be NAT'd on a PIX 506E (Version 6.3(3)) for Internet access. The issue is that most users will be NAT'd to one IP in order to use our WebSense server but two IP's need to be NAT'd to another IP in order to bypass WebSense.

This is what we have set up:

global (outside) 1 165.x.x.41

global (outside) 2 165.x.x.43

nat (inside) 1 access-list inout-nat 0 0

nat (inside) 2 access-list websense-bypass 0 0

access-list inout-nat deny udp any any eq 1398

access-list inout-nat deny udp any eq 1398 any

access-list inout-nat deny udp any any eq snmp

access-list inout-nat deny udp any any eq snmptrap

access-list inout-nat deny tcp any any eq 135

access-list inout-nat deny tcp any any eq 445

access-list inout-nat deny udp any any eq netbios-ns

access-list inout-nat deny ip host 10.x.x.200 any

access-list inout-nat deny ip host 10.x.x.201 any

access-list inout-nat permit ip 10.x.x.0 255.255.254.0 any

access-list inout-nat deny ip any any log

access-list websense-bypass permit ip host 10.x.x.200 any

access-list websense-bypass permit ip host 10.x.x.201 any

The problem is, everything gets NAT'd to the first IP (165.x.x.41) including the two IP's in the websense-bypass access list, even though they are denied in the inout-nat access-list. We even swapped around the two PAT statements and after that everything was NAT'd to the WebSense Bypass NAT!

Is there something inherent that we are missing here or is this a bug??

Your help is greatly appreciated!!

Thanks.

2 Accepted Solutions

Accepted Solutions

paddyxdoyle
Level 6
Level 6

Looking through the documentation it states that:

5. nat (regular NAT)—Best match. The order of the NAT commands does not matter. The nat statement that best matches the local traffic is used. For example, you can create a general statement to translate all addresses (0.0.0.0) on an interface. If you also create a statement to translate only 10.1.1.1, when 10.1.1.1 makes a connection, the specific statement for 10.1.1.1 is used because it matches the local traffic best.

So based on that i would assume you don't need the deny statements for your two hosts in your nat1 access-list and ASA should see the rule in the nat2 statement as it contains a better match.

Have you tried removing:

access-list inout-nat deny ip host 10.x.x.200 any

access-list inout-nat deny ip host 10.x.x.201 any

Rgds

Paddy

View solution in original post

This is correct and I agree with Paddy's thoughts.

I would also like to point out that 'deny' statements are *not* supported in access-lists tied to nat statements:

"You can only include permit statements in the access list."

from http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/mr.htm#wp1032129

So, I would suggest removing all 'deny' statements from the ACL's and making your websense ACL more specific than your other one.

Scott

View solution in original post

3 Replies 3

paddyxdoyle
Level 6
Level 6

Looking through the documentation it states that:

5. nat (regular NAT)—Best match. The order of the NAT commands does not matter. The nat statement that best matches the local traffic is used. For example, you can create a general statement to translate all addresses (0.0.0.0) on an interface. If you also create a statement to translate only 10.1.1.1, when 10.1.1.1 makes a connection, the specific statement for 10.1.1.1 is used because it matches the local traffic best.

So based on that i would assume you don't need the deny statements for your two hosts in your nat1 access-list and ASA should see the rule in the nat2 statement as it contains a better match.

Have you tried removing:

access-list inout-nat deny ip host 10.x.x.200 any

access-list inout-nat deny ip host 10.x.x.201 any

Rgds

Paddy

This is correct and I agree with Paddy's thoughts.

I would also like to point out that 'deny' statements are *not* supported in access-lists tied to nat statements:

"You can only include permit statements in the access list."

from http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/mr.htm#wp1032129

So, I would suggest removing all 'deny' statements from the ACL's and making your websense ACL more specific than your other one.

Scott

This is why I love these forums!

Worked like a bomb - thanks Paddy and Scott! One thing though, I did have to make a slight change - I had to swap the Global and NAT numbers around, i.e, make the WebSense bypass global (outside) 1 & nat (inside) 1 and the rest of the users had to be global (outside) 2 & nat (inside) 2. I guess it has to do with the order it processes the NAT lists.

Thanks again!