SNAT pool and persistence
Hi all! I have a LTM-setup (10.0.1) with a SNAT Pool containing 5 ip addresses. So each connection uses the next SNAT address (round robin). But for persistent connections (source persistence), i'd like the LTM to use always the same SNAT address, and not to change it during the session. Otherwise some of my applications have problems with session management... Is there a way to configure the SNAT pool in a way that persistent connection always keep their SNAT address? Thanking you in anticipation, regards Marc
Pool member connection
Hi All, we have 5 pool memebr . That pool attach to Virtual server.and Loadbalancing method is round Robin I am getting connection to multilple source. i want to identify particular source is hitting to Wich Pool member with current connection. HOW can i achieve this ? Thanks & Regards Ankush narangBIG-IP : iControl API failure to retrieve system configuration file
BIG-IP 11.4.1 Build 635.0 Hotfix HF2 We have a C service that on a schedule performs a "health ping" of our BIG-IP devices by calling iControl API to retrieve the system configuration file : SystemConfigSync.download_file("/config/bigip.conf", ... ) If exception is thrown (or blank config retrieved), the service will trigger an alert. Once a subsequent retrieve sys config succeeds, the alert is cancelled. This service has been operational in production for over one year -- with no alerts. However, over the past 4 days we've seen alerts firing frequently. Day 1 was the peak of a period of extraordinary site traffic that placed record load on our devices, however the peak dropped off drastically near end of day 1 and days 2,3,4 were normal traffic. Logs reveal three distinct types of errors : ERROR : SystemConfigSync.download_file() threw exception [Client found response content type of 'text/html; charset=iso-8859-1', but expected 'text/xml'.] ERROR : SystemConfigSync.download_file() threw exception [The underlying connection was closed: An unexpected error occurred on a receive.] ERROR : SystemConfigSync.download_file() threw exception [The request failed with HTTP status 401: F5 Authorization Required.] The text/html errors are by far the most common, followed by connection-closed : both of these types of errors are ongoing. The auth errors occurred infrequently over the initial two days and then stopped completely. What are some possible BIG-IP factors that could be contributing to iControl API failures to retrieve sys config file ? Could it be load related ( even though that doesn't match-up with day 2,3,4 ) ? Are there any config settings that could be contributing ? Also, what determines the text format returned by SystemConfigSync.download_file() ?
Health monitors - XML API
Hi, I'm trying to write a health monitor that sends an XML string, in order to receive some specific information. I've successfuly been able to replicate the query using cURL by replicating catured live, working traffic. However when I attempt to duplicate this into a health monitor I get a HTTP 400 Bad Request message: This curl statement works and results in the output that follows, what is curious is that the first attempt fails with an authentication error but curl seems to try again and works. (some sensitive information has been removed) curl -N -v \ -H 'Connection: Keep-Alive' \ -H 'Content-Type: text/xml; charset=utf-8' \ -H 'SOAPAction: "urn:domain-name.co.uk/service/check/Test"' \ --ntlm \ -u 'username:password' \ -d '' \ http://172.21.42.40:9003/service/check/11?wsdl POST /Service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAA= 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.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 0 HTTP/1.1 401 Unauthorized Content-Length: 0 Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: NTLM EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Date: Thu, 14 Feb 2013 16:06:16 GMT POST /service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== 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.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 154 HTTP/1.1 200 OK Content-Length: 428 Content-Type: text/xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 14 Feb 2013 16:06:16 GMT 9ecb118c-486c-4581-afda-0b59d367ed7e2013-02-14T16:06:10.42 The following is the equivilent health monitor of the above curl statement, originally this errored as the header value Content-Length was missing. I added this manually with values of both 0 and 154 but each time monitor errors. From looking at a capture of the monitor the POST request appears to be identical to the working curl one Monitor (actual carriage return entered for clarity) monitor TEST_MON { defaults from http recv "" send POST /service/check/11?wsdl HTTP/1.1\r\n Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\r\n Host: 172.21.42.40:9003\r\nAccept: */*\r\n Connection: Keep-Alive\r\n Content-Type: text/xml; charset=utf-8\r\n SOAPAction: \"urn:domain-name.co.uk/service/check/Test\"\r\n Content-Length: 154\r\n\r\n } results in the following POST /service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== Host: 172.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 154 HTTP/1.1 400 Bad Request Content-Length: 0 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 14 Feb 2013 16:53:01 GMT Changing the content-length to 0 produces the following output HTTP/1.1 400 Bad Request Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Fri, 15 Feb 2013 09:49:09 GMT Connection: close Content-Length: 326 Bad Request Bad Request - Invalid Verb HTTP Error 400. The request verb is invalid.
Health monitors - XML API
Hi, I'm trying to write a health monitor that sends an XML string, in order to receive some specific information. I've successfuly been able to replicate the query using cURL by replicating catured live, working traffic. However when I attempt to duplicate this into a health monitor I get a HTTP 400 Bad Request message: This curl statement works and results in the output that follows, what is curious is that the first attempt fails with an authentication error but curl seems to try again and works. (some sensitive information has been removed) curl -N -v \ -H 'Connection: Keep-Alive' \ -H 'Content-Type: text/xml; charset=utf-8' \ -H 'SOAPAction: "urn:domain-name.co.uk/service/check/Test"' \ --ntlm \ -u 'username:password' \ -d '' \ http://172.21.42.40:9003/service/check/11?wsdl POST /Service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAA= 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.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 0 HTTP/1.1 401 Unauthorized Content-Length: 0 Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: NTLM EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Date: Thu, 14 Feb 2013 16:06:16 GMT POST /service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== 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.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 154 HTTP/1.1 200 OK Content-Length: 428 Content-Type: text/xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 14 Feb 2013 16:06:16 GMT 9ecb118c-486c-4581-afda-0b59d367ed7e2013-02-14T16:06:10.42 The following is the equivilent health monitor of the above curl statement, originally this errored as the header value Content-Length was missing. I added this manually with values of both 0 and 154 but each time monitor errors. From looking at a capture of the monitor the POST request appears to be identical to the working curl one Monitor (actual carriage return entered for clarity) monitor TEST_MON { defaults from http recv "" send POST /service/check/11?wsdl HTTP/1.1\r\n Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\r\n Host: 172.21.42.40:9003\r\nAccept: */*\r\n Connection: Keep-Alive\r\n Content-Type: text/xml; charset=utf-8\r\n SOAPAction: \"urn:domain-name.co.uk/service/check/Test\"\r\n Content-Length: 154\r\n\r\n } results in the following POST /service/check/11?wsdl HTTP/1.1 Authorization: NTLM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== Host: 172.21.42.40:9003 Accept: */* Connection: Keep-Alive Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:domain-name.co.uk/service/check/Test" Content-Length: 154 HTTP/1.1 400 Bad Request Content-Length: 0 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 14 Feb 2013 16:53:01 GMT Changing the content-length to 0 produces the following output HTTP/1.1 400 Bad Request Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Fri, 15 Feb 2013 09:49:09 GMT Connection: close Content-Length: 326 Bad Request Bad Request - Invalid Verb HTTP Error 400. The request verb is invalid.
Problem talking to VIP from Internal Node
My apologies if this is the wrong group for this question. Our somewhat simplified configuration: +-----------------------------------------------+ +--------------------------------+ | | | | | VLAN101 | | VLAN102 | | | | | | | | | | VIP-64.100 VIP-64.101 VIP-64.102 | |VIP-72.100 VIP-72.101 | +-----+>--------------^-----------------^-------+ +--------------------------------+ |Self-IP |Self-IP |Self-IP ^ ^ |64.10/11 |64.10/11 |64.10/11 |Self-IP |Self-IP | | | |72.10/11 |72.10/11 |SNAT | SNAT |SNAT | | | | | |SNAT |SNAT | | | | | +----+----+ +-------+-----+ +-------+------+ +-----+-------+ +-------+------+ |VLAN2000 | |VLAN2001 | |VLAN2002 | |VLAN2010 | |VLAN2011 | | | | | | | | | | | |192.x.y.z| |192.x.y2.z | |192.x.y3.z | |192.x.y4.z | |192.x.y5.z | +----+----+ +------+------+ +------+-------+ +-----+-------+ +------+-------+ | | | | | | | | | | +---v----+ +----v------+ +-----v------+ +-----v-------+ +------v--------+ | | | | | | | | | | | Node1 | | Node2 | | Node3 | | Node4 | | Node5 | | | | | | | | | | | +--------+ +-----------+ +------------+ +-------------+ +---------------+ We have multiple VIPs configured where each group of VIPs all share a single VLAN on the top/external side (e.g. 172.x.y.z/21). The bottom/internal side of each VIP has its own VLAN (192.168.x.y/28). SNAT is configured to translate each of the internal VLANs out to either the single Self-IP for VLAN101 or VLAN102 (really 2 since one is fixed and the other floating -- eventually we'll hook up the second F5 for failover). Each of the internal VLANs has a specific translation rule to translate it's internal IP range out to the external Self-IP. We don't have it configured with automap. In addition to the above, we have route-domains defined. RD101 is the route domain for VLAN101. RD102 is the route domain for VLAN102 There is a route domain for each of the bottom VLANs (RD2000, RD2001, etc) whose parent is either RD101 or RD102. Our problem is communicating from the internal nodes directly to the VIPs within a group. Nodes 1,2 or 3 which SNAT out to the Self-IP in VLAN101 are unable to establish connections to any of the VIPs in VLAN101. They are able to connect to the VIPs in VLAN102. If I run tcpdump on VLAN101 on the F5, I see the F5 trying to ARP for the address of the VIP (e.g. ARP: tell 172.16.64.11 the Mac of 172.16.64.100). Since the Self-IPs and the VIP addresses are part of the same VLAN (VLAN101), shouldn't the F5 be able to talk directly between the Self-IP and the VIP? Here's an example of the kind of tcpdump out we are seeing: 23:51:05.138541 arp who-has 172.24.73.1 tell 172.24.72.11 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=2 inport=0 haunit=0 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0 Any help would be greatly appreciated. Thanks, barryAPM used for Mobile Authentication
I am not sure if this is the right forum to ask this question but I will ask it anyways. Lately, I had been doing some research on Mobile Authentication mechanism and saw a great developer guide from Google on this subject. https://developers.google.com/accounts/docs/MobileApps In this article, it talks about using either OpenID or SAML protocol for authenticating, how to get the token from the HTTP response and how to use it to secure API calls for the enterprise. Now, I know that since F5 platform version 11.3 and up, the APM module now supports the SAML protocol. Has anyone tried to use F5 APM product in conjunction with the technique that Google Developer site had posted? If there is, is there a published article on this in the F5 Dev Central? Also, if no one has done this before, can this be done? I am particularly concern especially as the article mentions items which I am not sure if it can be done through F5 APM which are: -Using the APM Authentication Cookie as a Security Token -Setting the cookie name as well-known name such as auth_token after authentication to issue the token -Passing the token as a HTTP header parameter rather than as a cookie parameter when the mobile client is executing API calls -Validating that the token can only be used in API calls and not for web application browsing. -Ensuring that the token doesn't have the typical short lifespan (e.g. 30 mins) of a browser session - it only expires when it is manually revoked or the user's password has been changed Any thoughts and feedback on this matter would be great. Thank you.
Emulate v4.5 SNAT behavior with 10.x
I'm trying to emulate BIGIP 4.5 SNAT behavior for a set of legacy hosts that are being migrated from a 4.5 bigip box to a 10.x BigIP LTM. With a 4.5 SNAT things work as follows: All connections that the server initiates outbound using the bigIP as it's default gateway are SNATed to the snat IP. All connections inbound to the server, initiated by a client, say an admin ssh'ing into the server, are simply forwarded without any NAT/SNAT. (this would be an asymmetrical flow, bigip only sees half the connection.) In 10.2.1 I've created an irule and forwarding server (see below) that SNATs connections from a 'legacy server' data class. However, currently the 10.x BigIP SNATs everything it sees... This includes flows that it never saw an initial SYN for... For example, if you ssh into a server, you have asymmetrical routing, so all packets from the ssh client go router -> server, while the return path is server -> bigip -> router. This prevents ssh'ing into the box as a 3way handshake is never established, the ssh client sends a SYN which reaches the server, the server replies next-hoping the syn/ack to the bigip. The bigIP then SNATs the connection before sending it to the router, which of course prevents the 3way handshake. Some detailed information and diagrams of what's going on, as well as my current irule and forwarding server configuration. VLAN205 = Servers, 10.10.205.0/24 VLAN210 = VIPS, 10.10.210.0/24 Default Gateway for BIG-IP Route Domain: Router interface on VLAN 210. Default Gateway for Servers: Big-IP Interface on VLAN 205. +-----------------------+ | | | VIP VLAN 210 | | 10.10.210.0/24 | | | +-----+--------------+--+ | | | | +--------------+--+ +-+--------------+ | | | | | BIG-IP | | Router | | | | | +--------------+--+ +-+--------------+ | | | | +-----+--------------+---+ | | | SERVER VLAN 205 | | 10.10.205.0/24 | | | +----------+-----------+-+ | | | | +-----+--+ +-+-------+ | | | | | Server | | Server | | | | | +--------+ +---------+ class legacy_servers { { host 10.10.205.103 host 10.10.205.104 } } rule SNAT-TEST-RULE-1 { when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals "legacy_servers"] && ( [IP::protocol] == 6 || [IP::protocol] == 17 ) } { log local0. "==============================================================" log local0. "SNAT'ed Legacy Server: [IP::client_addr] to 10.10.210.50" log local0. "IP::client_addr: [IP::client_addr]" log local0. "IP::local_addr: [IP::local_addr]" log local0. "IP::remote_addr: [IP::remote_addr]" log local0. "IP::protocol: [IP::protocol]" snat 10.10.210.50 } } } profile fastL4 route_friendly_fastl4 { defaults from fastL4 loose initiation enable loose close enable } virtual VS-FORWARD-RD0 { ip forward destination any:any mask 0.0.0.0 rules { SNAT-TEST-RULE-1 } profiles route_friendly_fastl4 {} vlans { VLAN205 } enable }
