WERAracer
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
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
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
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
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
ASKER
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)#
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
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.
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.