Forum Discussion
Heidi_35827
Nimbostratus
NimbostratuscURL 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
richard_77048It 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- nitass
Employee
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 --------------------------------------------------------------- 
Heidi_35827Thanks 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??- Heidi_35827We 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.
