Jump to content
Welcome to our new Citrix community!

Citrix Gateway AlwaysOn Inconsistant IntranetIP

Darren Bolton

Recommended Posts

I'm in the process of setting up a new Gateway vServer for use as a FullVPN with AlwaysOn and also looking to enable the AlwaysOn Service for Windows.


Netscaler version is at 12.1 51.19.


I've created the new vServer, enabled Certificate based authentication as the primary method and created and assigned a session policy to the vServer.


Within the session profile that is linked I've set Use Mapped IP to NS and Use Intranet IP to SPILLOVER and also set the Intranet IP DNS suffix.


Split tunnel has been configured to On and two Intranet applications bound to the vServer which cover the subnets I want the client to pass over the tunnel. I've also bound the IntranetIP range I want the clients to use to the vServer.


This configuration appears to work in a fashion and the clients connect and gain access to the network, however the client doesn’t always obtain an IntranetIP.


Sometimes it is and then other times it just shows as "Internal network address: Not Enabled" - surely this should be consistent? I’d like to bottom this out as well.


From here though I moved forward with trying to enable the AlwaysOn Service for Windows by creating the AlwaysOnService registry key as per https://docs.citrix.com/en-us/citrix-gateway/12-1/vpn-user-config/alwayson-service-for-windows.html


On restart of the device the tunnel comes up and I can see the client connected under Active users sessions however no traffic will pass from the client, it becomes completely isolated. Surely if it works when not configured as a service the same session policy should be getting applied and should work?


Am I missing something obvious?


Link to comment
Share on other sites

So, after a few days of head scratching I've made progress and just wanted to update this should anyone else come across the problem.


I’ve still got issues with devices not always obtaining an IntranetIP, however the issue whereby having the AlwaysOnClient running as a service and traffic failing to pass is now resolved.


From my troubleshooting I’ve found that on the installation of the AlwaysOnClient it configures a number of Inbound and Outbound firewall rules in the Windows Firewall, however in our environment we have the Windows Firewall configured via Group Policy and under the options for Rule Merging we have "Apply local firewall rules" set to “No” so that only the policies defined in the domain come into effect.


Changing this to "Yes" allowed the policies to merge and for the tunnel to then pass traffic correctly.


I've raised a call with Citrix as ideally, I'd like to just create the required inbound and outbound rules in Group Policy, however when I did this it failed to work so I'm assuming some of the rules maybe created dynamically when the tunnel is established. Should I get a defined list of rules required from support I’ll update this post.


Until I get that though we will just progress with leaving the firewall policy set to Yes for the application of local firewall rules.


I'd still appreciate some input around the IntranetIP not always being allocated if anyone has seen that before.

Link to comment
Share on other sites

  • 4 weeks later...

Some basic questions:

- any particular reason you are actually using Intranet IPs?

- How many IPs have you put into the "pool"?

- How many different users?

- and how many CONCURRENTLY CONNECTED users? 

- do you have any users who are actually disconnected, but Netscaler thinks are still connected (Netscaler Gateway / Monitor Connections / Active User Sessions)

Link to comment
Share on other sites

Sure, answers below;


- any particular reason you are actually using Intranet IPs? - We want to be able to manage the devices as though they are any other client on the network, so require them to obtain and use a unique IP.

- How many IPs have you put into the "pool"?  - I've allocated a subnet with a 20bit mask so 4094 addresses in the pool.

- How many different users? - up to now this has been limited to my lab and around 10 devices.

- and how many CONCURRENTLY CONNECTED users? - I've only had around 5 or 6 concurrently connected.

- do you have any users who are actually disconnected, but Netscaler thinks are still connected (Netscaler Gateway / Monitor Connections / Active User Sessions) - When the client fails to obtain an IP if I issue  show aaa session the device is shown with 2 sessions, the one from what I gather is a previous session which has and IP against it and then a new session with no ip. If I kill both the sessions the device connects and obtains an IP from the pool.


The problem with this though during my testing is that this happens too often and once in production we can't be expected to be having to clear sessions down manually this frequently?

Link to comment
Share on other sites

hmm, looks like you're doing things right....... plenty of IPs, and not many users!


Ignoring the longer-term need for remote management, could you disable the Intranet IPs (ie let everyone share a SNIP), and check that things are stable when done like that?


It seems that there's a "conflict" between the disconnected session, with an allocated IP, and the second connection, which isn't getting an IP. (thinks aloud: isn't there a setting I've seen that limits the number of per-user connections.... maybe could help?)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...