Forum Discussion

Heidi_35827's avatar
Heidi_35827
Icon for Nimbostratus rankNimbostratus
Aug 02, 2012

cURL to the VIP, can we do that?

We have a basic port 80 VIP. Very simple. VIP is on port 80, 2 real servers behind it on port 8084.

 

 

My customer has some DOS-based devices that need to submit info to this VIP via cURL, no browser. It is not working. The browser-based systems that submit the same request, work fine.

 

 

The VIP is up and healthy but there must be something different in how the cURL command is sent or received by the BigIP vs the browser. Do we need to flip any special switches on cURL statement to make this work?

 

 

We did some TCPdumps and from the browser request (which works) we see, syn, syn-ack, ack, then the HTML request, followed by the HTML content, etc.

 

 

When we send the cURL (which doesn't work), we see syn, syn-ack, ack then that is it. The next packet should be the HTML request from the client to the server but it is never sent.

 

 

Packets make it on both sides of the BigIP per the tcpdump, nothing getting dropped.

 

 

One other tidbit - We can send the exact same cURL to the 'real' server behind the BigIP (specifying port 8084) and it works.

 

 

I hope that is all clear as mud. Any ideas? I'd appreciate any help.

 

4 Replies

  • It sounds like you were sniffing traffic on the BigIP. Did you try sniffing traffic on the server? Does the traffic look any different.

     

    Is there anything showing up in /var/log/ltm on the BigIP?

     

    Try using an irule to log the request headers and compare the curl requests and requests coming through the browser.

     

     

    Finally, I would try making the request from the DOS-based device using telnet (assuming it's available to you) and do all the same testing.

     

     

    I test VIPs using wget/curl and telnet/netcat and haven't run into any issues like you are describing.

     

     

    HTH

     

     

    Richard
  • this is mine.

    [root@ve10:Active] config  b virtual bar list
    virtual bar {
       snat automap
       pool foo
       destination 172.28.19.79:80
       ip protocol 6
       profiles {
          http {}
          tcp {}
       }
    }
    [root@ve10:Active] config  b pool foo list
    pool foo {
       members 200.200.200.101:8084 {}
    }
    
    [root@ve10:Active] config  ssldump -Aed -nni 0.0 port 80 or port 8084
    New TCP connection 1: 172.28.19.251(42473) <-> 172.28.19.79(80)
    1343999070.4086 (0.0012)  C>S
    ---------------------------------------------------------------
    HEAD / HTTP/1.1
    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
    Host: 172.28.19.79
    Accept: */*
    
    ---------------------------------------------------------------
    
    New TCP connection 2: 200.200.200.10(42473) <-> 200.200.200.101(8084)
    1343999070.4094 (0.0007)  C>S
    ---------------------------------------------------------------
    HEAD / HTTP/1.1
    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
    Host: 172.28.19.79
    Accept: */*
    
    ---------------------------------------------------------------
    
    1343999070.4113 (0.0018)  S>C
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Date: Fri, 03 Aug 2012 13:17:52 GMT
    Server: Apache/2.2.3 (CentOS)
    Last-Modified: Fri, 11 Nov 2011 14:48:14 GMT
    ETag: "4183e4-3e-9c564780"
    Accept-Ranges: bytes
    Content-Length: 62
    Content-Type: text/html; charset=UTF-8
    
    ---------------------------------------------------------------
    
    1343999070.4113 (0.0027)  S>C
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Date: Fri, 03 Aug 2012 13:17:52 GMT
    Server: Apache/2.2.3 (CentOS)
    Last-Modified: Fri, 11 Nov 2011 14:48:14 GMT
    ETag: "4183e4-3e-9c564780"
    Accept-Ranges: bytes
    Content-Length: 62
    Content-Type: text/html; charset=UTF-8
    
    ---------------------------------------------------------------
    
  • Thanks for the feedback.

     

     

    We believe this is more likely a arp/routing issue. But still strange. Why can the browser packet get there, but not the cURL?

     

     

    This is what the infrastructure looks like:

     

     

    client ---------- router ---------------- firewall ------------ F5 ----------- servers

     

     

     

    Tcpdump from client shows with his cURL - ack, syn-ack, ack, HTTP GET....wait.....retransmit HTTP GET

     

     

    On a capture at the firewall, we see - ack, syn-ack, ack.

     

    The HTTP GET never gets there.

     

     

    But why? From the same laptop we can send the same HTTP request with a browser, and it makes it there and back. Somewhere the cURL HTTP is gets lost. And how does ACK get there and HTTP can't? The routing looks good from his subnet to DMZ, I traced it hop by hop. We would have many more issues if that were broken.

     

     

    MAC/ARP issue possibly? But how would the browser call ever work if that were the case??

     

     

     

  • We finally got to the bottom of this today. Thanks for all the suggestions.

     

     

    IPS was the culprit. Tipping Point between the router and the firewall. I didn't realize it lived there but scrutinizing every packet at every hop, we found it. Our Security guy just confirmed it is blocking the cURL.