Re: PIX/DMZ problems

petersontom · ‎08-23-2005

I have a test web server inside our DMZ that accesses a sql server on the inside network. The problem is when I create the access rule

access-list DMZ_inf_in permit tcp host 172.16.10.250 eq 1433 host 10.10.2.28 eq 1433 and create the static route

static (inside,DMZ) 10.10.2.28 10.10.2.28 netmask 255.255.255.255 0 0

The SQL server becomes unavailable to the network.

See PIX logs:

Deny udp src DMZ:10.10.31.7/2034 dst inside:10.10.2.28/161 by access-group "DMZ_inf_in

I am unable to connect to the sql box from the inside network.

Thanks for you help

rsmith · ‎08-23-2005

Your error message indicates that the DMZ has an IP address of 10.10.31.7 (is this your test web server?) trying to access the inside address 10.10.2.28. Your DMZ translation has an IP address of 172.16.10.250. Are your inside and DMZ network overlapping? If this does not help, please post your config, and sample log entries.

petersontom · ‎08-23-2005

I'm sorry for the confusion.

The DMZ ip address 172.16.10.250 (Web server)

SQl Server 10.10.2.8 (Inside network)

The address 10.10.31.7 is a workstation on the inside network pinging the SQl server.

Here is the access-list for the web server to access the sql server.

access-list DMZ_inf_in permit tcp host 172.16.10.250 eq 1433 host 10.10.2.28 eq 1433

Here is the static NAT

static (inside,DMZ) 10.10.2.28 10.10.2.28 netmask 255.255.255.255 0 0

Once I add this the SQL server becomes unreachable from any workstation on the inside address (10.10.x.x) ,however the web server in the DMZ can still access the SQL server.

petersontom · ‎08-23-2005

I'm sorry for the confusion.

The DMZ ip address 172.16.10.250 (Web server)

SQl Server 10.10.2.8 (Inside network)

The address 10.10.31.7 is a workstation on the inside network pinging the SQl server.

Here is the access-list for the web server to access the sql server.

access-list DMZ_inf_in permit tcp host 172.16.10.250 eq 1433 host 10.10.2.28 eq 1433

Here is the static NAT

static (inside,DMZ) 10.10.2.28 10.10.2.28 netmask 255.255.255.255 0 0

Once I add this the SQL server becomes unreachable from any workstation on the inside address (10.10.x.x) ,however the web server in the DMZ can still access the SQL server.

rsmith · ‎08-23-2005

There may be a problem with your physical setup of your DMZ interface, possibly connected directly to your inside network. The log entry you posted:

Deny udp src DMZ:10.10.31.7/2034 dst inside:10.10.2.28/161 by access-group "DMZ_inf_in

shows the source interface (DMZ) for the 10.10.31.7 address, which you say is your inside workstation. Since it is trying to go from your DMZ to the inside (lower to higher) it will be denied unless you have an acl entry to allow access. The web server is getting access since you put the acl entry for that IP.

petersontom · ‎08-23-2005

Thank you for your thoughts. However, I have other devices in the DMZ access our internal network without issues. Is there a fix up protocol I'm might be missing? It seems to be the static NAT causing the current issue.

rsmith · ‎08-23-2005

hmmm. I am still curious why the log file showed your udp denied coming from the DMZ interface, when it is an inside device.....

As to your static, do you use NAT 0 for all your access? (no translation to a DMZ address?) Could you post more log information when this fails, and possibly the config of the Firewall?

petersontom · ‎08-23-2005

Company policy will not allow me to post the config, I contacted Cisco they wanted the access-list changed to:

access-list DMZ_inf_in permit tcp host 172.16.10.250 host 10.10.2.28 eq 1433

I did this and I still have the problem. here are some trap logs:

Deny tcp src DMZ:10.10.10.59/2148 dst inside:10.10.2.28/80 by access-group "DMZ_inf_in"

Deny tcp src DMZ:10.10.10.231/2222 dst inside:10.10.2.28/80 by access-group "DMZ_inf_in"

Deny tcp src DMZ:10.10.10.29/1980 dst inside:10.10.2.28/80 by access-group "DMZ_inf_in"

All these machines are on the internal network.

As soon as I remove the access-list I am able to ping/connect to the SQL server. I cannot explain this either. I can get the PIX config posted but will take me awhile to remove private info.

Thank for the help.

rsmith · ‎08-24-2005

Hopefully you can get that cleaned and posted soon. I still keep going back to the log entries; since the Source interface for your Internal clients (10.10.10.x) is showing as the DMZ, attempting to access the inside (due to the static translation), it seems your DMZ and inside physical connections 'may be' reversed? Other than that, it will take a closer look at the config to see what is going on...

petersontom · ‎08-24-2005

Here is a very stripped version of the config

PIX Version 6.1(4)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security50

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 1720

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000

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

access-list outside_inf_in permit tcp any host x.x.x.x eq pop3

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

access-list DMZ_inf_in permit tcp host 172.16.10.250 eq 1433 host 10.10.2.28 eq 1433

access-list DMZ_inf_in permit tcp host 172.16.10.x eq 1433 host 10.10.2.28 eq 1433

access-list DMZ_inf_in permit tcp host 172.16.10.x host 10.10.x.x eq smtp

access-list DMZ_inf_in permit tcp host 172.16.10.x any eq www

access-list DMZ_inf_in permit tcp host 172.16.10.x any eq 443

access-list DMZ_inf_in permit udp host 172.16.10.x any eq domain

access-list DMZ_inf_in deny icmp any any

access-list DMZ_inf_in permit udp host 172.16.10.x any eq domain

access-list DMZ_inf_in permit tcp host 172.16.10.x any eq www

logging trap warnings

logging history warnings

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

ip address outside x.x.x.x 255.255.255.0

ip address inside 10.10.x.x 255.0.0.0

ip address DMZ 172.16.10.x 255.255.255.0

ip verify reverse-path interface outside

ip audit info action alarm

global (outside) 1 interface

global (DMZ) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat (DMZ) 1 0.0.0.0 0.0.0.0 0 0

static (DMZ,outside) x.x.x.x 172.16.10.x netmask 255.255.255.255 0 0

static (inside,outside) x.x.x.x 10.10.x.x netmask 255.255.255.255 0 0

static (inside,DMZ) 172.16.10.x 10.10.x.x netmask 255.255.255.255 0 0

static (DMZ,outside) x.x.x.x 172.16.10.x netmask 255.255.255.255 0 0

static (inside,outside) x.x.x.x 10.10.x.x netmask 255.255.255.255 0 0

access-group outside_inf_in in interface outside

access-group DMZ_inf_in in interface DMZ

route outside 0.0.0.0 0.0.0.0 x.x.x.x 1

route DMZ x.x.x.x 255.255.255.255 172.16.10.x 1

route outside x.x.x.x 255.255.254.0 x.x.x.x 1

route inside x.x.x.x 255.255.255.0 10.10.x.x 1

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

no sysopt route dnat

petersontom · ‎08-25-2005

Okay, I found the problem. Unbelievable, one of our network administrators had mistakly plugged in a network cable from the DMZ switch to the internal LAN switch. Thank you for all your help.

rsmith · ‎08-25-2005

Great that you found the issue. Please rate my post if you think they were helpful.