Front end Web access can't talk to back end

[Jean Paul Enerst]

Hi all,

        I have two servers, one is in the inside network and the other one is in a DMZ. Both servers can ping each other. The server in the inside(10.x.x.10) is the sql DB which will be moved on its own dmz. The other server is the front end customer web portal, it is already on the dmz, let'say dmz30(192.168.30.12). Both servers can ping each other,but the dmz30 server can't access the back end SQL DB. I have an ACL in the dzm30 permit access to the inside server. I am not a server guy and I don't have access to any of the server, just rely on what the server guys tell me.ASDM Packet tracer shows that the packet is permited.

There is partial configuration:

access-list DMZ30_access_in extended permit object-group TCPUDP DMZ30-Network 255.255.255.0 trans-Server-VLAN 255.255.255.0 eq 1433
interface Ethernet0/1
speed 100
duplex full
nameif inside
security-level 100
ip address 10.1xx.0.2 255.255.255.0
!
interface Ethernet0/2
  speed 100
duplex full
nameif DMZ30
security-level 90
ip address 10.1xx.30.1 255.255.255.0
!

Thanks,

Jean Paul

[Jennifer Halim]

Base on the packet tracer output, the connection seems to pass through the firewall just fine.

Are you able to telnet on port 1433 from the web server to the sql server? If you can, then it looks like it's an application issue with sql.

Does it require any other ports to be opened except TCP/1433?

[Jean Paul Enerst]

Hi Jenn,

              I only have port 1433 opens for now,but for testing purposes I can permit all tcp/ip for a few hours. As i said above, I do not have access to any of the two mentioned servers;therefore, I have to rely on the server guys to make some test on the server. And God knows how many times they make me over work. I was wondering if there any other troubleshooting tool that i can use right from the FW to prove that the packets do leave the FW. Packet capure does show the packet get to the back end server as well.

The fun thing is, i got it working a few months a few, just before they have a complete server outage!!

Thanks,

Jean Paul

[Jennifer Halim]

If the packet capture is showing that the packet is actually sent to the server, then i don't think it is a firewall issue, especially if they have a server outage earlier.

You can try to "clear xlate" on the ASA and re-test the connection again and see if it works after. If it works after, that means that there might be a stale xlate entries and the server is trying to connect using the previous connections and fails. If after clearing the xlate, it is still not working, then it definitely looks like application (server) issue.