Link to home
Start Free TrialLog in
Avatar of WERAracer
WERAracerFlag for United States of America

asked on

Need help deploying internal firewall please

We need to deploy an internal firewall. Several questions:

1. Can I have the untrusted side, access hosts via their actual addresses? Or do they need to hit one of the pix's interfaces?  I think Pix's don't allow this, but I am not sure.  For example, can 10.24.1.1 access 172.16.31.80 directly?

2.  Is this commonly done with a pix?

3. I need some advice here, I'm hitting a wall

thanks
Avatar of egyptco
egyptco
Flag of Austria image

yes it does that. you need to configure nat exemption (NAT Statements with NAT 0) see http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00800b6e1a.shtml#multi_nat
Avatar of WERAracer

ASKER

so this will work coming from the untrusted side? I have used nonat commands for ipsec tunnels. But I need to know that it works the opposite direction to? Untrusted to trusted
it should work as long you explicitly permit the traffic on the outside interface. lets say you need 10.24.1.1 to access the entire internal network without translation:

access-list outside-to-inside permit ip host 10.24.1.1 172.16.31.8 255.255.255.0
access-list nonat permit ip host 10.24.1.1 172.16.31.0 255.255.255.0

nat(outside) 0 access-list nonat
I tried that and this is what it said:

FWALL(config)# nat (outside) 0 access-list nonat
WARNING:  Specified interface is lowest security interface. This statement
WARNING:  is not applicable to any traffic.                              
FWALL(config)#                        
ASKER CERTIFIED SOLUTION
Avatar of egyptco
egyptco
Flag of Austria image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
tried that, says there is no translation group found (in the log)
I opened up a TAC case with Cisco and they are looking at it
OK. I did some research and it is bit trickier that I thought. the problem is that I've presumed  configuring exemption on outside would work in the same way as configuring such on inside, but it doesn't. there is a small documentation gap of configuring outside nat on pix. cisco would encourage you to use static, which is probably the better and "more intuitive" solution in your case. you need to statically translate all inside hosts which are supposed to be  accessed from outside. lets say you have 2 hosts on inside 172.16.31.10 and .20 and you want to access them without translation from outside. you configuration should be:

static (inside,outside) 172.16.31.10 172.16.31.10 netmask 255.255.255.255
static (inside,outside) 172.16.31.10 172.16.31.20 netmask 255.255.255.255

if you have asa where nat-traversal disabled it should work without that trick but since pix needs always xlate translation entry you need statically to map every inside host to appear with its inside address on outside.

just for sake of completeness to configure outside nat (outside hosts to be nat'd with inside addresses). by doing that, if your inside host  tres to initiate outbound connection will end up with this message because once an outside nat statement is added, all outside hosts must meet a nat rule. there is very interesting discussion on this topic - http://www.velocityreviews.com/forums/t32235-need-help-with-pix-message-quot305005-no-translation-group-foundquot.html

so for example if you want you entire 10.24.1.0 to appear with  the ip of the inside interface on inside you should do:

access-list nonat deny ip 10.24.1.0 255.255.255.0 172.16.31.0 255.255.255.0
access-list nonat permit ip any any
nat (outside) 0 access-list nonat
nat (outside) 10 10.24.1.0 255.255.255.0
global (inside) 10 interface

but the above configuration would still been preventing inside hosts to initiate outbound connections to network 10.24.1.0 since it is dynamically nat'd.

in conclusion configuring static is the best way of achieving your goals. for outside nat  you should take some considerations.