DMZ setup. Net from inside?

[NInja Black]

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.

[turbo_engine26]

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.

[NInja Black]

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?

[turbo_engine26]

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

[turbo_engine26]

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.

[NInja Black]

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

[turbo_engine26 · Accepted solution]

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

[NInja Black]

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!

[turbo_engine26]

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.

[NInja Black]

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.

[turbo_engine26]

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

[turbo_engine26]

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

[NInja Black]

AM. You are awesome!!!

Will look into this. Thanks.

[turbo_engine26]

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

Please feel free to ask any question at any time.

AM

[NInja Black]

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.