Is there a way to completely disable beaconing on ...
# citrix-storefront
m
Is there a way to completely disable beaconing on Workspace App/SF? I have need to force all traffic through the NetScaler, even when internally. I was eyeing ‘*Clear-STFRoamingBeacon’.* However this prompts me for “Roaming Service” and I’m not sure what value to put in there (I’ve tried several with no luck)
v
In the past I have just used a non-resolvable URL to force all traffic through the NetScaler.
m
I tried https://127.0.0.1 but that didn’t seem to help
Actually, to ensure there isn’t something else going on, is there any way to tell (logs, or whatnot) of what it’s beaconing process result is? I really hate stuff that works “automagicaly”
Here’s a bit of background on what’s going on: • Configuring workspace app with the gateway URL from the outside works. Session Policy is good and auth works (using SAML/Duo). FAS is implemented and working. • When a workstation on the inside is similarly configured, it prompts for MFA/Duo but then pops up asking for your name and password. And at this point, even if you enter in the correct credentials, it doesn’t accept it (I have tried various version of domain\username, upn, etc.)
I thought perhaps it was because it was beaconing and that last prompt was Workspace app talking to SF directly
v
💯 2
m
I’ll try that too
On the outside, that last username/password prompt does not appear. Once you MFA in your apps are presented and you can launch them A-OK. Only when you are inside does that pop up after (and won’t accept any creds)
In this case - the Base URL is the same as the Gateway FQDN also. I never usually set up deployments like that but that’s how it’s set up. That configuration alone I would think should HELP not hinder when wanting to force all traffic through the NS.
r
Yea don’t do 127.0.0.0 as that plays a role in the SF loopback options. You need to send the internal beacon to a dead url.
✅ 1
m
Thanks guys - I’ll try that
👍 1
Looking at my wireshark traces I think that may have worked. However my original issue remains, so it may not be related to beaconing is what I’m starting to suspect.
The mystery is why this extra SF credential prompt when on the inside vs. outside if both are now going through the NetScaler 100%
r
So they hit Netscaler gateway, auth, sends to SF but then SF ask for creds again?
2 stores or 1?
m
That seems to be what is happening: From Outside • If you configure workspace app with portal.domain.com, you are prompted for AAD Credentials/MFA (and then Duo MFA - for some reason they both prompting…) • After that it prompts you to select a store and apps come up and are available. So MFA and Session Policy for ‘Receiver’ are good & working From Inside • If you do same as above it prompts for AAD credentials, app MFA and Duo just the same, and also to select the Store as above. • But after that it then prompts for regular domain user credential. Nothing works here no matter the format (domain\username, UPN, etc.). • Update: After putting in a nonexistent internal beacon, when i wiretrace these popups and username/password prompts now it’s all between my internal workstation and GW VIP
r
You need to look at the gateway and determine what SAML actions you have in play, then you also need to looking into conditional access. Is the SAML app in Entra defined with azure MFA, and custome control in the mix? It sounds like your running into condition access and perhaps other config on AAA side. What your explaining to me seems somewhere there
m
Thanks Ray, let me ponder this a bit. Update: it had been a while since I looked in the SF Event Log. I do see something in here that may be a clue.
c
Internal gateway dns lookup resolves to external GW VIP?
Does a browser work fine internally?
c
I have used optimal gateway routing before to send all traffic through the Netscape gateway https://c4rm0.wordpress.com/citrix-receiver-sso-domain-passthrough-and-optimal-hdx-routing/
m
@Corey Tracey Yes, web works fine internally (both HTML5 and Workspace/ICA). The goal here is to get both workspace (configuration & launching directly from wtihin workspace) and HTML5 to work both internally and externally so laptop users have a seamless experience. In order to get HTML5 to work easily, I’m pointing internal URL to point to internal GW VIP IP instead of pointing to SF to facilitate that. But Workspace is unhappy with this - internally (external is fine).
@c4rm0 Thanks John, I’m reading that over now. Perhaps this may be a solution but I feel there is something amiss that may manifest itself in other areas. The goal as mentioned above to have have both HTML5 and Workspace connections work seamlessly inside as they do outside, for laptop users who roam back and forth. I’ve configured systems like this many times without too much drama. The unique pieces here on this install is that the client recently implemented AAD SAML Auth and Duo MFA leveraging FAS — and that the Base URL on SF is the same as the Gateway URL - a configuration I rarely setup myself (I usually separate SF from GW FQDN).
Update - I did some testing earlier and this setting didn’t seem to make a difference but now it is (maybe there was some setting cache/refresh time at play) - but a colleague here turned me onto this after we saw the Event ID 23's (CTX227498). Turning off requiring token consistency seems to allow credentials to be accepted into the popup. I’d still prefer that popup not happen but if it works then we’ll take it. But I still want to understand WHY this additional auth popup appears when you’re on the inside and not if you are outside. The next step would be to configure Workspace and then move the connect to the outside and see if it’s seamless or there is some other drama lying in wait.
Hey @Ray Davis to try to answer your questions - the only thing I see on the NetScaler Gateway is an Authentication Profile with one Duo SAML auth policy. That’s all - no AzureAD/MFA things, so I can only guess that perhaps the Duo is using Entra as the IdP I posted some updates above. I’m able to get past the last auth prompt from SF by disabling required token consistency, but still not sure why it appears at all, and if I can make it go away.
Thanks for all the input, folks - much appreciate it
d
I use this to force all traffic via NetScaler - this is from my notes. haven't done it for a while so unsure if this is still correct in latest StoreFront etc: If clients have direct access to StoreFront URL but you want to force all traffic via ADC (eg for MFA, firewall / traffic steering reasons etc) run the below command on the StoreFront server. Ref: https://docs.citrix.com/en-us/storefront/1912-ltsr/set-up-highly-available-multi-site-stores.html#use-powershell-to-configure-optimal-citrix-gateway-routing-for-a-store Relevant part is the last parameter: *-EnabledOnDirectAccess (Boolean)*—Set to true: ensures that when local users on the internal network log on to StoreFront directly, connections to their resources are still routed through the optimal appliance defined for the farm. Set to false: connections to resources are not routed through the optimal appliance for the farm unless users access StoreFront through a Citrix Gateway. Set-DSOptimalGatewayForFarms -SiteId 1 -ResourcesVirtualPath /Citrix/Store01 -GatewayName "gw.domain.com.au" -Hostnames "gw.domain.com.au" -Farms "FarmName1","FarmName2" -StaUrls "https://ddc2.domain.com.au/scripts/ctxsta.dll","https://ddc2.domain.com.au/scripts/ctxsta.dll" -StasUseLoadBalancing $TRUE -StasBypassDuration 000500 -EnableSessionReliability $TRUE -UseTwoTickets $TRUE -EnabledOnDirectAccess $TRUE NOTE - this may not work. refer to Note section here ( https://docs.citrix.com/en-us/storefront/1912-ltsr/set-up-highly-available-multi-site-stores.html#configure-an-optimal-gateway-for-a-farm Note - Above is deprecated. New commands are get-stfstoreregisteredoptimalgateway, register-stfstoreoptimallaunchgateway
j
Set the internal beacon to something like thissite.doesnt.exist Then all traffic looks like external. Also if you are using optimal gateway routing make sure to uncheck the External Only option.
🙏 1