Recently I had to transfer a NetScaler VPX configuration to a MPX appliance. This was not much of a hassle as most of the configuration can just be re used but be sure to check as i.e. the ntp configuration did not quite reach the new appliance.
Nevertheless as always I was not only applying the old configuration but also doing some optimizing. The number one desire was to use rules with Exchange 2010 SMTP. The challenge was not indeed to create a rule within Exchange but rather that the rule was based on client addresses!
There was already a load balancing virtual server created which worked perfectly but you have to keep in mind that with a standard load balancing virtual server the Exchange servers will always only notice the NetScalers IP address.
First things first you will have to make sure that the clients IP address will reach the Exchange servers. This can easily be done by choosing your Service or Service Group and check „Use Source IP“ (USIP) within the Advanced settings. After completing this single configuration your source IP will be transmitted to your Service i.e. in my case Exchange Servers. You will notice that communication with your virtual server is broken now (test environment or at least test virtual server!). This problem arises as your server will now answer directly to your requesting client as he now knows its IP address and tries to start a direct connection. As your client did never start a direct connection with your server it will drop all packages and data will be lost in space.
To overcome this problem you will need to use your NetScaler as a gateway for your defined servers. This would mean you will have to make sure that your NetScaler is able to route all packages as your gateway does and you always will have to recall that those servers are not using your standard default gateway anymore. If only some clients are using a such configured virtual server you can use manual defined routes also.
As you can see this might not be always an option as in addition to changing the gateway on your production servers reverse traffic will flow through the NetScaler again and often you just want a load balancer but will not use any optimization so why spend your precious throughput on useless data pass through?
From this point on in my example the Exchange server will get the clients IP address and is able to use rules to check i.e. wether the client resides in the internal or external network and use different policies then. If you will just test this scenario use a route for your test client and sure a test virtual server for load balancing. This will make sure your production environment is not being affected.
The communication flow so far is IP based so your server will always have to answer through your NetScaler as he did start the communication. To break down this barrier we will have to make the server think that communication originated from the client itself and the client that it still communicates with the virtual server so packages will not be dropped.
This can be done by changing the redirection mode of your virtual server from IP based to MAC based or Direct Server Return (DSR). You will accomplish this by choosing „MAC Based“ in your virtual servers advanced settings Redirection Mode option. The change from IP to MAC based forwarding is all there is to do on the NetScaler. From now on all packages send from the virtual server to your server i.e. Exchange will still get inserted the clients IP address as of USIP enabled on the services but in addition with MAC based redirection enabled the NetScaler will replace its own MAC in every package with the one of your services server.
You have to know that this will only work with protocol type ANY, so you might have to change your services server and/or virtual server. If you will not you will get an error message, while trying to switch your virtual server to MAC based redirection.
Your services server will now think that communication came directly from your client but will never answer this request. This behavior is due to the fact that your services server will not own the virtual servers IP thus dropping the package. A network trace will show that from your NetScaler there will be three SYN attempts but you will never see an ACK from your server.
First we will have to make the server own your virtual servers IP address but not make it addressable from outside itself. You sure know that this would give your network a headache and you do not want that. Add a loopback adapter on your services server uncheck all protocols leaving IPv4 checked. Configure your virtual server IP address and subnet mask and you are done here. You should choose a sensible name for the loopback adapter so you will recognize it at once. This will not just make configuration easier but also troubleshooting in case 😉
You can add the loopback adapter within your device manager choosing add legacy hardware. The loopback adapter can be found with choosing Microsoft as manufacturer.
At this second your services server also owns the NetScaler virtual server IP address but the sad news it it will mostly still not answer if your services servers are beyond Microsoft Windows Server 2003. If you are using a newer version your TCP/IP stack will be secured and your server will never answer a request on your production LAN network adapter.
This will lead to some configuration on your production and loopback adapter. To understand what you will be configuring you might wanna read a bit in here.
netsh interface ipv4 set interface "Your production network adaptor name" weakhostreceive=enabled netsh interface ipv4 set interface "Your loopback network adaptor name" weakhostreceive=enabled netsh interface ipv4 set interface "Your loopback network adaptor name" weakhostsend=enabled
The magic is done!
Be sure if you tested with manual routes or NetScaler as your gateway before to revert those settings otherwise you might run into serious problems. Your client will now still communicate with your load balancing virtual server thus leverage its capabilities. Your services servers however will answer directly to your client.
To sum up the needed configuration tasks:
- Create your Load Balancing virtual server with services servers
- Check USIP on every Services server or your Service Group
- Change redirection mode on your virtual server to MAC based
- Create a loopback adaptor on every services server with the virtual servers IP address and uncheck any other protocol
- Configure wakhostreceive and send on your services servers network adaptors as described
In a follow up article I will show you the necessary alteration to use the same technique for Citrix Provisioning Services TFTP.
Always mind your network!
- Azure Remote App https://t.co/cWZK5X5iHn
vor 1 Jahr
- Azure Remote App https://t.co/cWZK5X5iHn