IP Transparency and Routing Problem

[gr_stanley]

We have a problem with IP Transparency and routing.

Sample configuration:

Traffic IP: 192.168.0.100

Pool with Single Node: 192.168.0.101

Default Gateway: 192.168.0.1

With IP Transparency disabled, everything works great.

Connection from outside:

Outside -> 192.168.0.1 -> 192.168.0.100 -> 192.168.0.101

192.168.0.101 -> 192.168.0.100 -> 192.168.0.1 -> Outside

Connection from inside:

192.168.0.200 -> 192.168.0.100 -> 192.168.0.101

192.168.0.101 -> 192.168.0.100 -> 192.168.0.200

With IP Transparency enabled, the routing becomes a problem:

Connection from outside:

Outside -> 192.168.0.1 -> 192.168.0.100 -> 192.168.0.101

192.168.0.101 -> 192.168.0.1 -> Outside

Because the node no longer sees the request as coming from the load balancer, the return path skips it.

We were able to do a workaround by configuring the default gateway of the node to be the load balancer, which made the route symmetrical again:

Outside -> 192.168.0.1 -> 192.168.0.100 -> 192.168.0.101

192.168.0.101 -> 192.168.0.100 -> 192.168.0.1 -> Outside

But this doesn't work for connections from inside:

192.168.0.200 -> 192.168.0.100 -> 192.168.0.101

192.168.0.101 -> 192.168.0.200

Because the source IP is in the same subnet as the node IP, the return path of the traffic bypasses the gateway and goes directly back to the source.

This seems to break the TCP connections.

What is the proper way of configuring IP Transparency?

[markbod]

Hi Stanley,

Your usage of the transparency module is correct. The nodes do indeed need to have the STM as their default gateway because the return traffic must pass through Stingray. The best practice would be to use a TIP group as the default gateway and enable the option to keep the IPs together so that when the service VIP fails over, the gateway VIP moves with it.

The difficulty with having clients and nodes on the same subnet is that they will try to talk to each other directly when IP Transparency is enabled. Why wouldn't they? One solution is to override the Transparency when the client is on the same subnet. The below TrafficScript rule should help...

$client = request.getRemoteIP();
$stm = "192.168.0.100";
$net = "192.168.0.0/24";

if ( string.ipmaskmatch($client, $net) ) {
   request.setRemoteIP( $stm );
}

With this rule enabled any connections from local clients will appear to originate from the Traffic Manager (ie STM will operate in it's default SNAT mode).

Cheers,

Mark

[gr_stanley]

Thanks for the confirmation.

We are currently using Stingray Load Balancer 8.1r1 and don't see a way to add a TrafficScript rule.

How do we accomplish this?

[markbod]

Hi Stanley,

If you navigate to Catalogs -> Rules do you have a choice of creating TrafficScript or RuleBuilder rules, or do you just have the option to create a rule? If you do not have TrafficScript enabled on your license, then the alternative would be to create a duplicate pool with IP Transparency disabled, and then Create a RuleBuilder rule to direct local clients to the duplicate pool, and then apply that to the Virtual Server as a Request Rule.

Your rule should look like this:

• Condition: Remote IP Address - is a member of - 192.168.0.0/24,
• Action: Choose Pool: <Duplicate Pool without Transparency>

Remote clients will continue to use the default pool (with Transparency enabled), while local clients get directed through the other pool (with Transparency disabled).

Cheers,

Mark

[gr_stanley]

Thank you for the instructions. I will reference this page the next time we encounter this issue.