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
LVL 1
WERAracerAsked:
Who is Participating?
 
egyptcoConnect With a Mentor Commented:
well.. something is nor correct obviously. try to add outside at the end to specify it is outside NAT.


FWALL(config)# nat (outside) 0 access-list nonat outside
0
 
egyptcoCommented:
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
0
 
WERAracerAuthor Commented:
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
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

 
egyptcoCommented:
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
0
 
WERAracerAuthor Commented:
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)#                        
0
 
WERAracerAuthor Commented:
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
0
 
egyptcoCommented:
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.


0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.