rserver behind ACE connecting to VIP in front of ACE

[robin.vanacoleyen]

Hi,

Is this possible?

Imagine the following situation:

LAN LB DMZ: 172.16.16.0/24 <=> ACE <=> LAN DMZ VIP 192.168.0.0/24 <=> FW <=> OUTSIDE

Rserver_16 172.16.16.10

Rserver_17 172.16.16.11

LAN DMZ VIP for Rserver_10_11: 192.168.0.10

Rserver_20 172.16.16.20

Rserver_21 172.16.16.21

LAN DMZ VIP for Rserver_20_21: 192.168.0.20

And here is the problem now:

Rserver 10 or 11 needs a connection to the Rservers 20 and 21 through the VIP 192.168.0.20.

But the connection seems to fail...

It seems like there is no solution, other than creating a new VIP on the LAN LB DMZ (inside) interface of the ACE.

That loadbalances to the same Rservers as the VIP on the outside.

But that would mean you have to change the hosts file on the rservers 10 and 11 so that they do not try to connect to the VIP on the outside, but that they would connect to the VIP on the inside.

I assume we would also need a NAT?

Or am I missing something here, are there other solutions?

I don't think this would have been a problem on other loadbalancers (atleast it isn't a problem on radware WSD...)

Kind regards,

Robin

[Francesco Casotto · Accepted solution]

Hello Robin,

if you configure the same service policy that you used for the VIP 192.168.0.20 on the server side interface you will make this VIP available also for incoming connections from that vlan interface, you will need to ensure that your servers will reach it by creating a route on them (a host route if you don't want to influence the rest) pointing them for 192.168.0.20 to the alias ip address on the server vlan on the ACE.

Depending on the setup you might need NAT, the general idea is to make sure that the reply from a server will not go directly to the other server without traversing the ACE (that would be asymmetric routing and would not work as the reply to the client would have to come from the VIP and not from the server's ip).

Hope it helps,

Francesco

[robin.vanacoleyen]

Francesco,

In a way this helped me to find the solution.

I added a new multi-match policy that used the same classes as the original multi-match policy

Then I played with the NAT a bit to find out where it needed to be applied.

When playing I noticed the ARP entry for the NAT got corrupt, so sometimes I had to clear all nat configuration and re-add to test some stuff.

But then I found the solution is to add a nat address to the inside interface, but the nat address itself belongs to the outside interface.

When applying that nat entry on the policy-map class, it works!

Thanks for pointing me in the right direction!

Kind regards,

Robin