cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1320
Views
5
Helpful
3
Replies

General setup of DMZ on ASA 5520 version 8.2(1)

Soren Sjostrom
Level 1
Level 1

 recently upgraded my firewall hardware from an ASA 5505 to an ASA 5520. Since I am a small startup company on a tight budget, I have purchased a used firewall. Unfortunately, the firewall runs on software version 8.2 (1), which I generally find difficult to find any documentation on. So I'm pretty much a beginner on this software.
I have some problems with the setup on my DMZ subnet, which I hope to get some help with. In general, I try to achieve the following:
1) Access to my web server (gateway) from the Internet.
2) Access to my mail server from the Internet.
3) I need to make a hole in the firewall from DMZ to LAN so I can get my Zabbix Proxy to communicate with the Zabbix Server in my LAN subnet. Generally, I am not much to make holes in the firewall, but it is necessary for me to make things work. It is therefore important that only the Zabbix Proxy gets access to my LAN subnet.
I have tried to make some access-lists, but I can't really make it work. Something is still missing.
Here is my running-config regarding access-lists:

object-group network WEB_SERVERS
 network-object host 172.16.1.30
object-group network MAIL_SERVERS
 network-object host 172.16.1.40
object-group service WEB_SERVICES tcp
 port-object eq www
 port-object eq https
object-group service MAIL_SERVICES tcp
 port-object eq smtp
access-list ACL_IN extended permit ip any any
access-list OUTSIDE_TO_DMZ extended permit ip any any
access-list OUTSIDE_TO_DMZ extended permit tcp any object-group WEB_SERVERS object-group WEB_SERVICES
access-list OUTSIDE_TO_DMZ extended permit tcp any object-group MAIL_SERVERS object-group MAIL_SERVICES
access-list DMZ_TO_INSIDE extended permit tcp host 172.16.1.5 host 192.168.1.4 eq 10051
access-list DMZ_TO_INSIDE extended permit tcp host 172.16.1.5 host 192.168.1.4 eq 10050
access-list DMZ_IN extended permit ip any any

access-group OUTSIDE_TO_DMZ in interface outside
access-group ACL_IN in interface inside
access-group DMZ_TO_INSIDE in interface dmz

 

Best regards

3 Replies 3

xAdventix
Level 1
Level 1

1) Access to my web server (gateway) from the Internet. -> Do you have NAT configured for this? 
2) Access to my mail server from the Internet. -> Do you have NAT configured for this?
If you do, from my memory pre 8.3 you have ACLs checked before NAT in the order of operation. Easy way to check this is utilising packet-tracer. My best advice is to abuse this and work out where it's failing, this will give you the detailed operation of each part showing where the issues lie. 

 

Questions regarding ACL's:

Why are we doing permit ip any any ? 
access-list OUTSIDE_TO_DMZ extended permit ip any any

I assume you are happy for the inside to access anything which is fine, as well it appears you made a typo in the following:

access-list DMZ_IN extended permit ip any any <- This should be the Access-group DMZ name. Please note again, this is a permit ip any any which doesn't make sense? 

So far the ACL's are obsolete due to the permit ip any any referenced on these. Secondly, could you provide packet-tracers for the ACL's you've put? 

xAdventix
Level 1
Level 1

1) Access to my web server (gateway) from the Internet.
2) Access to my mail server from the Internet.
For the first two points, do you have NAT configured? If so, the ACL's are incorrect from my memory, as I believe it checks the ACL before NAT within the order of operation and if not, I assume you've changed the IP addresses. 

 

Please also note, you've put permit ip any any for outside which means any other permit rules are obsolete. ---> access-list OUTSIDE_TO_DMZ extended permit ip any any -> This is super bad practice and basically says firewall is obsolete. 

 

You have typo'd this: access-list DMZ_IN extended permit ip any any -> This should be the DMZ access-group like the others, but why are we doing a permit ip any any again? As this makes all the other ACL's obsolete and again very bad practice. 

 

For the 3rd point, can you provide packet tracers to show where it's failing? This should help us pin point the problem. 

Thanks for your reply, appreciate it very much.
I deleted the two access lists - they arrived late in the night when I was tired and tried to make things work (as I wrote, I am a novice here).

The following NAT rules are defined:
global (dmz) 101 interface
global (outside) 101 interface
global (data) 101 interface
nat (dmz) 101 172.16.1.0 255.255.255.0
nat (dmz) 101 0.0.0.0 0.0.0.0
nat (inside) 101 192.168.1.0 255.255.255.0
nat (inside) 101 0.0.0.0 0.0.0.0
nat (data) 101 192.168.128.0 255.255.255.0
nat (data) 101 0.0.0.0 0.0.0.0
static (dmz, outside) tcp interface www 172.16.1.30 www netmask 255.255.255.255
static (dmz, outside) tcp interface https 172.16.1.30 https netmask 255.255.255.255
static (dmz, outside) tcp interface smtp 172.16.1.40 smtp netmask 255.255.255.255

Here are output from packet-tracer regarding the web server:
Phase: 1
Type: FLOW-LOOKUP
subtype:
Result: ALLOW
config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
config:
Additional Information:
in 172.16.1.0 255.255.255.0 dmz

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
config:
access-group OUTSIDE_TO_DMZ in interface outside
access-list OUTSIDE_TO_DMZ extended permit for any object-group WEB_SERVERS object-group WEB_SERVICES
object-group network WEB_SERVERS
network-object host 172.16.1.30
object-group service WEB_SERVICES tcp
port-object eq www
port object eq https
Additional Information:

Phase: 4
Type: IP-OPTIONS
Result: ALLOW
config:
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf check
Result: Drop
config:
static (dmz, outside) tcp interface www 172.16.1.30 www netmask 255.255.255.255
match tcp dmz host 172.16.1.30 eq 80 outside any
static translation to 109.xxx.yyy.131 / 80
translate_hits = 0, untranslate_hits = 159
Additional Information:
Result:
input interface: outside
input status: up
input-line status: up
output interface: dmz
output status: up
output-line status: up
Action: Drop
Drop-reason: (acl-drop) Flow is denied by configured rule

 

As far as I can see, it's my NAT rules that are wrong - but I don't know how the rules would otherwise look like.

The same problem applies with regard to the mail server and access from DMZ to LAN.

 

Best regards

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: