Jump to content
Welcome to our new Citrix community!

Netscaler 14.1 DSR Mac based USIP for SMTP


fahae

Recommended Posts

We have configured a load balancer for SMTP on a new VPX Netscaler 14.1 appliance in the classic load balancer way. Client sends a request. Netscaler processes it and sends the request to the Exchange Server. The Exchange server responds to the Netscaler and the Netscaler forwards the response back to the client. Everything works fine.

 

But now, as you can probably already guess, we don't want to see the SNIP on the Exchange Server, but the client IP address. 

Therefore we followed this Docs article (https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-dsrmode.html) and this blog post (https://ingmarverheij.com/citrix-netscaler-dsr-poor-mans-load-balancing-solution/) and configured Direct Server Return (DSR) with the help of MAC based forwarding and USIP. 

 

To summarize:
Service with USIP. Load balancer with Redirection Mode: MAC based, Traffic Settings: Sessionless and Method: SourceIPHash. No SMTP monitoring but simple PING or TCP monitoring. Everything tied together. Then configured the loopback adapter on the Exchange. Done.

But unfortunately the configuration doesn't work and now I can't think of anything else to test. That's why I'm writing to you today and hoping for help from the community. 

 

How is the behavior now?

 

Ping, TCP, SMTP monitors that we attach to the services or service groups are always positive (green). This can also be seen in the trace and in the nstcpdump. 

However, if we now make a Telnet session with port 25 to the load balancer address, we get no response. In a trace from the netscaler and in the nstcpdump we can see that the request arrives at the load balancer address. But what is completely missing in the trace and in the nstcpdump is the packet that should now go from the netscaler to the exchange server. There is simply nothing there. 

 

What am I missing here? Why is the Netscaler not sending out the customized packet? I would be grateful for any tips. 

Link to comment
Share on other sites

22 hours ago, Fabian Hässelbarth said:

We have configured a load balancer for SMTP on a new VPX Netscaler 14.1 appliance in the classic load balancer way. Client sends a request. Netscaler processes it and sends the request to the Exchange Server. The Exchange server responds to the Netscaler and the Netscaler forwards the response back to the client. Everything works fine.

 

But now, as you can probably already guess, we don't want to see the SNIP on the Exchange Server, but the client IP address.

 

Hello,

We've used NetScaler to load balance SMTP traffic while preserving the client's IP address for many years.  We only use this capability when X-Forwarded-For-type solutions won't work.

 

We basically:

Create a NetScaler SNIP on the same subnet as the back-end Exchange servers (if there isn't already a SNIP/MIP on that network)

Set the Default Route of the Exchange servers to that SNIP (this is required)

Enable USIP on the Service/Service Group for that port 25 SMTP traffic

 

There may be other ways to do this and others can describe what I've put above with better detail, but we've never had to set up DSR or anything complex to retain client IP addresses.

Link to comment
Share on other sites

Thank you for your answer. 
 

3 hours ago, Robert Blissitt said:

Create a NetScaler SNIP on the same subnet as the back-end Exchange servers (if there isn't already a SNIP/MIP on that network)

 

Do you know whether this is also necessary for my preferred solution? Our SNIP can reach the Exchange servers, but is in fact located in a different network. But the default gateway that is stored in the Netscaler can handle this. Or is this "primarily" for your solution because you are configuring the default gateway of your Exchange infrastructure to this new SNIP? 

 

3 hours ago, Robert Blissitt said:

Set the Default Route of the Exchange servers to that SNIP (this is required)

 

But I don't think it's a good idea to change the default gateway of the existing Exchange Server infrastructure. I don't think I actually want to do that. 

 

3 hours ago, Robert Blissitt said:

There may be other ways to do this and others can describe what I've put above with better detail, but we've never had to set up DSR or anything complex to retain client IP addresses.

Well, if we use HTTP traffic, then an X-Forwarded and an Insert-Client-IP are usually also right for us. But as far as I know, this does not work with TCP out of the box.

 

 

Perhaps another community member will take pity on us and can help us here or at least confirm that we are completely on the wrong track. 

Link to comment
Share on other sites

1st consideration: changing the default gateway is the "correct" way to use this "creative" feature that is UseSourceIP. This comes with a lot of downsides, the only way I saw this work without issue is when the Netscaler is placed behinde 2 firewalls (front and back) and the NetScaler IS the default gateway for both firewalls. I don't think this is your situation.

 

2nd consideration: the "official" way to achieve what you're looking for should be this: https://docs.netscaler.com/en-us/citrix-adc/current-release/system/client-ip-address-in-tcp-option.html. This solution would allow you to keep your network configuration cleaner.

 

3rd consideration: SMTP traffic is not web so the use of any kind of HTTP Header (like X-Forwarded-For) is not an option

 

So my understanding is that you're trying to leverage security features of your backend server like ip-based-blacklists.

My suggestion would be to review the design of this service but I understand this can be challenging and can potentially requires a lot of time and effort, so the best suggestion I can give you is to try with the link on the 2nd consideration, Client IP Address in TCP Option. Keep in mind that every router needs to maintain those options while routing the packet, so your infrastructure should be "aware" of this option (or your ADC should talk directly to your backend, on the same network)

Link to comment
Share on other sites

22 hours ago, Robert Blissitt said:

Create a NetScaler SNIP on the same subnet as the back-end Exchange servers (if there isn't already a SNIP/MIP on that network)

Set the Default Route of the Exchange servers to that SNIP (this is required)

Enable USIP on the Service/Service Group for that port 25 SMTP traffic

 

The above is the only scenario I'm familiar with and the only one I've found that works to load balance SMTP traffic to Exchange.  The "TCP Option" above may work with other mail servers, but I don't think Exchange has the ability to extract the client's IP address when it's inserted this way.  There may be other mail server solutions available, perhaps even free ones, that you can deploy alongside Exchange solely to handle this particular traffic.  But if you want to use Exchange, I believe you will need to use USIP.  You can find many examples of how to set up USIP online, and they all include the steps I've written above.

Link to comment
Share on other sites

On 1/31/2024 at 7:54 PM, Fabian Hässelbarth said:

Our SNIP can reach the Exchange servers, but is in fact located in a different network.

For MAC-based redirection to work, you have to configure SNIPs in the same subnet as the backend servers, because the NetScaler needs to discover the MAC address of each server. Without being in the same layer 2 network that is not possible.

 

If you want Exchange to receive the real client IP for purposes of allowing/denying specific IPs to use SMTP relay, you can do that with a Responder policy in the NetScaler. And if the Exchange team want to have the connection logs, you can create a log policy and send via syslog to an external server.

Link to comment
Share on other sites

  • 1 month later...

Well, the Source IP (SIP) mode is the right choice. However, the problem with SIP mode is that the NetScaler uses the client IP. So it sends a TCP SYN packet from the client IP to the backend, and the backend server sends SYN/ACK to the "real" client. This packet comes as a surprise to the client and is therefore discarded.

There are only two ways to work around the problem:

  • The NetScaler and the mail server are in the same subnet, then you can, as mentioned, enter the NetScaler as the default gateway on the mail server (which has the disadvantage that the NetScaler must have licensed all traffic that the mail server must do to the Internet, this includes updates.
  • And perhaps better: The components between NetScaler and mail server (switches, routers) must support Policy Based Routing (PBR). Then only the traffic that was initiated from the NetScaler runs via the NetScaler. If the device is a Cisco device, PBR can be programmed very quickly and easily via RISE Integration.

 

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...