ICMP Through a Source Group

[dan.shalinsky]

I'm attempting to get Windows traceroute to work through a Source Group. I believe that ICMP traffic is not NAT'd by default, but I've specified with an ACL and I think it may be getting translated now.

I still cannot trace all the way to my destination and can only get to 1 intermediate hop. Interestingly, ping seems to work fine, which is also ICMP on Windows.

Also, a question about source groups in general: if a flow is initiated internally with a Source Group, will any traffic with the correct source/destination pair be allowed in, even if it does not match a configured Content Rule?? If so, I presume that once the flow times out, further traffic would be subject to active Rules.

Can anyone shed any light on the situation?

Regards,

~Dan

[Zach Seils]

Hi Dan,

What version of WebNS are you running? A co-worker found bug id CSCdx90237 when researching a similar problem -- so this should be fixed in the latest 7.40 code.

To answer your second question -- responses to source group initiated traffic will be allowed in. In fact, the CSS doesn't drop traffic that isn't destined for a content rule, it just passes it through.

~Zach

[dan.shalinsky]

Hi Zach:

Thanks for the reply and the info on source groups. I was thinking about the whole thing wrong. I gather that, basically, traffic replies to source group traffic completely bypasses all content rules, *but* only as long as the TCP flow hasn't timed out. Once it times out, traffic is denied, right?

We're actually running 6.10.405 on a 11800 if that makes any difference. It's the lastest and greatest for the 11800 series.

Regards,

Dan

[Zach Seils · Accepted solution]

Right -- because the CSS creates both flows (in <-> out, out <-> in) at the same time, return traffic is handled by the flow system and is not evaluated against content rules.

Once the flow(s) have been removed, traffic that doesn't match a content rule will just be routed through the CSS, not denied.

~Zach

[dan.shalinsky]

Hi Zach:

Thanks again for the clarification.

Any ideas on the traceroute issue?

Dan

[Zach Seils]

Dan,

For the ICMP issue, can you take a sniffer trace on the server and client side of the CSS? If possible, a copy of your configuration would be helpful.

Thanks,

Zach

[Gilles Dufour · Accepted solution]

Dan,

this is a bug.

We jsut fixed it.

The problem is that the nating info is saved on 1 module and the TTL expired message arrives on another module.

We fixed the problem by looking into the icmp message to find the correct source/destination and assign the packet to the correct module.

I tested the fix yesterday and it works.

We now have to integrate it in the next software release.

The bug id is CSCeh29793.

Gilles.

[dan.shalinsky]

Hi Gilles:

Many thanks for letting me know. Out of curiosity, was this something that has worked in the past on older images?

~Dan

[Gilles Dufour]

it works with 11000.

It works with non-windows platform.

It works if you have only 1 module in the CSS.

It works if the router ip address is hashed to the same value as the destination.

All versions of the 11500 would show the problem out of the working conditions descrived above.

Gilles.