Hi guys, We have two APM devices sitting behind individual public IP addresses. Inbound SSL VPN connections are load balanced between these two devices via two GTM's. In summary, we are faced with a situation whereby if a user has an active session to APM device 1 and APM device 1 encounters a failure and goes offline, they are unable to connect to APM device 2 without restarting the Edge Client or waiting between 20 and 30 minutes for the Edge Client to perform a new lookup on the server URL. Here is a run-through of how this works from a user point-of-view: User attempts to connect to f5.mydomain.com via the Edge Client. The TTL for the DNS record is 10 seconds.The Edge Client performs a lookup on f5.mydomain.com and DNS (the GTM's) return one of two public IP addresses. One belonging to APM device 1 and the other belonging to APM device 2. In this example the IP address for APM device 1 is returned.The user successfully authenticates and is assigned full network access.APM device experiences a complete failure. The GTM's acknowledge the failure and all future client requests are directed to APM device 2 only.The user's Edge Client drops the session and attempts to re-establish connectivity but gets stuck in a Downloading server settings/Connecting to server/Waiting to connect cycle.If left for around 20 to 30 minutes the Edge Client connects to APM device 2 and the user establishes a new session. The only other way to kick-start it is to completely shutdown the Edge Client and re-launch it. What I've found is that during step 5, rather than honouring the TTL of the DNS record and therefore re-resolving the f5.mydomain.com DNS name, the Edge Client appears to cache the value found in steps 1 and 2 and reuse it when it tries to reconnect. Note this is not an issue with DNS. Whilst the Edge Client is in its reconnecting cycle described in step 5, normal network tests (ping, nslookup etc.) via the Windows command prompt complete successfully (i.e. resolve to the correct IP of APM device 2). What I'd like to know is: Is this normal/expected behaviour and, if so, what is the reason for that?Is there a way to work around this by modifying something in the client or perhaps a clever DNS workaround that I haven't considered? Any help would be much appreciated! Thanks Peter

This is the normal behaviour. AFIK,the solution for this is a 'Redirect 302' as explained: 1) Need 4 public IP address, and 3 domain names f5.mydomain.com - IP1 (apm1 VS with redirect iRule) apm1.mydomain.com - IP1a(apm1 SSL VPN VS) f5.mydomain.com - IP2 (apm2 VS with with redirect iRule) apm2.mydomain.com - IP2a(apm2 SSL VPN VS) 2) EdgeClient f5.mydomain.com resolves to IP1 or IP2 as per GTM 3) When EdgeClient hit IP1(on apm1), do redirect to apm1.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm1.mydomain.com[HTTP::uri]" } 4) When EdgeClient hit IP2(on apm2), do redirect to apm2.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm2.mydomain.com[HTTP::uri]" } Hope it works for you.

What version of the APM are you running? There was a bug related to this in EDGE client that was fixed in 11.3.0 HF5 and 11.4.0 and above...

@kunjan - Many thanks for your response, I'll look into that. @Michael Koyfman - We're running version 11.4.1 HF3. I don't suppose you have any info relating to the bug (bug ID etc.)?

It's bug id 416115 I was referring to. Strange, it should be addressed in 11.4.1. I suggest opening a case and referencing the issue and perhaps mentioning potential link to 416115 to have support investigate

vandenhoutenp_9

Nimbostratus

Apr 12, 2014

Edge Client (Win) Caches Initial Server URL

Hi guys,

We have two APM devices sitting behind individual public IP addresses. Inbound SSL VPN connections are load balanced between these two devices via two GTM's. In summary, we are faced with a situation whereby if a user has an active session to APM device 1 and APM device 1 encounters a failure and goes offline, they are unable to connect to APM device 2 without restarting the Edge Client or waiting between 20 and 30 minutes for the Edge Client to perform a new lookup on the server URL.

Here is a run-through of how this works from a user point-of-view:

User attempts to connect to f5.mydomain.com via the Edge Client. The TTL for the DNS record is 10 seconds.
The Edge Client performs a lookup on f5.mydomain.com and DNS (the GTM's) return one of two public IP addresses. One belonging to APM device 1 and the other belonging to APM device 2. In this example the IP address for APM device 1 is returned.
The user successfully authenticates and is assigned full network access.
APM device experiences a complete failure. The GTM's acknowledge the failure and all future client requests are directed to APM device 2 only.
The user's Edge Client drops the session and attempts to re-establish connectivity but gets stuck in a Downloading server settings/Connecting to server/Waiting to connect cycle.
If left for around 20 to 30 minutes the Edge Client connects to APM device 2 and the user establishes a new session. The only other way to kick-start it is to completely shutdown the Edge Client and re-launch it. What I've found is that during step 5, rather than honouring the TTL of the DNS record and therefore re-resolving the f5.mydomain.com DNS name, the Edge Client appears to cache the value found in steps 1 and 2 and reuse it when it tries to reconnect.

Note this is not an issue with DNS. Whilst the Edge Client is in its reconnecting cycle described in step 5, normal network tests (ping, nslookup etc.) via the Windows command prompt complete successfully (i.e. resolve to the correct IP of APM device 2).

What I'd like to know is:

Is this normal/expected behaviour and, if so, what is the reason for that?
Is there a way to work around this by modifying something in the client or perhaps a clever DNS workaround that I haven't considered?

Any help would be much appreciated!

Thanks

Peter

application delivery

availability

BIG-IP Access Policy Manager (APM)

12 Replies

kunjan
Nimbostratus
Apr 12, 2014
This is the normal behaviour. AFIK,the solution for this is a 'Redirect 302' as explained: 1) Need 4 public IP address, and 3 domain names f5.mydomain.com - IP1 (apm1 VS with redirect iRule) apm1.mydomain.com - IP1a(apm1 SSL VPN VS) f5.mydomain.com - IP2 (apm2 VS with with redirect iRule) apm2.mydomain.com - IP2a(apm2 SSL VPN VS) 2) EdgeClient f5.mydomain.com resolves to IP1 or IP2 as per GTM 3) When EdgeClient hit IP1(on apm1), do redirect to apm1.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm1.mydomain.com[HTTP::uri]" } 4) When EdgeClient hit IP2(on apm2), do redirect to apm2.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm2.mydomain.com[HTTP::uri]" } Hope it works for you.
- AP
  Nimbostratus
  Aug 04, 2015
  HI Kunjan, Could this be done with only a single IP in each site? For example using a filter to only redirect the initial request. when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { if { [HTTP::host] equals "f5.mydomain.com"} { HTTP::respond 302 Location "https://apm1.mydomain.com[HTTP::uri]" } }
- kunjan
  Nimbostratus
  Aug 04, 2015
  Seems possible. Hope you can test and share the results. BTW, there is doc available now https://f5.com/solutions/deployment-guides/f5-big-ip-gtm-with-apm-for-global-remote-access-big-ip-112-gtm-apm
- AP
  Nimbostratus
  Aug 05, 2015
  Thanks for the feedback. I've read through that deployment guide a few times already. I guess I'll need to lab it. :)
kunjan_118660
Cumulonimbus
Apr 12, 2014
This is the normal behaviour. AFIK,the solution for this is a 'Redirect 302' as explained: 1) Need 4 public IP address, and 3 domain names f5.mydomain.com - IP1 (apm1 VS with redirect iRule) apm1.mydomain.com - IP1a(apm1 SSL VPN VS) f5.mydomain.com - IP2 (apm2 VS with with redirect iRule) apm2.mydomain.com - IP2a(apm2 SSL VPN VS) 2) EdgeClient f5.mydomain.com resolves to IP1 or IP2 as per GTM 3) When EdgeClient hit IP1(on apm1), do redirect to apm1.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm1.mydomain.com[HTTP::uri]" } 4) When EdgeClient hit IP2(on apm2), do redirect to apm2.mydomain.com when HTTP_REQUEST { HTTP::respond 302 Location "https://apm2.mydomain.com[HTTP::uri]" } Hope it works for you.
- AP
  Nimbostratus
  Aug 04, 2015
  HI Kunjan, Could this be done with only a single IP in each site? For example using a filter to only redirect the initial request. when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { if { [HTTP::host] equals "f5.mydomain.com"} { HTTP::respond 302 Location "https://apm1.mydomain.com[HTTP::uri]" } }
- kunjan_118660
  Cumulonimbus
  Aug 04, 2015
  Seems possible. Hope you can test and share the results. BTW, there is doc available now https://f5.com/solutions/deployment-guides/f5-big-ip-gtm-with-apm-for-global-remote-access-big-ip-112-gtm-apm
- AP
  Nimbostratus
  Aug 05, 2015
  Thanks for the feedback. I've read through that deployment guide a few times already. I guess I'll need to lab it. :)
Michael_Koyfma1
Cirrus
Apr 12, 2014
What version of the APM are you running? There was a bug related to this in EDGE client that was fixed in 11.3.0 HF5 and 11.4.0 and above...
vandenhoutenp_9
Nimbostratus
Apr 12, 2014
@kunjan - Many thanks for your response, I'll look into that.

@Michael Koyfman - We're running version 11.4.1 HF3. I don't suppose you have any info relating to the bug (bug ID etc.)?
Michael_Koyfma1
Cirrus
Apr 12, 2014
It's bug id 416115 I was referring to. Strange, it should be addressed in 11.4.1. I suggest opening a case and referencing the issue and perhaps mentioning potential link to 416115 to have support investigate
vandenhoutenp_9
Nimbostratus
Apr 12, 2014
That's very interesting, many thanks for the response! I have a ticket logged with F5 on this one so I'll feed this back to them.