I want to create two security contexts on my pix. But I want to share the same (outside) interface. Do you have an example of how to do that. Can the outside interface have the same ip address in both contexts?
i am sure that is possible although i am not sure why you would want that. the pix is designed for 2 ISP on the 'outside'. you would just create an interface to be 'inside2' and make sure your route inside has a higher cost.
There is a video/booklet from Cisco Press, by David Huckaby, it is called "Cisco Firewall Video Mentor" ... it describes how to set that up, and says that you can share an interface. But he doesn't go into detail on what you might do on the outside, such as sharing the same IP.
He cautions that issues may arise if they also share a MAC address, as the firewall itself may become confused about how to track packets for proper delivery.
Apparently, newer software such as what's available on the ASA can create unique MAC addresses for each instance of the same interface to avoid this problem. But some older platforms can't do it. So you might have issues there.
I wondered too, if two contexts did share an interface and also the IP, but would that mean that each context sees the same packets?
If so, I should think that you'd have to be careful that one context handled what the other context didn't, and vice verse, without ambiguity.
The two examples that Huckaby gives are a situation where you have several internal departments that are capable of managing their own firewall, and a case where you sell the firewall instances to clients, which they can administer themselves.
He mentions that they can all share the same interface, and later says they can "share same network on the outside" but unfortunately doesn't elaborate on how or why you'd do such a thing.
brianinms, you may jave guessed that I'm considering doing just that (as well as other things) to solve my current email problem over in the Cisco ASA forum. I'm not at all sure it would work.
razmar, I am curious about what you might want to do with a shared interface/network.
I have an issue where I'm considering multiple contexts.
In a nutshell, I want any inbound SMTP to be forwarded to an internal SMTP server A, except inbound SMTP from a specific network, which I want forwarded to a second internal SMTP server B.
My idea to solve this with multiple contexts would be:
Security context A:
Access List:
1. Deny SMTP packets from Specific_Network
2. Permit SMTP packets from anywhere else
3. all other non-SMTP access rules go here
NAT:
1. Route all SMTP packets to server A
2. other non-SMTP NAT rules go here
Security context B:
Access List:
1. Permit SMTP packets from Specific_Network
2. Deny SMTP packets from anywhere else
NAT:
1. Route all SMTP packets to server B
I'm making a broad assumption here, and that is that both contexts see all of the same packets arriving on the interface that they share. They share both the interface and the outside network.
In other words, for our email problem, both contexts get the same SMTP packets but each deals with one condition or other, in an un-ambiguous way. One context denies what the other context permits.
I've no idea if this would work. I'm hoping for simpler solution (see also the Inbound SMTP issue thread, in the ASA Series forum)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.