Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Issue with F5 APM with Citrix Storefront beacons and internal/external single fqdn using receiver

Hi - I'm using a client with receiver 14.3.100.10 and the iApp citrix_vdi v2.2 - also tried 2.3 with the same problem.

I can see the problem but don't know how to resolve it. Let me explain what's happening:

We have 2 internal storefront servers. Internally they are load balanced by the F5 LTM with internal DNS resolving the single service fqdn citrix.domain.com to the VIP. No problem.

The beacons are configured on the Citrix Storefronts to help the receiver discover if it's inside or outside and if it should use the external gateway configuration. The beacons can't contain the service fqdn - because it's available internally and externally the client will determine it's internal and not connect/authenticate with the gateway.

When i connect externally using receiver to the F5 APM and add the store it works the first time - it connects and get's the config from storefront. Logoff and i can't logon again because the F5 seems to have added the service fqdn as an external and internal beacon.

I can see the beacon entry in my registry - if i delete it and restart receiver it connects again only for the wrong beacons to be re-added and break the next connection.

If i take the access policy off the VIP i can connect through fine and these beacons aren't added which makes me conclude it's the F5 doing it. We want the authentication to happen at the edge so want to use APM. I can't see what part of the config is adding it - can anyone point me in the right direction?

0
Rate this Discussion
Comments on this Discussion
Comment made 15-Mar-2016 by Greg Crosby
Hi vmoseley, I am not positive beacons are supported, but I would open a case to get a definitive answer from support.
0
Comment made 15-Mar-2016 by Andrey Terentyev
I believe we do support beacons but we have a logic to insert StoreFront Store FQDN as an internal beacon (which we do for historical reasons as older StoreFront versions did not specify it). This breaks single FQDN deployments where Receiver Client thinks it is talking directly to StoreFront if it can resolve internal beacon (StoreFront Store FQDN). The workaround is to use different FQDNs for APM VS and StoreFront Store.
0
Comment made 15-Mar-2016 by hm111 2
Andrey, that's very useful to know. What we are finding is that it is inserting the StoreFront FQDN in as both an internal and external beacon. It doesn't matter that it is inserting it is an external beacon (although I would rather it didn't) but surely there is no logic that says that it should it insert it as both because then you are going to end up in a situation where Receiver just won't work. Or is it the case that it is inserting the StoreFront FQDN as an internal beacon and the Gateway FQDN as an external beacon, and, because in my case they are the same this is how we are ending up in a situation with identical internal and external beacons. I guess the only way to find out will be to use different FQDNs.
0
Comment made 16-Mar-2016 by Andrey Terentyev
I could not find a way to make a formatted comment and copied our conversation into reply section. Please see my answer and possible solution below.
0

Replies to this Discussion

placeholder+image

Comment by hm111

... Or is it the case that it is inserting the StoreFront FQDN as an internal beacon and the Gateway FQDN as an external beacon, and, because in my case they are the same this is how we are ending up in a situation with identical internal and external beacons.

This is exactly what is happening. APM inserts its own FQDN as external beacon + it grabs StoreFront FQDN and inserts it as an internal beacon. If both are the same, then external and internal beacons will be the same. Citrix Receiver will first try internal beacon, and since it can resolve it, it will think it's going directly to StoreFront and will skip (and fail) gateway authentication against APM.

Using different FQDNs for APM and StoreFront and making sure StoreFront FQDN is not externally resolvable would solve this issue.

0
Comments on this Reply
Comment made 16-Mar-2016 by vmoseley 107
Thanks Andrey - i'm trying to test that irule but if i try and attach it to a forwarding server but because of HTTP_REQUEST it says i need a http or fasthttp profile which i don't seem to be able to add to a forwarding server. Only allows me to add fastL4 profile. I'm not too experienced with irules or forwarding servers so apologies if the answer is simple.
0
Comment made 16-Mar-2016 by Andrey Terentyev
I found the iRule approach not working and removed it. It seems the best course of action is to go through support case as Greg Crosby suggested.
0
Comment made 18-Mar-2016 by vmoseley 107
Will do Andrey. I tried it and it has the desired affect but doesn't resolve the problem as it breaks something else. Thanks for your effort.
0
placeholder+image

I created a ticket. Various logs have been sent and analysed and the f5 is putting both unwanted beacons in as internal and external. I.e. the xml received from the storefronts only contains the beacons configured on the storefronts. The F5 is adding the storefront service url as an internal and external beacon. Most helpful! It's been escalated internally to engineering as it's not obvious how the F5 is doing this or how to change its behaviour. I hope to have a workaround in the next update...

0
placeholder+image

werp werp! They created an engineering hotfix which works for 11.6.0 HF6. Hotfix-BIGIP-11.6.0.6.342.442-HF6-ENG.iso

0