In talking to a customer this week, they expressed a wish to move from one authentication mechanism to another, but first needed to test. We all know you can spin up a test VPX on your LAN, or in the cloud (any cloud) and do the configuration there, but what will happen when you try to use that same configuration within the boundaries of your DMZ? Will there be certificate issues? Will all the right ports be open? Will DNS work the way it’s supposed to? Will the answer be allowed back? So many questions.. and the answer will only truly be known by setting it up in the network environment it will ultimately run in.
You might want to use Azure MFA. Or change your second factor.. perhaps to use the Citrix One Time Password functionality as your second factor? You might have authentication on your internal Outlook Web Access, and want to setup MFA so it’s ready to be securely exposed to external access.
ANYhow – this is one of the queries I got this week. How do we effectively test this. With minimal disruption and ease. Standing up a second VPX means getting additional IP addresses, NATs, ports opened etc. Sounds lengthy.
So – I thought I’d remind everyone of the humble listen policy. A massively useful tool on Citrix ADC that has several use cases. One of these is to allow you to have two separate VServers listening on the same IP and same port.
Why you ask? Well – so you can apply your test authentication policies against the second Vserver of course!
How do I ensure only test requests will land on this test Vserver? Well my dear (in a grandmotherly voice) with a listen policy of course! This means only traffic that matches the listen policy will hit that second Vserver. So – if I add a listen policy to only allow traffic from my home internet IP address, or from a test workstation – say 10.20.0.22 for example) – then only THAT traffic will hit the test vserver. The production vserver continue to hum along unhindered, and unaware.
Once your testing is complete, you can either
- bind your new auth policies to the old vserver
- remove the old vserver and remove the listen policy from the test vserver.
I’d prefer option 1 – as there may be other policies or settings that you didnt duplicate to the test vserver, plus your metrics and stats etc will be attached to the original vserver entity. Might be nice to retain those.
I’m very visual – so here’s a little diagram to explain what this is all about:
Here’s the disclaimer – there are always risks with testing in production, this DOES require changes on a production appliance. Adding a second vserver shouldnt cause any problems – but if you mess up your listen policy, there IS a chance that production traffic could land on your test vserver. (e.g. if you use client.ip.src.in_subnet(10.0.0.0/8) as your policy, then all traffic from the 10.x.x.x network will be funneled to your test vserver. )
Oh – also – when creating the test VPN VServer, I don’t think you’ve the option to create the listen policy at creation time. So I just used a dummy IP to create the VPN VServer entity. Clicked OK, & done. Then I edited the test VPN VServer, and added the listen policy, and THEN changed the IP address of the test VPN VServer to match that of the Production Vserver.
I’ve gotten a few notes back on other use cases.. so I decided to add them in here too.. drop me a line on social media and I’ll add your use case in too. 🙂
- Configuring a different cipher list for a specific customer or client IP / client IP range. Very useful if an automated solution cannot negotiate to the configured ciphers on the public vserver. (Yan)
- Same hostname, but different back end server resources depending on where the client is coming from. (Probably could achieve this with content switching too.. and it might be the better tool)