Hi there
We are in the process of doing a POC with the StingRay appliances within our Exchange 2010 environment. We have a requirement to continue with restricting access to our SMTP service by controlling who is allowed to connect. This is based on IP address and relies on preserving source IP of the SMTP connection thru the LB and not the IP of the LB.
Problem is how to setup this up in the LB? If I enable IP transparency SMTP doesn't seem to work correctly after that.
Any help would be appreciated.
Solved! Go to Solution.
Typically when IP Transparency is enabled the problem is with back end nodes routing the reply. This is covered in the user’s guide @ SteelApp Traffic Manager Docs , Chapter 2 - IP Transparency; see the Routing Configuration, and Local Routing Problems sections.
Instead of using IP Transparency and potential routing problems, have you considered offloading this functionality and configuring the Traffic Manager to restrict access to the virtual server by ip address with a Service Protection Class?
Alternatively, This can also be achieved with a Traffic Script Request Rule.
#entire range
$clientip= request.getremoteip();
if( string.ipmaskmatch($clientip, "192.168.1.0/24" ) == 0 ){
connection.discard(); }
or
#specific addresses
$allowed = [ "192.168.1.68", "10.0.0.43", "172.16.1.177", "8.8.8.8" ];
if( ! array.contains( $allowed, request.getRemoteIP() ) {
connection.discard();}
Hello Stephane,
I never played with IP transparency on SteelApp TM, but what about enforcing the restrictions at the LB level?
Rate-limiting, ACL to discard connections, etc.
I personally don't use load balancing for SMTP and rather rely on another MTA sitting in-between Exchange and Internet. This is because SMTP inbound already includes failover (multiple MX records) and does not require low latency fallbacks.
If you are setting up an outbound Exchange SMTP though, I understand why the trouble going with IP transparency. Can you elaborate on the problems you're encountering?
Typically when IP Transparency is enabled the problem is with back end nodes routing the reply. This is covered in the user’s guide @ SteelApp Traffic Manager Docs , Chapter 2 - IP Transparency; see the Routing Configuration, and Local Routing Problems sections.
Instead of using IP Transparency and potential routing problems, have you considered offloading this functionality and configuring the Traffic Manager to restrict access to the virtual server by ip address with a Service Protection Class?
Alternatively, This can also be achieved with a Traffic Script Request Rule.
#entire range
$clientip= request.getremoteip();
if( string.ipmaskmatch($clientip, "192.168.1.0/24" ) == 0 ){
connection.discard(); }
or
#specific addresses
$allowed = [ "192.168.1.68", "10.0.0.43", "172.16.1.177", "8.8.8.8" ];
if( ! array.contains( $allowed, request.getRemoteIP() ) {
connection.discard();}
Note this is for internal SMTP access for internal application servers.
Thanks for your response, your recommendations are of value and I am going to test the scenario.
However, if I use your second option traffic rule I get the following when trying to do a Check Syntax:
Error: line 4: Syntax Error, unexpected "{"
if ( ! array.contains( $allowed, request.getRemoteIP() ) {
The second conditional statement lacks a closing parenthesis.
Cheers
I am very new to this, can you show me what u mean by updating the script?
Hehe, no problem:
#specific addresses
$allowed = [ "192.168.1.68", "10.0.0.43", "172.16.1.177", "8.8.8.8" ];
if( ! array.contains( $allowed, request.getRemoteIP() )
{
connection.discard();
}
Should read:
#specific addresses
$allowed = [ "192.168.1.68", "10.0.0.43", "172.16.1.177", "8.8.8.8" ];
if( ! array.contains( $allowed, request.getRemoteIP() ) )
{
connection.discard();
}