Hierarchical contexts - how?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-18-2005 09:04 AM - edited 03-09-2019 10:02 AM
We have been battling to configure a FWSM with multiple contexts. The attached drawing shows this muchly simplified, in which a context labelled "External" is connected to the Internet on its outside interface and an intermediate DMZ LAN on VLAN 900/interface inside. Also connected to VLAN900/interface outside are other internal contexts providing access to internal services. The drawing indicates one of these being a VIP on a content switch at 192.168.15.140.
The intention is that the web server VIP at 192.168.15.140 should be available to devices in VLAN 900 (i.e. there may be multiple "internal" contexts) at a NATted address of 10.224.0.140. Clients in the outside world should see the VIP at a NATted address of 100.100.100.140.
All of the routing is working, and we are fairly certain the access-lists are properly formed. Each context is configured with an appropriate static as shown in the figure, but there is no connectivity. The external context identifies incoming connection requests and shows xlates being formed, then tears them down due to FIN timeouts. The internal context never sees any incoming request.
You can ping from the external context to the 10.224.0.140 translated VIP address on the internal context.
We can't seem to get "debug packet" or "capture" commands to show any related traffic on VLAN 900.
Does anyone have any idea why we are seeing these issues? Is this context hierarchy fundamentally flawed for some reason?
- Labels:
-
Other Security Topics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2005 11:37 AM
Sorted it now, thanks.
