ACE Strange setup: catch-all rule and no normalization

GIULIO FAINI · ‎04-04-2013

Hi,

I have the following setup:

Internet

|

PC1 ACE Default Gateway

| | |

===================================

I need to fullfull 2 requirements for this one-armed setup:

1) Incoming requests from the Internet must have visibility on the client source-IP. This has been solved by configuring the default GW of the PC1 server pointing to ACE (and not to the Deafult GW) and by not configuring source-NAT (nat dynamic command on the relevant classes).

2) PC1 must also initiate traffic to the internet using PC1 source address (and not ACE source address). Therefore we configured a catch-all rule that is intercepting this traffic and sending it to the external world via the Default Gateway and also we disabled normalization.

It works, both point 1 and point 2. My questions are:

1) Have you ever seen such a design in place and it is a supported Cisco design? I.e. Use a catch-all rule to intercept traffic to send it to the default GW, all this configured in a one-armed design like we have.

2) Do you think it could create a traffic loop if the catch all rule would intercept other traffic passing via the ACE? In PROD we have different contexts all configured in the same VLANK0 and I guess we should check that any of this traffic is impacted?

Thanks a lot in advance,

Giulio.

ACE1/Microsoft# sh run

Generating configuration....

access-list ALL line 8 extended permit ip any any

rserver host PC1

ip address 160.213.122.100

inservice

rserver host Default_Gateway

ip address 160.213.122.9

inservice

serverfarm host TO_INTERNET

transparent

rserver Default_Gateway

inservice

serverfarm host macchine

rserver PC1

inservice

class-map match-all DEFAULT_VIP

2 match virtual-address 0.0.0.0 0.0.0.0 any

class-map match-any PC1

2 match virtual-address 160.213.122.36 tcp any

policy-map type management first-match remote-access

class class-default

permit

policy-map type loadbalance first-match GIULIO-l7slb

class class-default

serverfarm macchine

policy-map type loadbalance first-match INTERNET

class class-default

serverfarm TO_INTERNET

policy-map multi-match PC1_INTERNET_NAT_PMAP

policy-map multi-match POLICY

class PC1

loadbalance vip inservice

loadbalance policy GIULIO-l7slb

loadbalance vip icmp-reply active

class DEFAULT_VIP

loadbalance vip inservice

loadbalance policy INTERNET

loadbalance vip icmp-reply

interface vlan 503

ip address 160.213.122.50 255.255.255.0

no normalization

access-group input ALL

access-group output ALL

service-policy input POLICY

service-policy input remote-access

no shutdown

ip route 0.0.0.0 0.0.0.0 160.213.122.1

Jorge Bejarano · ‎04-04-2013

Guilio,

I think a "black hole" configuration (match virtual-address 0.0.0.0 0.0.0.0 any) like this, may cause unexpected behavior sooner or later.

I consider an alternate solution would be either to change the design or perhaps apply a x-forward-for feature where you can inject the original source address no matter you apply NAT.

Please this link:

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c3041.shtml

GET /header.html HTTP/1.1
x-forward: 172.16.10.221
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://www.cisco.com/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 30 Nov 2007 16:59:08 GMT
If-None-Match: "0164b527233c81:767"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: www.cisco.com
Connection: Keep-Alive

All these queries should be discussed with your Cisco SE or Cisco Partner anyway to have a better approach.

Jorge