> (I assume you removed cisco-nsp on purpose?)
Yeah, just getting some more caffine in me before posting publicly...
> > Any chance you could do a gre tunnel w/ the 10.0.0/24 network?
>
> That's what I have been thinking, too (and what we do with other
> locations, covering "friendly" networks only).
>
> The problem I can see with that is the other end is a PIX, and AFAICS,
> PIXen do not support GRE tunneling
Ugh. If only they'd give us a beefy cpu or a PXF equivalent for the
low-end modular boxes (3600 and 2600) that are inevitably expected to do
all the really nasty stuff like CBAC and NAT (a 'feature AIM' for that
second slot on a 3660?). Might actually be able to lay the PIX to rest.
> ip nat inside source static 192.168.0.10 195.30.101.17 list 170
Yep, that'd do it beautifully.
> I'm not really sure what you're hinting at, but I'm afraid it won't - to
> get "external access NAT", I need a static - and the docs pretty clearly
> state that access list and route-map are not considered if a NAT
> translation entry already exists :-/
It damn ugly and probably wouldn't work, but the idea was to use the
policy route to force the application of acl 170 to nat policy.
Assuming a present config of S0 as ip nat outside, and E0 as ip nat
inside, and you have a small public block as well....
loopback0 sits on the public block, and is made ip nat inside. nat is
turned off on E0, and a policy route-map applying acl 170 to set interface
loopback 0 is added (thus bypassing the def route to S0). The crypto-map
is then applied to S0. Its really damn ugly and flies
I haven't ever tried something like this, nor read the nat docs in
consideration of it, so I'm undoubtedly overlooking something that would
prevent this from working, but I thought I'd throw it out as a concept..
..kg..
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:44 EDT