Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Cisco Employee

one armed transparent proxy configuration saga

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 :

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.

New Member

Re: one armed transparent proxy configuration saga

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.


Cisco Employee

Re: one armed transparent proxy configuration saga


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 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.

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



New Member

Re: one armed transparent proxy configuration saga


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 originated-packets

CSS11150(config)# arp 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?