one armed transparent proxy configuration saga

[sfrisby]

We successfully migrated to a one-armed transparent proxy configuration with two SCA-2 boxes off a CSS11501. The reason for the migration was to allow the client (INET) source ip addresses to land on the server.

However ICMP echo replies broke. I fully understand why this happened as we are using 3 default routes and relying upon the " prefer ingress " behavior of the CSS as documented here :

http://www.cisco.com/en/US/customer/products/hw/contnetw/ps2083/products_tech_note09186a00801abfd6.shtml

My question is - how do I allow for icmp echo reply for clients that want to ping the VIP to validate reachability ?

I can't use ACL's as the ICMP echo originates from the box. The originated packets key word option does not look to be an option either.

The TAC was suggesting REVERSE NAT for ICMP - Thats way too ugly.

If I can't resolve this _ I may have to go back to non-transparent mode.

Any help would be appreciated.

[stevehall]

Well, why is "originated packets" not an option? I would think that would work. The reason is that we don't set up a flow for ICMP, so our reply should use the originated packets route.

Also, you could make a host route for the station that needs to ping the VIPs. Then you don't need to worry about the extra routes. The only caveat is that the host defined in the host route will not be able to access the VIP as we won't use the extra routes for that host.

If those don't do it, then proxy mode will be your 3rd option.

-Steve

[sfrisby]

Steve,

Thanks for your response.

The host route option is not feasible. As the echo would be coming from the global Internet hence the echo-reply needs to be a default out.

I had previously tried the originated packets keyword as follows :

CSS-LA-1(config)# ip route 0.0.0.0 0.0.0.0 144.142.128.5 originated-packets

%% That static route already exists.

hence there is a conflict with the existing static route already there ( without the originated packets keyword ) which is required.

I guess my only option at this point is back to proxy mode. I was told we can use the SCA's to insert the source IP address and have the webservers extract this in their logs.

http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_sca/sca_420/rnsca420.htm#41703

Due to the inflexabilty and management overhead of the one-armed transparent configuration - I think I will be moving back to the one-armed non-tranparent w/ httpheader forwarded

thanks.

-Scott

[stevehall]

Scott,

I have an unusual idea on this that may be the solution...

Configure a default route for originated-packets for a new address (in the same subnet as the existing gateway). Then, configure a static ARP entry on the CSS for that new address....

CSS11150(config)# ip route 0.0.0.0 0.0.0.0 144.142.128.6 originated-packets

CSS11150(config)# arp 144.142.128.6 00-00-0c-11-11-11 e1

Of course, use the actual MAC address of that gateway. The CSS pings default-gateways and we will need to turn that function off....

CSS11150(config)# ip no-implicit-service

That way, we will keep the routes in the table. We will not be able to ping the ".6" address from the CSS but will use the MAC address for all traffic originated from the CSS... I believe that will work for you. Is that an option?

-Steve