VSX as Web proxy using IP different from the interface

[Rui_Pereira1]

Hi.

I'm trying to put in operation an explicit Web proxy within a VS (on a VSX cluster).

This VS only has 2 interfaces, external (the default route), and the internal (RFC 1918 route).

It works ok, PC have the VS internal IP address as proxy, and the outbound traffic leaves the VS with the external IP address.

However, If I want to use as proxy address an IP address from the VS internal interface, I can't put it to work.

I've tried IP address in the network as the internal interface (with NAT rule and proxy ARP entry), but it didn't work.

Tried with an IP from a different network (with a NAT rule for VS internal IP), but no luck.

The traffic arrives in the VS, but nothing happens after.

Also, a second issue is to change the outbound IP address based on the source PC.

But no luck also, just created a simple NAT hide rule, but it isn't taken in account... it always use the external interface IP.

Maybe I can do it for the destination, but then the rule will be applied to all sources...

And as far as I know, loopback or secondary addresses are not permitted in VS.

Anybody succeeded in putting a Web proxy working in VS but using IP different from the interface IP (or internal IP, or external IP, or both)?

This deals with a proxy migration, where I would like to keep the old proxy address (and it is an IP and not a FQDN), and the old outbound public address, but the same can't be assigned directly to the VS interfaces.

Thanks

[PhoneBoy]

In an explicit proxy configuration, traffic always originates from the gateway itself.
This is why explicit proxy traffic is F2F and will definitely lead to an increase in CPU utilization.

It's also likely why NAT rules involving the source IP don't work, since I believe that's done on the inbound chains only.
Having said that, unchecking "Translate Destination on Client Side" under Manual NAT rules in global properties might help here (or possibly create other issues):

 

Otherwise, you're likely looking at an RFE.

[Rui_Pereira1]

As this a VSX I do not want to uncheck "Translate Destination on Client Side", due to implications in other VS.

[Chris_Atkinson · Accepted solution]

Please review sk165672 and see if it helps with the NAT portion of your issue.

You may however need to consult TAC regarding the VS specific granularity of the same if required.

[Bob_Zimmerman]

That should definitely work for the proxy-to-server leg of the connection.

As for the client-to-proxy leg, I've been trying to find out more about that, myself. My company merged with another which uses the firewalls as proxies like this. I don't see any process listening on the proxy port, but connections to the proxy port work. I suspect it's getting handled by the multi-portal feature or something like it, but I haven't had time to really dig into what the proxy process is or how it receives traffic.

[Rui_Pereira1]

Applied sk165672 on the VS and it worked.

On the log we have an outbound source IP different from the interface IP  and it is accordingly with the NAT policy.

However in the log, the original source is the VS funny IP, we do not have any reference to the original source user IP (as in the old mode), nor any way to correlate the two logs.

But now it is possible to control the source outbound IP address.

Thanks

[Wolfgang]

It‘s VSX, maybe you can build another VS around your existing one and do the NAT there. Use the VS only as router or maybe s bridge, a rule with any any allow and your NAT rules. Doing no deep inspection need not so much CPU utilization.

[Rui_Pereira1]

That could be a solution, but need to connect both VS by an external VLAN to take advantage of VSLS, and it is traffic passing twice on the same switches.