cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
978
Views
0
Helpful
8
Replies

Cant pass traffic between interfaces with the same security

Rex Biesty
Level 1
Level 1

Hi. We have an ASA5510 firewall and I have 2 inside interfaces (both 100 security) on different subnets, both use NAT to access the internet. I'm trying to enable traffic from one interface (192.168.1.0) to my websense server on the other (172.16.1.8) so websense displays it's blockpage message (currently when users on 192.168.1.0 access a restricted site they're getting either a 'page cannot be displayed' message or a 'Live Search' page).

I've tried adding the following commands but just cannot get it to work (not even ping).

Same-security-traffic permit inter-interface

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.0.0 192.168.1.0 255.255.255.0

access-list Non-Opps-Orgs_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 172.16.0.0 255.255.0.0

nat (Non-Opps-Orgs) 0 access-list Non-Opps-Orgs_nat0_outbound

All devices use the firewall as their default gateway and there are no static routes on any on the computers.

Any ideas would be greatly appreciated.

Rex

1 Accepted Solution

Accepted Solutions

ddawson
Level 1
Level 1

You're seeing one of the subtleties of the "nat-control" command. Because you have a nat/global pair configured on the Non-Opps-Orgs interface to the outside, that's blocking the default functionality of the "no nat-control" feature for traffic to other interfaces, such as the inside interface. This means you either have to configure an explicit nat exemption between the Non-Opps-Orgs and Inside interfaces (in both directions), or just configure static identity NAT between them (in both directions). Personally, I prefer the old-school static identity NAT, since it's easy and obvious. For example, if you add these two commands to your config I think it'll work:

static (inside,Non-Opps-Orgs) 172.16.1.0 172.16.1.0 netmask 255.255.255.0

static (Non-Opps-Orgs,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

View solution in original post

8 Replies 8

ddawson
Level 1
Level 1

You're seeing one of the subtleties of the "nat-control" command. Because you have a nat/global pair configured on the Non-Opps-Orgs interface to the outside, that's blocking the default functionality of the "no nat-control" feature for traffic to other interfaces, such as the inside interface. This means you either have to configure an explicit nat exemption between the Non-Opps-Orgs and Inside interfaces (in both directions), or just configure static identity NAT between them (in both directions). Personally, I prefer the old-school static identity NAT, since it's easy and obvious. For example, if you add these two commands to your config I think it'll work:

static (inside,Non-Opps-Orgs) 172.16.1.0 172.16.1.0 netmask 255.255.255.0

static (Non-Opps-Orgs,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

Thanks, that worked a treat. Just out of interest, would it be easy to restrict Non-Opps-Orgs to a particular IP and protocol on the inside network?

You could restrict IP addresses by only doing NAT for the address(es) you want to allow, but to restrict by individual ports you'd be better off using access-lists.

Might be one to research in the new year but thanks for your help anyway, much appreciated.

question about your answer. Once upon a time wasn't there a limit on how many net statics you could have defined? Let say you had 20 subnets each with 255 addresses?

There's never been a hard limit on the number of static commands you could configure, though there were (and still are) limits on how big your entire configuration could be. However, there did used to be more restrictions on statics that overlapped (they weren't allowed at all), but now you *can* have overlapping static commands and they are processed in order. For example, say you have a network static but want to map one of the addresses in the network to some other public address. This used to not be allowed, but now (as of 7.0) you can get the desired behavior as long as you configure the individual static command(s) before any more general network statics commands that would include the individual inside host(s).

Hi DANA

I have a query on the ablove question.If we add the following entry

"access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.0.0 192.168.1.0 255.255.255.0" will it work?

look for ur valuable answer..

Ullas

Yes, that will work too, since the "nat 0 access-list" command *does* have the side effect of creating the necessary xlates for lower-to-higher traffic. Many people prefer this approach, but I still like the "old way" since it's usually fewer commands.

Review Cisco Networking for a $25 gift card