Re: Default routing depending on source-address

jxdemel · ‎08-11-2004

I have the need to use different default-routes depending on the source-address of the packet, when it comes from the content switch (e.g. from a group-address or as response-packet in a conversation with

a content address).

The reason for this requirement ist, that I have one firewall which is connected to both vlan2 and vlan602.

First there are rules, which disallow some traffic between 128.111.1.0 and 128.222.2.0. (addresses are only examples !!)

Second there occurs a routing-triangle which results

in blocking of path through the (statefull) firewall because the firewall sees no completion of the tcp 3-way handshake.

I tried this configuration but it does not work.

Pakets from 128.222.2.x adresses to 128.111.1.x adresses are send directly to the destination because the address in the arp-cache of the content switch.

any ideas ??

ip route 0.0.0.0 0.0.0.0 128.111.1.1 1

ip route 0.0.0.0 0.0.0.0 128.222.2.1 1

!************************* INTERFACE *************************

interface 1/1

trunk

vlan 2

vlan 602

!************************** CIRCUIT **************************

circuit VLAN2

ip address 128.111.1.101 255.255.255.0

ip virtual-router 2 priority 254 preempt

ip redundant-interface 2 128.111.1.100

circuit VLAN602

ip address 128.222.2.101 255.255.255.0

ip virtual-router 102 priority 254 preempt

ip redundant-interface 102 128.222.2.100

jfoerster · ‎08-11-2004

HI,

in my opinion this can not be solved with a CSS as you want to do policy based routing and as routing criteria the source-IP if I understood your question right. In my opinion you have to place a router between the CSSes and the Firewalls to be able to do that.

Regards,

Joerg

paul.matthews · ‎08-12-2004

I'm with Joerg, use a router outside the CSS and you can use PBR to do whatever you want.

Paul.

jchin · ‎08-13-2004

The problem with using PBR is the issue of scalability since PBR is process switched. You would need pretty sizeable upstream routers to do PBR at 100+ Mbps rate, let alone trying to do this at gig rate. Someone will probably point out that some of the L3 switches will do PBR at gig line rate, and I have done it on the 3750, but all the planets have to line up just right and you have to do much placating of the TCAM god (e.g. no ACE that would result in TCAM subtraction). Otherwise, PBR will get process switched and the processor will go to 100% with throughput of only 60-70 Mbps. PBR also makes it more complex to implement redundancy; probably have to use object tracking.

It would just be more straightforward and simpler if the CSS can use the "most appropriate" next hop for the source IP in question. For example, group A uses 1.1.1.1 and group B uses 2.2.2.2, and you have default gateways 1.1.1.254 and 2.2.2.254 configured. So the desired behaviour would be for all outbound traffic NAT'd to 1.1.1.1 to be automagically route to 1.1.1.254 for its next hop, and similarly for 2.2.2.2 and 2.2.2.254. I am sure some of the competing products (e.g. RADware Linkproof) can do this.

I have submitted this as a feature request to our local Cisco SE. We'll see if anything comes of it.

jchin · ‎08-13-2004

Additionally, since the CSS is flow based, it should have sufficient clue to send the return traffic out to the same next hop (maybe identifiable via L2 adjacency info, e.g. MAC address) that the inbound traffic came in from.

Gilles Dufour · ‎08-13-2004

here is a solution.

Create a service pointing at the firewall ip address.

ie:

service FW_ip1

ip address 128.222.2.1

active

Then configure the following acl

acl 1

clause 10 permit any 128.222.2.0 255.255.255.0 destination 128.111.1.0 255.255.255.0 prefer FW_ip1

clause 99 permit any any dest any

apply all

Regards,

Gilles.

jfoerster · ‎08-13-2004

HI Gilles,

great thing...

Didn't think about that kind of possibility to do "routing"....

Regards,

Joerg

jchin · ‎08-13-2004

This looks like it will work for return traffic for an established flow. But are you sure it would work for outbound (group NAT'd) traffic? Doesn't the ACL work in the inbound direction only? If so, would this still work if the ACL is applied to the pre-NAT'd inbound traffic to the "inside" interface?

Gilles Dufour · ‎08-16-2004

this won't work for established flow.

Once a flow is created it can't be modified.

This solution is for new sessions.

ACL are indeed applied on inbound, so think about your ACL acarefully.

Finally, if some nating is needed, use the acl to perform the nating - see my previous answer.

Regards,

Gilles.

jxdemel · ‎08-14-2004

I tried this, but it does not work (with 7.30 version).

I tried it with and without 'ip opportunistic all'.

I played with the 'ip ecmp' command too, but it did not help.

Should this work for outgoing flows resulting from NAT based on groups ?

when I run the debug-command 'ip routes master' their is a routing-table entry like:

0x8a68de08 128.111.1.74/32 08-00-20-fe-58-80 Dynamic

resulting from the arp entry.

Maybe the problem is, that this is an /32 entry which

will be used before /24 entries ?

when a do a 'sh acl 1' the usage -count for clause 10 is always zero !!

when I configure an explicit route:

ip route 128.111.1.74 255.255.255.255 128.222.2.1 1

this route never shows up in 'show ip routes' !!

Gilles Dufour · ‎08-16-2004

First, the static host route will not override a locally attached route. That's the way they design the CSS.

Regarding the solution provided.

Remember the acl is only applied inbound.

Then, if you need some nating do the following

acl 1

clause 10 permit any destination sourcegroup prefer

I did not test this myself but I know one customer doing it successfully.

Regards,

Gilles.

jxdemel · ‎08-16-2004

I tried now the following acl-clause:

clause 3 permit any 192.168.7.60 destination 128.1.1.0 255.255.255.0 sourcegroup belanna1n prefer gw-128.222.2

Sourcegroup belanna1n looks like

group belanna1n

vip address 128.222.2.60

add service belanna1i

active

and the Service is:

service gw-128.222.2

ip address 128.222.2.1

active

I also did a clause 3 log enabled

First I tried a ping: the sys.log looks like:

AUG 16 15:17:00 1/1 347 ACL-7: ACL match 1:3 Forwarding

AUG 16 15:17:00 1/1 348 ACL-7: ICMP

AUG 16 15:17:00 1/1 349 ACL-7: Source: 192.168.7.60

AUG 16 15:17:00 1/1 350 ACL-7: Dest: 128.111.1.74

The destination host still reaches the packet directly from the content switch (verified by tcpdump)

Then I tried a telnet to port 80:

No the log looks like:

AUG 16 15:19:12 1/1 351 ACL-7: ACL rule match 1:3 Redirecting packet, Log Enabled

AUG 16 15:19:12 1/1 352 ACL-7: ACL returning preferred service index 7

The service gw-128.222.2 has number 7, which seems ok.

But: no packets leave the content-switch at all !!!!

Gilles Dufour · ‎08-17-2004

I just did the test and it works for me.

However, I noticed I forgot to mention that the GW service definition requires the command 'type transparent' so the CSS does not nat the destination ip address.

Regards,

Gilles.

jxdemel · ‎08-17-2004

ok, after inserting the type transparent-cache statement now this works for hosts in the 128.111.1.0 network which are not vip of the CSS.

When I access a host e.g. 128.111.1.42 -- which

has defined http as content -- from 128.222.2.40,

the packet goes first to the firewall (128.222.2.1)

which sends it back on the other vlan to the

128.111.1.42 adresse. But the return-packets

go directly in the CSS from 128.111.1.42 to 128.222.2.40

how can I solve this problem ?

Gilles Dufour · ‎08-17-2004

can't you do the same acl for the reverse path ?

This solution won't work with VIP.

If you need such requirement, the CSM is much better for that.

Regards,

Gilles.