Forum Discussion

d33z_14138's avatar
d33z_14138
Icon for Nimbostratus rankNimbostratus
Dec 18, 2015

HTTP requests to internet web server through Link Controller fail with packet resets

Hello,

 

I have a client that is unable to access an external web site when connecting through a Link Controller. I've narrowed the connectivity issue down to the the Link Controller and have taken packet captures on the LC and client (connected directly behind the LC as well as in front of the LC). The site works fine when connecting to it at any point, except from behind the LC. The Link Controller is setup in an active/passive pair running 11.5.1 Build 5.0.147 HF5 with a default forwarding outbound rule configured (fastl4 with automap) and two internet links. No other complaints connecting to other remote web sites, just this specific one. Sifting through the packet captures, the only thing that stands out on the non-working captures are several TCP retransmissions to the remote server and finally a RST, which is coming from the LC as best as I can tell. The RST packet indicates "/forwarding_outbound PFlow expired (sweeper idle timeout)". I've tried an iRule to bind the outbound requests to the site to one internet link but with no luck. I can attach/upload/screenshot any captures or other info if anyone is interested but this one has me really stumped and I'm running out of ideas and leads to seek or try. Any guidance and help with this issue is greatly appreciated!

 

12 Replies

  • Hi, is it possible to get a 3-way handshake done to the target host or are the observed re-transmissions for SYNs only? How about trying to make a connect by using telnet (just to verify the TCP connect) or using cURL? Thanks, Stephan
  • Sorry, I posted in the answer section, but meant it as a comment. Any ideas what might be going on?
  • Hello,

     

    what is your routing table in the Link Controller?

     

    Do you have a default route via a only one ISP or via a pool of ISPs?

     

    Regards,

     

    • d33z_14138's avatar
      d33z_14138
      Icon for Nimbostratus rankNimbostratus
      Thanks for the response! The LC's routing is configured with a route named "default_route" that has destination and mask set to 0.0.0.0 and references a pool called "default_gateway_pool". That pool consists of two default gateway member nodes which are the two ISP default gateway routers.
  • Hello,

     

    if you change the next hop for the default route being the next hop one of the both ISPs, does it work fine?

     

    Regards,

     

    • d33z_14138's avatar
      d33z_14138
      Icon for Nimbostratus rankNimbostratus
      Are you referring to the Auto Last Hop and Last Hop Pool settings under the "forwarding_outbound" virtual server?
    • fgf_165674's avatar
      fgf_165674
      Icon for Nimbostratus rankNimbostratus
      I refer to the Network -> Routes section, where you define the default route. Not the settings in the Virtual Server
    • d33z_14138's avatar
      d33z_14138
      Icon for Nimbostratus rankNimbostratus
      Not exactly sure if this is what you meant to try on this, but I just tested with only one default gateway address at a time, within the "default_route", rather than using a default_gateway_pool. Same results however...no connectivity to the remote web host from behind the LC. Any other ideas?
  • Hi, beside your tests I also suggest you do a tcpdump on your router to see if packets are properly leaving and coming back to it. If possible you may also try to replace your LC with your test machine giving it the same outside address as the LC just to make sure the router is not the cause of the problem.

     

  • I've come across the solution and it's not on the Link Controller. The web admin of the remote site moved the web server to a new co-lo facility and reconfigured the site but forgot to "white list" our public IP blocks that the clients were connecting from. I'm not exactly sure what security software/hardware is in place at the remote site but it was blocking inbound requests from our public IP blocks after a specific threshold was reached from each source IP. The threshold was not triggered by individual hosts, but when multiple clients initiated requests (behind a PAT), the "security software/hardware" would block the requests.

     

    Thanks, everyone, for your input and assistance with this! After this issue though, I wonder what could've been tested to determine that the issue was on the remote end without input from the remote admin? NMAP? HPING?