cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1535
Views
0
Helpful
12
Replies

DMZ server unable to access outside world

bberry
Level 1
Level 1

OK .. I am have an odd issue I am unable to figure out. I have a new ASA 5520 that we implemented last week. I have the standard inside, DMZ, outside interfaces set at security levels of 100, 40 and 0 respectively. I have an ACL for inside traffice and outside traffic and one rule for a DMZ server that pulls information from the inside. My issue surrounds a server in the DMZ that users connect to and initiate an FTP session to the outside to pull data from a vendor. It was unable to make an FTP connection so I added an rule for port 21 with an any destination. Still no luck. I modified the rule for it to be any destiantion IP port and server seems to work just fine. In looking at the log for this server it builds a dynamic translation for the outside to my gobal address and then starts a port 21 session.

I thought that by default you did not need any rules to go from a lower level to a higer level. Do I need a generic rule to allow the dynamics to be built? I basically copied the config from our PIX and dropped it onto the ASA. Is there somthing that I could have possibly missed in the configuration? I am going to try a little testing to see if any of the other servers act the same trying to get to the outside from them.

I have attached a filtered log from the ASA to show the activity. I can attach a copy if the config if needed.

Brent

12 Replies 12

Brent,

You don't need to define a rule for higher-security to lower-security unless there's an ACL already applied to the higher-security interface.

This is because as soon as there's an ACL, everything not defined is denied implicity.

Also, the ASA uses the inspection to dynamically open the responses from outbound connections (the PIX used the fixup)

Federico.

So because I have DMZ ACL rules that apply to traffic to the inside I will now have to have rules to the oustide? I guess the any destination makes no descression between the inside interface and the outside interface. If that is the case then I can understand the rule for FTP then but do not understand needed a rule for the dynamic TCP build unless there is somethig else going on that the log is not catching.

Yes.

If you have an ACL applied to the DMZ, then it will apply to any traffic entering the DMZ interface (this applies to traffic going to the inside or outside).

You're right the ''any'' keyword applies to any destination (inside or outside).

As soon as there's a single statement in an ACL, everything that needs to be permitted must be explicitly defined in that same ACL.

If you're still seeing a strange behavior please post the part of the configuration and an explanation of the connection.

Federico.

Here is the DMZ ACL I have so far.

access-list dmz_access_in extended permit ip host A-192.168.45.10 any log  
access-list dmz_access_in extended permit ip host A-192.168.45.25 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.30 any eq ftp log
access-list dmz_access_in extended permit ip host A-192.168.45.30 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.40 object-group MailServers eq smtp log
access-list dmz_access_in extended permit icmp any any

45.10 is there to see if anything specific external DNS needs to / from inside.

45.25 runs a home built application and current programmers are not 100% sure what ports it uses to come to the inside to pull its report data.

45.30 is the server in question that uses FTP to the outside world. Once I know I am going to taylor the ACL and eleminate the IP

45.40 is inbound mail filter.

icmp is for testing connectivity to servers from inside to DMZ

This ACL replaces the permit any any that was originally inbound and outbound on the PIX.

Do I need a generic so that any other DMZ server that needs out can build the translation?

access-list dmz_access_in extended permit ip host A-192.168.45.10 any log  
access-list dmz_access_in extended permit ip host A-192.168.45.25 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.30 any eq ftp log
access-list dmz_access_in extended permit ip host A-192.168.45.30 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.40 object-group MailServers eq smtp log
access-list dmz_access_in extended permit icmp any any

Assuming the above ACL is applied to DMZ (access-group dmz_access_in in interface DMZ)

The only traffic permitted is the traffic defined by that ACL.

Federico.

That is applied to the DMZ interface inbound.

I have added a rule to allow the DMZ network access to ASA global in IP port to see if that will allow the creation of the translations and I can remove the IP port rule for the 45.30 server.

Ok .. now I am really confused ... I have the following for my DMZ ACL. I added the first rule so that servers could build a translation and connect to the outside world. I would then remove the server specific ip port rules. My server that uses FTP (45.30) to access the outside world also needs to permit IP any to build the translations and then everything works fine. Without the ip any rule that server cannot FTP to the outside world. The IP address in the build is my global address and is in the 206.197.1.0 range. It appears that I am having to have an ip any rule for any server in the DMZ to be able to get to the outside world. I created the first rule so that I would not need a specific rule for every server. When I look at the log I am seeing the builds and teardowns for say the 45.30 server but when I look at the hit counts the first rule has a count of zero. What gives? I really don't waant a cart blanch (sp) rule for servers in the DMZ to go anywhere. Seems to defeat the security purposes and would be no better than a permit ip any any rule for the DMZ.

access-list dmz_access_in remark Generic rule so servers and build translations
access-list dmz_access_in extended permit ip 192.168.45.0 255.255.255.0 206.197.1.0 255.255.255.0 log
access-list dmz_access_in extended permit ip host A-192.168.45.10 any log
access-list dmz_access_in extended permit ip host A-192.168.45.25 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.30 any eq ftp log
access-list dmz_access_in extended permit ip host A-192.168.45.30 host 206.197.1.3 log
access-list dmz_access_in extended permit ip host A-192.168.45.30 any log
access-list dmz_access_in extended permit tcp host A-192.168.45.40 object-group MailServers eq smtp log
access-list dmz_access_in extended permit ip host A-192.168.45.40 any log
access-list dmz_access_in extended permit icmp any any

I have also noticed there are 23,000 hits on the ip any rule for 45.40 when there are only 3,000 hits for the smtp rule and that rule only handles in-bound mail for our barracuda.

Maybe I am just being too paranoid....

Brent

For security reasons you can avoid the ''any'' keyword in the ACL and instead just specify the ports you need either TCP or UDP.

For FTP sometimes a single ACE won't work because if you're using Passive FTP, both the control and data channel for FTP are initiated by the client, but if you're using Active FTP, then after the client opens the control channel, the data channel is initiated by the server (and this might not be allowed).

For such applications that behave using dynamic ports, it is required to ''inspect'' those sessions to dynamically open the return traffic.

Federico.

I thought I would catch any other needed ports in the log with the IP rule. In the case of the FTP server, there is a build or two, the port 21 then a eardown or two. I am seeing no other ports in the log using information on the IP rule.

If you have the FTP client on the DMZ, and creating an FTP connection to an outside server...

If using Passive FTP it should work, but the control channel goes to port 21 on the server and the data channel uses port 20.

If using Active FTP, you should allow somehow the return connection from the server (either via an ACL on the outside interface or preferred have the ASA inspect the FTP traffic).

Federico.

Well, for you to know things..

First know the logic of ports, as said by one of our cisco colleague engineer, FTP are of two types PASSIVE and ACTIVE.

ACTIVE FTP uses different methodlogy while PASSIVE FTP uses different logic.

I am sure CISCO Documentation will guide you more into this.

I understand that. It is passive FTP as I only have the rule for port 21. What I do not understand is why i ALSO need a rule for IP? I have informational for the log and the ONLY thing that appears in the log is the build and teardown of the translations. I understand needing to be specific in the rules once a set is started but I would think I could have a rule other than the server to any via IP to get everything to work. I added a rule for the server to the address in the log for the build & teardown and I get no hits on it. I added a rule to allow the entire DMZ network to the entire outside network and have results no hits. The only conbination that allows everything to work is...

access-list dmz_access_in extended permit tcp host A-192.168.45.30 any eq ftp log

access-list dmz_access_in extended permit ip host A-192.168.45.30 any log

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: