ASA not allowing OWA traffic

[scottwclarke]

Hi I have 3 5505 that all have very similar "quirks".

The device has been working normally for the last few months then suddenly decide not to allow owa traffic through, however a second site which we use to collect xml from our clients is working fine. I have resarted and cleared the translates but it hasn't helped any advice would be greatfully recieved.

[srue]

is OWA accessed via 80 or 443? can OWA be accesses from an internal client?

also, your ACL should be more specific..

for example, why are you allowing smtp to any host internally.?

[scottwclarke]

OWA is on 80 at the clients request

OWA can be accessed from any machine internally

we are controlling where traffic goes via PAT

I can tighten the rules up though if you think it would help

Thanks for the quick reply.

[srue]

and you've made sure the IP address is correct in the following entry:

static (inside,outside) tcp interface www x.x.x.x www

Can you telnet to port 80 from the outside? Check your IIS server where OWA resides, and make sure you don't have restrictions on who can access OWA. By the way, what type type of error are you getting when you try to access it from the outside?

[scottwclarke]

Yep the IP is correct, the problem seems to come and go, and even when I can't access owa I can access the monitoring site on the same server.

The error is page can not be diplayed.

I have also experienced this problem of only working sometimes with Remote Desktop exactly the same symptoms and roughly the same config.

[srue]

what license do you have for you ASA5505?

This does not look like a config issue.

[jojuarez]

Hi,

You need to run traffic captures to see what's going on. Configuration seems to be ok as you say sometimes works and sometimes not.

It's recommendable to narrow down the captures by matching only the interesting traffic. Let's suppose the public IP of the server (which uses port 80) is 60.1.1.1 whereas the private is 192.168.1.1 and that user testing from the outside has IP 70.1.1.1:

access-l capout permit tcp host 70.1.1.1 host 60.1.1.1 eq 80

access-l capout permit tcp host 60.1.1.1 eq 80 host 70.1.1.1

access-l capin permit tcp host 70.1.1.1 host 192.168.1.1 eq 80

access-l capin permit tcp host 192.168.1.1 eq 80 host 70.1.1.1

capture capin access-l capin int inside packet 1522

capture capout access-l capout int outside packet 1522

Once the above is configured, try to access to the server and then do a "sh cap capin" and "sh cap capout" or you can retrive them in pcap files by accessing to ASDM:

https:///capture/capin/pcap

https:///capture/capout/pcap

You can check the files using ethereal or any other similar software. In this way you'll be able to determine whether the firewall is dropping the traffic or not. Although it's pretty likely it's not a fw issue, you can check the flags of the TCP packets, perhaps some R or F flags are being sent by the server. You can also run some logs.