3620 http Access lists?

[pheidius12]

Hi,

"We are trying to setup NAT on a Cisco 3620 to work with our cable modem.  Currently Ping works by both canonical names and IP address.   However if we try to use HTTP the request times out.  Using Wireshark  it appears that all the HTTP requests end up in a retransmission  loop...data never gets back to requesting host on "inside" network. 

What is confusing to me is that DNS seems to work perfectly.

So do we need to enable a TCP specific access list for HTTP or are we doing something wrong with the existing access lists? 

Please see attached for Show_Version and current router config. 

Any help is appreciated."

[andtoth]

Hi,

The configuration looks fine, however you can remove the following configuration line as it will not match anything because there's no ACL 101 exist:

ip nat inside source list 101 interface Ethernet0/0 overload

There's no need to create a specific ACL for HTTP.

I'm a bit concerned about the full-duplex settings on the interfaces, if the other side (e.g. cable modem) is set to Auto negotiation (auto speed and auto duplex), you should set the router interface to "speed auto" and "duplex auto". Setting different options on the 2 sides can cause problems due to duplexity mismatch, like lost packets.

I have a few questions for you:

- Could you please attach an output of the 'show interfaces' command?

- What do you see in the Wireshark capture for the HTTP traffic?

- Do you see any packets coming back?

- Where are you capturing the traffic?

Andras

[pheidius12]

Hi,

Sorry about the delay in responding as I still am struggling with this issue. The notification of a response to this thread ended up in my spam folder.

In any case, ICMP seems to be moving along ok, but tcip seems squeezed. I did a little housekeeping and am attaching some more files.

Thanks a heap,

[andtoth]

Hi,

I've checked your outputs and the configuration looks fine. Also, I see only a low number of errors on the interfaces which should not affect the HTTP traffic.

Looks like an MTU issue because frames larger than about 1300 bytes are seemingly not received by the workstation. Where did you capture the traffic?

Try pinging with DF (Don't Fragment) bit enabled with a packet size of up to 1500. The settings of packet size depends on the OS as some systems include the IP header in the size, some does not. Try pinging an outside IP with DF set and look what's the largest packet which goes through.

You might try the 'ip tcp adjust-mss' interface configuration command with a value of 1300 or 1200 on the outside (Eth0/0) interface based on the ping test.

Please refer to the following links for more information:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ft_admss.html

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Did you try connecting without the router, by connecting directly to the cable modem?

Do you experience the same symptoms on another workstation with different OS?

Did you try connecting to other websites as well?

Are you experiencing the issue only on HTTP or HTTPS or both?

Andras

[pheidius12]

Hi,

[We captured the traffic with a Mac Book Pro directly connected to the router.  We conducted a ping sweep in two configurations:

Our understanding is that the MBP offloads TCP Checksums to the network interface so that is why WireShark is flagging the Checksum errors but we were able to successfully transmit/receive packets up 1472 bytes.  using the DF, Sweep, and Size options.

We can connect via both a TP-Link Router and Apple Airport Base Station but have not yet tried a direct connecting from Client Computer to Cable modem as the both the Apple Airport and TP-Link router function without any issues

Yes.  We've tried with both PC (Windows XP) and Mac (10.6.5) computers with the same issues

Yes.  We also tried yahoo.  We discovered google apparently has limitations on their ICMP responses, I'm guessing because everyone "pings" them.  So the ICMP responses range from minimum of 26 Bytes to a maximum of 72 bytes.  Yahoo does not exhibit this behavior and we get responses from 9 Bytes to 1472 Bytes without any problem.

We are experiencing the issue on both HTTP and HTTPS

So an overview:

Appeciate your insight.  We originally duplicated the Wifi router WAN port MAC address,  in case the ISP had locked the cable modem to this address.  However,  we subsequently found out that the ISP does not lock the CM to the MAC address so this was unnecessary.  We removed the manually set MAC address and are still experiencing the same issue.

We are currently using a Cable Modem, so there isn't a PPPoE configuration to setup.

Further testing:  We can Ping from 64 to 1472 bytes via setting the ICMP  packet size on both the MAC and PC.  Pings work both directly across  the cable modem and using an Airport Base Station from both the MAC and PC Clients.  Pings also work correctly across the Cisco 3620 router.  Although sometimes it appears there is some additional latency which is odd.

Mac or PC Client <—Directly Connected ---> Cisco 3620 <---Directly Connected ----> Motorola Cable Modem
Mac or PC Client  <—Directly Connected ---> Apple Airport Base Station <---Directly Connected ----> Motorola Cable Modem

In both setups the cables between the points are the same and in the case of the Airport Base Station we also tested via Wifi. 

That said, after additional testing it appears that some web pages do  try to load but is either very slow to load or times out.  I would  expect this kind of pattern if there was a duplex mismatch but after  setting the Speed/Duplex to 10 half on both interfaces and watching the  interface counters....the interfaces are clean.  Meaning no giants or  runts detected on either interface as would be expected with a duplex  mismatch.

We also turned on all possible TCP debugging with no errors.  Show IP  NAT Trans also shows the NAT translations tables being updated.   Lastly  we checked Show Proc CPU and looked for areas of high utilization but  the only process that was using slightly elevated CPU was ARP.  Not sure  if this is normal but ARP was running between 10-13% CPU utilization.

Did a show debug all and watched all the conversations and status  messages for a while so we could buffer them into hyperterminal but  didn't see/find anything significant.

Thanks

[andtoth]

Hi,

Thanks for your detailed reply. At this point I would suggest you to open a Service Request so that you can troubleshoot this together with TAC. The issue seems to be too complex to solve on the forum and also it would be better if a TAC engineer could help you in a remote assistance session.

Andras