Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Strange HTTP behaviour

Hi,

this is my scenario:

- an inside host that tries to login and then access to a network device that is located outside via HTTP.

- if the HTTP communication between inside host and outside network device runs  on an Extranet VPN, it works well.

- if the HTPP communication between inside host and outside network device runs on my Intranet, it fails. In fact the login process is successful but then the host doesn't access to the network device (the web page of network device is based on javascript).

Last situation is very strange.

The "Intranet" communication between inside host and outside network device goes through a Cisco ASA 5540 with sw 8.0(2).

Both the inside and outside interfaces have an ingress ACL that permits all IP traffic.

There is no nat  control.

Inside interface has obviously a greater security level than outside interface.

I notice that:

- the counter "packets dropped" of outside interface increases after the login is succesful

- if I issue che "show asp drop" command, the counter "Flow is denied by configured rule" increases after the login is succesful.

Anyone can help me?

thanks

antonio

  • Firewalling
Everyone's tags (3)
9 REPLIES
Cisco Employee

Re: Strange HTTP behaviour

Don't understand what you mean by "-if the HTTP communication between inside host and outside network  device runs  on an Extranet VPN" compared to Intranet. What is the difference between Extranet VPN and Intranet?

Is there outbound ACL as well?

Can you share the configuration?

New Member

Re: Strange HTTP behaviour

No there aren't any outbound ACL.

AS "Extranet VPN" I mean that I configure a client VPN directly from the inside host to an internet router  that is linked to the network devices that I want to access via HTTP.

So my network devices could be reached via Intranet or via a VPN session between host and another router (cisco 2800).

HTTP communication works only if it runs on a VPN session. If it runs on Intranet, it fails after login process (that is right!).

I attach to this reply the ASA configuration and a capture of the communication between inside host (192.168.8.18) and outside host (10.1.1.132).

I hope that these information are useful.

thanks

antonio

Cisco Employee

Re: Strange HTTP behaviour

Still not too sure how your VPN and where you VPN to?

Also when you say intranet, I assume the traffic flow is as follows:

Inside host (192.168.8.18) -- inside interface (ASA) outsideintranet interface -- outside host (10.1.1.132)

Is the traffic flow and interfaces of the ASA correct?

Can you share the static NAT and NAT/Global pair configuration?

New Member

Re: Strange HTTP behaviour

My VPN is directly from inside host (192.168.8.18) to an router that acts like as a VPN concentrator. The VPN traffic flows through ASA from inside interface to internet interface and viceversa but it is tunneled between host and router.

Your illustration of intranet traffic flows is correct.

Inside host (192.168.8.18) -- inside interface (ASA) outsideintranet  interface -- outside host (10.1.1.132)

ASA is configured with "no nat-control" command.

antonio

Cisco Employee

Re: Strange HTTP behaviour

Ok, so the assumption is nat-control is disabled, and there is no nat statement at all in the configuration.

And also, when it's VPN, traffic is routed to the outside interface instead of the outsideintranet interface, therefore 10.1.1.132 host is routed through the outside as well as the outsideintranet interface. So when it's VPN, I assume that the inside host will be assigned an ip address, and when it's directly connected via the outsideintranet interface, it will be using it's real ip address (192.168.8.18).

If all the above assumptions are correct, on the router connected to ASA outsideintranet interface (as per your configuration: nexthop2 ip address), is there a route statement for 192.168.8.0/24 to be routed towards the ASA outsideintranet interface?

New Member

Re: Strange HTTP behaviour

Your assumptions are correct.

Also on nexthop there is the route to ASA for network 192.168.8.0/24.

From the capture file that I've attached in previous answer, you can notice that communication occurs between the inside host and outside network device.

An important note: I configure the VPN only as a test to identifiy if it is an application problem or an ASA problem.

In daily operation the VPN is down: it is necessary only if my intranet goes down.

I don't understand if there is any TCP flow anomaly that caused the ASA to drop the packet.

As I initiallly wrote I notice:

- some packet dropped on outsideintranet interface

- when I  execute "show asp drop" command, the counter associated to "Flow is denied by configured rule" increases.

thx

antonio

Cisco Employee

Re: Strange HTTP behaviour

You can run packet capture with type asp-drop. It will capture packet which is dropped by the ASA, and you can check if the HTTP packets are somehow being dropped by the ASA for sure.

New Member

Re: Strange HTTP behaviour

This is the log of capture drop

ASA)# show capture asp-drop detail | i 10.1.1.132
948: 15:24:43.013869 0019.e8d3.855a 001b.d5e8.d1b3 0x8100 58: 802.1Q vlan#4 P
0 10.1.1.132.80 > 192.168.8.18.3010: . [tcp sum ok] 2368878:2368878(0) ack 51450
4708 win 9659 (ttl 59, id 25457)

Antonio

Cisco Employee

Re: Strange HTTP behaviour

You would need to grab all 3 packet captures at the same time with mirror image ACL to capture the traffic. From the initial packet capture, you only have 1 direction on each interface. Please capture both direction on both interfaces as well as the asp-drop packet capture at the same time.

Then download the packet capture in pcap format so it can be viewed in wireshark.

644
Views
0
Helpful
9
Replies
This widget could not be displayed.