Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASA and introducing DMZ

I have recently inherited a network with around 80 hosts containing mostly web, mail, and database servers. After auditing their ASA 5510, I found a major security issue I want to fix with as little service interruption as possible. The problem is that the ASA is only configured with 2 interfaces:

Outside = 123.123.123.0/29

Inside = 234.234.234.0/24

Both subnets are public address blocks, and the 234.234.234.0/24 subnet is currently assigned to the hosts.

To fix this I would like to introduce at least one DMZ interface to separate the web and mail servers from the database servers. My proposed setup would be:

DMZ = 10.10.10.0/24

Then I would NAT the public IP to DMZ interface to prevent having to change DNS for the sites that the web servers run.

My question is how can I introduce this DMZ with as little server interruption as possible? Could I take one host at a time and change the IP of that host to a 10.10.10.X IP, then issue a NAT command something like this?:

static (dmz,outside) 234.234.234.X 10.10.10.X netmask 255.255.255.255 dns

Keep in mind that the 234.234.234.0/24 subnet is still assigned to the inside interface and there will still be other hosts that are live within that subnet. Will the static (dmz, outside) 234.234.234.X override and route to the DMZ instead of the inside?

Of course in the end, I will have a new subnet on the inside, something like 10.0.0.0/24 and the only interface with a publicly routed subnet will be the outside.

I'm open for any ideas, thanks for your time.

5 REPLIES
New Member

Re: ASA and introducing DMZ

Mate,

Not sure if this will work, I know that the PIX will NAT and then router which means when you have a request from the outside towards a host on your DMZ, the PIX will translate the destination address and then forward the packet to the destination host. The fact that you have your inside interface addressed with the same range is a bit confusing and I don't think that I can give you an accurate answer.

My recommendation is: Save the hassle, write a proper plan and do a big bang migration ... it saves you time and it will be cleaner and more efficient.

Even if your approach worked, how are you going to deal with server-2-server traffic where hosts on the DMZ will need to talk to hosts on the inside while your migrating? You will need to consider more elements and you will expose yourself to more risk.

That's my personal opinion.

Cheers,

S.

New Member

Re: ASA and introducing DMZ

scheikhnajib,

Thanks for your reply. I was hoping to avoid this but I'm not sure I can. Only problem is changing 80+ servers all at once is no small task.

Thanks for your help.

New Member

Re: ASA and introducing DMZ

phillips,

The method that you are suggesting should work.

if you have a static translation of a host in the dmz with the public address belonging to the inside..it does not matter because the firewall will be loooking for a route to the 10.x.x.x IP and not the 234.x.x.x ip...right?

My feeling says it should work, chnage the IP of one server at a time to bring it to the dmz after creating the static translation.the access list is already there I guess applied to the outside interface.

However you might also want to consider communication between your webserver/app servers and the DB servers because once you create the dmz and move servers there, webservers and app servers will now have to traverse the firewall to reach the DB servers...in contrast to the current scenario where all servers are in one zone "INSIDE"

Naseem

New Member

Re: ASA and introducing DMZ

Naseem,

Thank you very much for your input.

I'm going to test this next week during our maintenance window. I will let you know what the results are.

New Member

Re: ASA and introducing DMZ

Naseem,

Just wanted to update you as I tried this during our maintenance window last night. This worked!!!

I did have some issues talking back to the 234.234.234.0/24 from the DMZ, but that's expected. Only quirk I found was in the ASDM. I added the DMZ interface in the ASDM, but setup the static NAT rule via the command line tool in the ASDM. After I verified that it worked, I removed the static NAT rule from the ASA via the ASDM. The ASDM tried to get smart and screwed up my outside_acl. It basically replaced everything with 234.234.234.X with the DMZ's subnet of 10.10.10.X. I'm not sure why it did it but it of course broke all external access in. I had to quickly fix it but it wasn't a major issue.

I guess the ASDM was confused because of the NAT to the DMZ and that the inside had the same subnet bound to it.

Anyways, this did work and I guess I will not be able to use the ASDM (or will need to be very careful) until it's all migrated over. Thanks for your help on this.

118
Views
0
Helpful
5
Replies
CreatePlease to create content