ASA 5520 general questions

broeder · ‎10-08-2008

1. Do I need to nat translate all of my internal networks back to the same addresses to get to internal DMZ's in oreder for communications to take place. It seemed that I had to do this to get it to work

2. I am converting from Checkpoint to ASA 5520 and am taking each rule in the Checkpoint and trying to add an equivalent access list command in the ASA. In Checkpoint, all rules are just added with no interface specified, but in the ASA it wants an interface to assign it to. So the question is this: When converting these Checkpoint rules to the ASA, what direction should the converted access list be (inbound or outbound), and, what interface would I apply it to? I've included a snapshot of a few of the Checkpoint rules for reference in this conversation. Rule #2 source inex2-owa is in the DMZ and the dest. FDBSID is on the inside.

Thanks for your help.

Frederick Reimer · ‎10-08-2008

0) I don't necessarily believe in security by obscurity, but you should never share your firewall rules to the public at large...

1) You can use NAT exemption to handle this. It is not necessarily required if you use no nat-control, which is the default unless you upgraded your ASA from an earlier configuration where no nat-control was not available. I'd recommend NAT exemption.

2) There is a tool available to convert a Checkpoint config to an ASA config. I'd recommend using that and then tweaking the configuration by hand - never use the converted configuration without tweaking. As far as ACL direction, the usual approach is to apply inbound ACL's on all interfaces. Outbound ACL's are generally used to further tweak the policy if required.

Thanks,

Fred Reimer

Senior Network Engineer

Coleman Technologies, Inc.

Marwan ALshawi · ‎10-08-2008

for ACL use the following general guides

any traffic sourced from higher security level to lower security level u dont need ACL

if the traffic from lower to higher u need ACL to permit that traffic and nating as well

let take simple example

lets say u have DMZ 192.168.1.0/24

and inside 192.168.10.0/24

inside sec level 100 DMZ sec level 50

now we can make communication between those two networks as follow

static (inside, DMZ) 192.168.1.0 192.168.10.0 netmask 255.255.255.0

access-list 100 permit ip 192.168.1.0 255.255.255.0 192.168.10.0 255.255.255.0

access-group 100 in interface DMZ

this is one way and i found it simple

for nating and access to internet from inside

nat (inside) 1 192.168.10.0

global (outside) 1 interface

if u have host withc public address on the DMZ needed to be accessed from internet u can make static nat like

lets say the host IP is 192.168.1.1 on DMZ

public IP 1.1.1.1

static (DMZ, outside) 1.1.1.1 192.168.1.1 netmask 255.255.255.255

access-list 101 permit tcp any host 1.1.1.1

access-group 101 in interface outisde

here we allwoed http access to a host in the DMZ through the internet

good luck

if helpful Rate

cisco24x7 · ‎10-08-2008

"0) I don't necessarily believe in security by obscurity, but you should never share your firewall rules to the public at large..."

I think this is perfectly fine. Do you know the IP addresses of these devices with

this security policy

I've some experience with Checkpoint so hopefully what I am saying here will make some senses:

The security policy you share with us is not complete. In order to know how things work, we need

to know the following information:

- How many interfaces does this firewall have?

- Do you have "hide" NAT (aka PAT) and "static NAT? If so, can you share the NAT table?

The complexity of the conversion really depends on how many interfaces you have on the

Checkpoint firewall. Furthermore, it also depends on how complex NATting you do on the

checkpoint firewall. Remember that Checkpoint has NO security level on its interface.

Why don't I give you an example with your security policy by looking at rule #4:

Let say you have 10 interfaces on the Checkpoint firewalls. If you look at rule #4,

you then will have to create 9 different access-list names to apply on 9 different

interfaces that you will allow traffics to get to your INEX2-OWA. Now you get the idea.

From there, the problem can get only worse. If you have complex NAT in Checkpoint it will

get ugly in converting it over to Cisco. Let me give you another example:

Assume that your INEX2-OWA has an IP address of 192.168.1.1 and you NAT it 1.1.1.1.

Now you want everyone to get to this host as 1.1.1.1 BUT you want source 129.174.1.0/24

get to this host as 1.1.1.2 and that you want outbound traffics from 192.168.1.1 be seen

as 1.1.1.4 if it is trying to get to 4.2.2.2. Now you get the idea how complex it has

become.

I am going to offer you this advise: Be VERY careful when you do this because there is

a very likelyhood you will cause a network outtage.

my 2c