PIX 515E slow http from inside to dmz network

[kvoelker2000]

                  I have a PIX 515E V7.0.4 and I'm having trouble with http access between the inside interface and a DMZ zone I have.  I have a web server setup in the DMZ with an web interface to upload/download files.  I can connect to this interface from a workstation in the inside network but when I try to download a file it is incredibly slow.  If I upload a file there are no speed issues.  If I connect using an https connection then both upload and downloads are at speeds I would expect.

I have disabled http inspect but this didn't improve the speed connection.

Other http communications from inside to outside do not have any speed issues in either direction.

Any thoughts or suggestions appreciated.

Thanks,

Karl

[kvoelker2000]

Hi,

I went to run the captures you wanted but the commands aren't recognized,  I don't think it likes the "match" command.  I will try to get those captures run but here is the running config from my PIX. 

Thanks,

Karl

[Julio Carvajal]

Hello,

Got it, yes, that's because of the version you are running.

You will need to do it with an ACL instead of a match.

Regards.

Julio

[kvoelker2000]

              HI,

OK so I got the capture syntax and attached is the capture from the hosts on the DMZ interface.  The capture on the inside interface did not collect any packets which was odd, upload or download and I used the same access-list.     

I'll keep trying to get a capture on the inside interface.

Karl

[Julio Carvajal]

Hello,

Can you share the NAT you are using from the internal interface when going to the DMZ server and?

Do you have any NAT from DMZ when going to inside

What is between the ASA and the HTTP server on the DMZ?

Regards,

[kvoelker2000]

The NAT I have between the inside and DMZ network is one to one.  Private addresses in the inside net translate to those same addresses in the DMZ and vice versa.

The server in the DMZ zone, 192.168.2.37, is a public facing server so it's public address is translated to the inside network so the machines in the inside net access it via it's public address. 

Nothing is in between the HTTP server and the PIX.  Both the inside network and DMZ are connected directly to the PIX.  The DMZ network is on a VLAN on a seperate switch.

Hopefully this makes sense.

Karl

[Julio Carvajal]

static (inside,Audiovault-DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

static (Audiovault-DMZ,inside) xxx.xxx.xxx..37 Remote_Server

The last one is the one from the DMZ server to Inside right?

You are not seeing the traffic on the inside interface because it should point to the public, so please create the captures again

access-list capin match tcp host inside_host host public_ip_dmz_server eq 80

access-list capin  match tcp host public_ip_dmz_server eq 80 host inside_host

access-list capdmz match tcp host inside_host host 192.168.2.37 eq 80

access-list capdmz match tcp host 192.168.2.37 eq 80 host inside_host

capture capin interface inside access-list capin

capture capdmz interface dmz access-list capdmz

Then generate an HTTP request and upload the resulting captures.

Remember to rate all of the answers, that is why the community is here  ( to know that we can help, if you do not know how to rate a post let me know)

Regards,

[kvoelker2000]

Hi Julio,

OK, I know have a capture for both interfaces.....didn't think of adding the public IP address in the access list.

Did an upload and download to the server in the DMZ and attached both capture files.  More information than the captures I got from the local machine so I'm curious to see what you think.

Thanks for your help.

Karl

[Julio Carvajal]

Hello,

Great jobs with the captures

I am checking them.

I will keep you post

Results of the analisys:

After changing the way wireshark shows the date and time I could detect that for a packet to traverse the PIX takes around 300 microseconds ( so based on that the PIX is no causing any delays to the traffic) he is just allow them, no inspection add it, no overhead.

Everything looks fine until packet number 2802 on the capin ( the first duplicate packet of 45 of them). On the DMZ capture we can see the same behavior ( 2802 first duplicate of 45)

The interesting part is that the client sends the same duplicate packet ( for the same segment) 44 times until it receives a replay.

So that let us know that there are some packets getting lost between this 2 guys, that is why I asked before what is in between,

Is there a way you could setup a capture between the Outside and DMZ. You will need to build a different pair of ACL's for this ones but that will show us if the big amount of duplicate packets are normal on your network ( witch I do not think so)

Hope this helps...

[kvoelker2000]

Hi,

Thanks for the update and looking at the captures.  I will try try to setup the capture on the outside interface and upload the results.

The strange part is that if I run the same application using a secure https connection then there are no speed issues and I assume no duplicate packets.  This is why I thought the PIX might be doing some inspection or buffering and casuing the speed issues.  Under https it would not be able to do inspection and would most likely just forward them along. 

I appreciate your help with this.

[Julio Carvajal]

Hello,

Not at all, I mean if we see thes re-transmission on just one interface I will agree with you but we are seeing them on both interfaces, There is nothing being done on the PIX related to the HTTP protocol.

[kvoelker2000]

Hi,

I ran a capture of an upload and download monitoring the outside interface.  Does not seem to have the same amount of errors at all.  Not sure what to amke of it at this point.  If the PIX isn't doing any filtering than I'm not sure where the problem would be.  Again I'm confused as to why if I run in in https I don't have any speed issues at all.  I figured if it was a switching issue I would have problems regardless of http or https.

Thanks again for your help and I'm curious what you think might be the issue.

Karl

[Julio Carvajal]

Hello,

So as you could see there is something happening in your network.

Okay what is the difference between one traffic flow and the other ( I mean from inside to DMZ and outside to DMZ)

Lets try to determine all the devices in between

[kvoelker2000]

Hi,

The three interfaces we have captured are connected as follows:

Inside interface - Connected to Cisco 3560G 48TS switch

Outside interface - Connected to 3Com Superstack 3300

DMZ interface - Connected to 3Com Superstack 3300

The PIX interfaces are set to  100MB Full Duplex

The inside interface port on the Cisco 3560G is set to 100MB Full duplex

The 3Com switch ports for the outside and DMZ interface are set to 100MB full duplex

For these interfaces I do not have anything connected using auto-negotiate

[Julio Carvajal]

Hello,

Okay so as you can see traffic from outside to DMZ goes through the same switch.

On the other hand traffic traverses 2 switches to reach the destination,

We are getting closer to the solution.

Is there a way you could connect a PC directly to the ASA inside interface ( as a test) and then try to access the HTTP server on dmz). Please try to make that happen

Regards,

[kvoelker2000]

Hi,

I'm not sure if I am going to be able to do this.  It's a production network and we are a 24/7 operation.  For me to take the entire inside network offline will be something I will have to get scheduled and have management approve it.  So if I can do this would I connect a crossover cable to the inside interface?  This seems a but odd but suppose it could be done. 

What's strange is there are two different paths,  outside to DMZ  and inside to dmz, with two different switches and the speed issue is present on both.  The common factor seems to be the PIX.

If I place a machine in the DMZ and connect to the http application then there are no speed issues.  If I tak the server, move it to the inside and have a workstation connect to it upload and download speeds are good.  It only seems to be when I run it through the PIX.  I would have thought this might be a duplex error between the PIX and a switch but I'm not seeing these in errors on either switch.

It's just strange behaivor.