09-10-2003 02:26 PM - edited 02-20-2020 10:59 PM
This is a somewhat lengthy post so I'll pose the key questions up front:
1) Are there any other viable workarounds for the problem/behaviour described below?
2) Is the behaviour described below a bug that should be fixed or a "design feature" of the 3060 that will never be fixed? TAC is trying to tell me the latter...
I have a 3060 concentrator serving around 1500 SOHO users. The outside of the 3060 connects to a DMZ ("encrypt DMZ") on the Corporate PIX and the inside connects to a second DMZ ("decrypt DMZ") on the same Corporate PIX (as recommended by the SAFE Secure Networking Blueprint for Enterprises). The corporate security policy does not allow split-tunnneling, so all traffic (including internet) passes over the tunnel from the client to the 3060.
Routing is currently configured as follows on the 3060:
- default route points at the PIX interface on the "encrypt DMZ"
- tunnel default points at the PIX interface on the "decrypt DMZ"
- internal static routes point at the PIX interface on the "decrypt DMZ" (for 3060 management/service traffic)
This works great for most traffic flows. The default is used for tunnel establishment, while the tunnel default is used for all client-internal and client-internet traffic. The only snag is that client-client routing does not work when the tunnel default gateway is configured to point at the PIX, because the PIX will not route a packet back out of the same interface it was received on.
Note: When tunnel default is not configured, the 3060 uses some internal (hidden) routing table to send client-client traffic directly back out of the tunnel interface. The tunnel default seems to override this internal (hidden) table. Is this a bug or "designed in behaviour"?
I have considered turning off tunnel default and just using static routes, but then I would run into issues with the client-internet traffic which would be routed using the 3060 default to the PIX interface on the "encrypt DMZ".
The other option I have considered is placing a router on the "decrypt DMZ" and pointing the 3060 tunnel default at it. The router would send all client-client traffic back to the 3060, and all other traffic to the PIX giving the desired behaviour. However, I would like to avoid this solution as it would make troubleshooting more complex and ties up an additional router.
I'd certainly be interested to hear of any other workarounds other folks may have come up with.
So why is the 3060 behaving like this? Common sense tells me that the 3060 should route something like this (assuming no dynamic routing in the DMZ environment):
1) Client routes, preferred over;
2) more specific static routes, preferred over;
3) less specific static routes preferred over;
4) tunnel default gateway, preferred over;
5) default gateway.
The cisco docs seems to say this, but they are certainly open to interpretation:
"The IP routing subsystem routes data packets first using learned routes, then static routes, then the default gateway. If you do not specify a default gateway, the system drops packets it cannot otherwise route.
For tunneled data, if the system does not know a destination address, it tries to route the packet to the tunnel default gateway first. If that route is not configured, it uses the regular default gateway."
Has anyone tried talking to the TAC about this behaviour before? I have to believe that people have run into this problem before, as this is a cisco touted topology.
Any insight would be appreciated.
Cheers
Dave
09-16-2003 09:52 AM
I dont think this is any bug, I guess this is designed like that and the way it ment to be, just my feeling.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide