cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
383
Views
0
Helpful
3
Replies

ACL bound to DMZ interface blocks outbound connections from DMZ hosts

admin_2
Level 3
Level 3

I have a web server in our DMZ. I need to initiate outbound connections from the server to the Internet. The access list bound to the DMZ interface blocks the connection. The access list is necessary for this server to connect to another host across the inside interface. I also have an access list bound to the outside interface that allows connections from the outside to the server in the DMZ. Connections to the server from the outside are successful. Connections from the server in the DMZ to the host inside are successful. Connections from inside to the DMZ are successful. Connections to the outside from the DMZ are blocked by the access list bound to the DMZ interface. Why would the access-list bound to the DMZ interface block outbound traffic from the DMZ to the outside?

Here is an entry in the log showing the dmz_acl blocking an outbound FTP connection from my server:

Deny tcp src dmz:webserver/3531 dst outside:161.114.22.111/21 by access-group "dmz_acl"

Here's is the relevant part of my configuration:

access-list outside_acl permit tcp any host x.x.x.x eq www

access-list dmz_acl permit tcp host webserver host x.x.x.x eq 2638

access-list dmz_acl permit udp host webserver host x.x.x.x eq 2638

global (outside) 1 x.x.x.x-x.x.x.x netmask 255.255.255.0

global (outside) 1 x.x.x.x netmask 255.255.255.0

global (dmz) 1 x.x.x.x-x.x.x.x netmask 255.255.255.0

nat (inside) 1 x.x.x.x 255.0.0.0 0 0

nat (dmz) 1 x.x.x.x 255.255.255.0 0 0

static (dmz,outside) x.x.x.x webserver netmask 255.255.255.255 0 0

access-group outside_acl in interface outside

access-group acl_in in interface inside

access-group dmz_acl in interface dmz

Any suggestions to fix this problem will be greatly appreciated.

3 Replies 3

ehirsel
Level 6
Level 6

Your dmz_acl only allows connections to the dest port 2638, not port 21. Thus the implicit deny all is taking effect. If you intended to use 2638 as the source port, then recode the permit as permit tcp host webserver eq 2638 host x.x.x.x eq 21.

Hopefully you will have an ipsec session, or run the ftp over ssl so that the username and password for the ftp process won't get sent out in cleartext.

Not applicable

Thank you for your response. But, wouldn't the implicit deny only affect connections from the DMZ to the inside? I thought it shouldn't block outbound connections from the DMZ to the outside. Don't hosts behind higher security interfaces have full access to hosts across lower security interfaces by default?

Not applicable

After my last post, I kept thinking about your statement regarding the implicit deny. It dawned on me that after all, the access list bound to the DMZ would examine all traffic coming in or going out. So I added permit statements for http traffic. I'm now able to make outbound connections to the Web. I could add a permit for port 21, but I don't have to at this point. Thanks for pointing me in the right direction.