'Subnet Originating Request' option with non-local real servers

0

We have an HA pair of VLMs configured in a DMZ network. We are struggling with creating firewall rules to allow the VLMs to connect to the real servers. Our real servers are in a different subnet to the 'inside' interface of the VLMs. Transparency is disabled on all VSs.

Internet <-> Firewall <-> VLM <-> Firewall <-> Internal (real servers)

eth0 = Internet arm
eth1 = Inside arm

When using tcpdump in the diagnostic shell I see traffic on eth1 towards the real servers, with the source address as the IP of the VS.

According to the documentation checking 'Subnet Originating Request' enables this behaviour:
"When transparency is turned off for a Virtual Service, the source IP address of the connections to the Real Servers is the Virtual Service. When the Subnet Originating Requests check box is selected, the source IP address will look like the local interface address on the Real Server’s subnet."

Whether or not I check the box for this parameter, the source address for traffic to the real servers is always the IP address of the VS.

My question is what is supposed to happen in this case? Can I use 'subnet originating requests' when my real servers are non-local?

Also, I've observed that the real server check traffic comes from the IP address of the individual node, not the VS address or the HA management address.

7 comments

Avatar
0
Barry Gleeson

Hi Ben,
Subnet Originating requests was typically designed for two-armed services in which the LM->RS communication would fail if coming from VIP (and therefore not local to the RS). Is it possible that in this case, even with SOR enabled, the natural route used is via ETH0 (and therefore the VIP is used)?

In your example for non-local Real Servers, Can you
1. Check if the Default Gateway is such that traffic will route out the inside arm.
2. Add a static route to the Real Server network under System Configuration>route Management>Additional routes and route out the internal arm.

Barry

Avatar
0
ben.lye

Hi Barry,

The default gateway is on eth0 (the outside arm), and there are routes sending traffic for our RS subnets to the inside interface, The routes seem to be OK, as using tcpdump I see the traffic going towards the real server on eth1 (the internal interface).

The problem is that the source IP address is always that of the VS, whether or not SOR is enabled.

Ben

Avatar
0
ben.lye

I wonder if I am encountering this known issue:

"Per-SubVS Subnet Originating Requests are not working when using reencryption"

We are using subVSs and re-encryption.

Avatar
0
Christian Scheller

Hi,

what firmware version are you running? Please try the latest and see if this fixes the issue.

Thanks and Regards

Avatar
0
Jason Bailey

Did this every get resolved?

I'm seeing a similair issue and as far as I can tell on on the latest firmware.

 

Avatar
0
ben.lye

I worked around the issue by enabling the global option for Subnet Originating Requests, rather than the per-VS option.  You can find it under Miscellaneous Options -> Network Options.

I don't know if it ever got truly fixed.

Avatar
0
Christian Scheller

Thanks, we are investigating the issue.

 

You might consider to raise a support ticket and provide the logs.

 

KEMP Customer Service