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. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

DMZ setup. Net from inside?

Hi,

 I was trying to configure a DMZ on our firewall for a webserver.

Our topology is  ...  Internet > Router 3925 > ASA5525 > Switch(inside LAN)

I have an interface on the ASA connected to the DMZ switch. ASA5525 > DMZ switch > Web server. The ACEs for the DMZ permit only tcp/https traffic.

The NATing is on the router for the WServer access from outside.

Do I need to configure a NAT statement for access from inside? Or the URL (Linked to the public ip address) will work from the inside too?

Hope my question is clear.

 

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

Ok, let us analyze your ACLs

Ok, let us analyze your ACLs one by one to clear any confusion.

access-list DMZ_access_in extended permit tcp object GSB_Web_Server any eq https log debugging

As you said, you will not need this entry since you don't want the web server itself to access anything. The purpose is to be accessed. However, you may need the web server to access, for example, the internet for online updates. But i would recommend to push updates locally from an internal update server. (Result: Not Necessary)

access-list DMZ_access_out extended permit tcp any object GSB_Web_Server eq https log debugging

This is not necessary as the below entry accomplishes the same goal.The difference is the below entry limits the access to the outside world only. You can keep it ONLY if you want also internal users to access the web server as well. In this case, you don't need the below entry. (Result: Necessary only if you want the web server to be accessed by both outside and inside users)

access-list outside_access_in extended permit tcp any object GSB_Web_Server eq https log debugging (Result: Necessary only if you want the web server to be accessed by outside users only)

 

access-list outside_access_out extended permit tcp object GSB_Web_Server any eq https log debugging

This is not necessary at all and must be removed. (Result: Not Necessary)

As you can see, you only need the necessary ACL that i mentioned in order to let the outside users access the web server.

Keep in mind that traffic and interface directions are very critical and they differ. The "out" keyword is rarely used and creates more confusion. You should only focus with the "in" keyword. If you still don't understand what i clarified, i suggest to read more about traffic and ACL directions in ASA.

Also, same security levels (inside and DMZ interfaces) minimizes the need for ACLs and NAT. However, ACLs and NAT are still needed for outside interface. The NATing also should be in the ASA.

Hope this helps.

AM

 

 

 

 

 

16 REPLIES
New Member

What version is your ASA? ..

What version is your ASA? .. If 8.3+, then no need for NATing between inside and DMZ interfaces. Just set the same security levels between the interfaces and issue the "same-security-traffic permit intra-interface". Also, no need to ACLs either. Access is open. Internal users do NOT need to access the web server by its public address if they can access it locally using its private address.

New Member

The ASA version is 9.1. Isn't

The ASA version is 9.1. Isn't the purpose of the DMZ is to have sec level between 0-100. Mine is set at 50.

 

Below are the DMZ int ACL enteries.

access-list DMZ_access_in extended permit tcp object WebServer any eq https log debugging

access-list DMZ_access_out extended permit tcp any object WebServer eq https log debugging

access-group DMZ_access_in in interface DMZ

access-group DMZ_access_out out interface DMZ

We have internal access to the server to its other NIC. But how do we access the URL from inside. (As URL is associated to the public ip). My understanding is when trying to access the URL from inside, the traffic passes through the ASA to the router, detects the NAT entry and then router sends it back to the ASA and the ASA forwards it to the DMZ int. Is this correct?

New Member

Hi,First, both of your access

Hi,

First, both of your access lists are not correct. Because you want your web server to be accessed by the public, you must modify the first ACL so that the web server is the destination (not the source). Source should be ANY. The second ACL is not important at all and doesn't accomplish anything. It is even not recommended to use the "out" keyword in your access group command.

access-list DMZ_access_in extended permit tcp any object WebServer eq https log debugging

I believe you must have a different local URL for the web server. Refer to the DNS server and check for A (host) record for your web server. Your scenario can work ONLY if you implement a feature in the ASA called "DNS Rewrite" and if the ASA does the NATing not the router.

Beginning from 8.3, NAT is no longer forced as in previous versions. So, you can set both the inside and DMZ interfaces to be 50 and you can access both resource without NATing and ACLs.

My questions to you:

1) Why wouldn't you do the NATing in the ASA? why the router?

2) I am not sure what is the problem exactly. Is it just URL internal access issue ?

3) Is it outside access issue?

 

AM

New Member

Sorry i made a mistake here.

Sorry i made a mistake here. Let me rephrase the first ACL issue.

Because you want your web server to be accessed by the public, you have two ways:

- Use Outside ACL Inbound:

access-list Outside_access_in extended permit tcp any object WebServer eq https log debugging

- Use DMZ ACL Outbound: (your 2nd ACL is correct in this case)

access-list DMZ_access_out extended permit tcp any object WebServer eq https log debugging

 

I prefer the first method because your limiting your web server access to the outside ONLY. The second method is allowing everybody to access the web server.

 

New Member

Thank you for correcting

Thank you for correcting yourself. You seriously had me confused. Relieved now.

Partly its my fault as I didn't send in all the relevant ACEntries. I do have the first ACL u mentioned in the list. Below is the full list (only relating to the webserver. No ACLs for the inside)

access-list DMZ_access_in extended permit tcp object GSB_Web_Server any eq https log debugging
access-list DMZ_access_out extended permit tcp any object GSB_Web_Server eq https log debugging
access-list outside_access_out extended permit tcp object GSB_Web_Server any eq https log debugging
access-list outside_access_in extended permit tcp any object GSB_Web_Server eq https log debugging
access-group outside_access_in in interface outside
access-group outside_access_out out interface outside
access-group inside_access_in in interface inside
access-group inside_access_out out interface inside
access-group DMZ_access_in in interface DMZ
access-group DMZ_access_out out interface DMZ

Now I understand what you mean by my forst ACL is not necessary.

access-list DMZ_access_in extended permit tcp object GSB_Web_Server any eq https log debugging

 If I am access the server from inside I will be allowed. If I am accessing from outside my 4th ACL will permit. I do not need incoming rule fOR DMZ interface as the web server would be access anything. Just annswering requests. Correct?

Will answer your 3 qs once this is cleared.

Really appreciate your time. Huge help. Thanks

 

New Member

Ok, let us analyze your ACLs

Ok, let us analyze your ACLs one by one to clear any confusion.

access-list DMZ_access_in extended permit tcp object GSB_Web_Server any eq https log debugging

As you said, you will not need this entry since you don't want the web server itself to access anything. The purpose is to be accessed. However, you may need the web server to access, for example, the internet for online updates. But i would recommend to push updates locally from an internal update server. (Result: Not Necessary)

access-list DMZ_access_out extended permit tcp any object GSB_Web_Server eq https log debugging

This is not necessary as the below entry accomplishes the same goal.The difference is the below entry limits the access to the outside world only. You can keep it ONLY if you want also internal users to access the web server as well. In this case, you don't need the below entry. (Result: Necessary only if you want the web server to be accessed by both outside and inside users)

access-list outside_access_in extended permit tcp any object GSB_Web_Server eq https log debugging (Result: Necessary only if you want the web server to be accessed by outside users only)

 

access-list outside_access_out extended permit tcp object GSB_Web_Server any eq https log debugging

This is not necessary at all and must be removed. (Result: Not Necessary)

As you can see, you only need the necessary ACL that i mentioned in order to let the outside users access the web server.

Keep in mind that traffic and interface directions are very critical and they differ. The "out" keyword is rarely used and creates more confusion. You should only focus with the "in" keyword. If you still don't understand what i clarified, i suggest to read more about traffic and ACL directions in ASA.

Also, same security levels (inside and DMZ interfaces) minimizes the need for ACLs and NAT. However, ACLs and NAT are still needed for outside interface. The NATing also should be in the ASA.

Hope this helps.

AM

 

 

 

 

 

New Member

Hey, I went through what you

Hey,

 I went through what you explained and it totally made sense. I made the appropriate changes and the DMZ is set up and working as expected.

 

Thanks!!!

Also regarding NATing at the router, thats how it was setup from before. Will look into it and make changes if necessary.

 

I really appreciate your time and the detailed explanation.

 

Thanks again!

New Member

Great !! Very glad it works

Great !! very glad it works.

You can use packet tracer to test your directions.

packet-tracer input inside tcp src_ip src_port dest_ip dest_port

The output is shown in phases and result of each phase. If all results in all phases is "ALLOW", then everything works.

 

New Member

Hey. Had a question regarding

Hey.

 

Had a question regarding putting both the DMZ and the inside on same securit level.

 

Isn't it vulnerable to spoofing attacks. If anyone spoofs the webserver IP they will have access to the inside.

New Member

Hi,There is a default

Hi,

There is a default functionality in ASA called "uRPF" stands for Unicast Reverse Path Forwarding. When a source traffic comes in and hit, lets say, the inside interface, the ASA checks the IP of the sender. If the IP belongs to other interfaces (DMZ or Outside), it knows that it is a spoofed address, RPF test fails, and it drops the traffic. If the IP does NOT belong to other interfaces, it knows that it is valid and forward the traffic to other processes such as ACL lookup, NAT lookup, inspection engines,...etc. So, even if there are same security interfaces, traffic cannot be spoofed easily because of the uRPF feature. This feature, actually, does its job by using the route table.

This RPF is part of "Initial Checking" process, in which the ASA does an initial traffic checking for spoofed senders. The beauty is that, this process is done early in the game before any ACL or address translations lookups, thus saving firewall resources. You don't want the firewall to detect spoofers late in the game after consuming unnecessary resources caused by this spoofed traffic.

 

AM

New Member

Sorry, i made a minor mistake

Sorry, i made a minor mistake. This feature is not by default enabled in the ASA. You have to enable it for each interface by using the below command:

ip verify reverse-path interface outside

 

AM

New Member

AM. You are awesome!!!Will

AM. You are awesome!!!

Will look into this. Thanks.

New Member

Thank you. :-) I am just

Thank you. :-) I am just trying to help.

Please feel free to ask any question at any time.

 

AM

New Member

Actually I do have a question

Actually I do have a question about EHWIC replacement for a switch.

Currently we have Cisco ISR router connecting to a switch for ASA failover.

I want to replace the switch with a EHWIC 4ESG module on the router.

New Member

Hi,I recommend to post this

Hi,

I recommend to post this issue in the 'WAN, Routing and Switching' topic in the 'Network Infrastructure' section.

I am really sorry but i can't help you with this.

 

AM

New Member

No problem AM. Thanks again

No problem AM.

 

Thanks again for the DMZ issue. Big help!!!

106
Views
0
Helpful
16
Replies