Static NATS on FWSM Contexts

[sidcracker]

Hello,

Resposting this since no replies were recieved for the earlier post

I am just designing a solution where a FWSM consists of 2 contexts initially and has a shared outside interface pointing to the 6500 switch. There are 3 subnets connected to each of the FWSM contexts. So if anyone wants to access these 6 subnets then a route would be needed pointing to the interface vlan of the shared interface on the switch. But that would not be enough to access the subnets.. I am sure we have to define static NATS to point them to the right context where these subnets reside.

The FWSM is running version 3.x code

So say 1.1.1.0(shared), 10.10.0.0(inside1), 10.20.0.0(inside2) and 10.30.0.0(inside3) reside in Context 1 and

1.1.1.0(shared), 20.10.0.0(dmz1), 20.20.0.0(dmz2) and 20.30.0.0(dmz3) reside in Context 2

in each of the context we would have to make three static NATS

static(inside1,shared) 10.10.0.0 10.10.0.0 netmask 255.255.255.0

static(inside2,shared) 10.20.0.0 10.20.0.0 netmask 255.255.255.0

static(inside3,shared) 10.30.0.0 10.30.0.0 netmask 255.255.255.0

The same would go for context 2 as well

static(dmz1,shared) 20.10.0.0 20.10.0.0 netmask 255.255.255.0

static(dmz2,shared) 20.20.0.0 20.20.0.0 netmask 255.255.255.0

static(dmz3,shared) 20.30.0.0 20.30.0.0 netmask 255.255.255.0

By creating these NAT statements, would the outside users be able to access the subnets residing in the context?

Thanks

[mirober2]

Hello,

Yes, that config should work for you (assuming your ACLs allow the traffic). The requirement is that you create static statements for each of the networks that will exist behind each context, so the FWSM's packet classifier knows which context to send the packet to when it arrives on the shared outside interface.

More details about the classifier and these requirements can be found here:

How the FWSM Classifies Packets:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/contxt_f.html#wp1124172

Sharing Interfaces Between Contexts:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/contxt_f.html#wp1124236

Give it a try and let us know if you run into any issues.

-Mike

[vmilanov]

Looks fine, just do not forget to install the backward route within each of the context toward the shared interface, and, that FWSM, as opposed to ASAs, requires access-lists to be applied on the interfaces with higher security-level as well, not only to those with lower security-level. Otherwise it would not pass traffic.

HTH

Vasil

[sidcracker]

Hello

Thanks for your responses Mike and Vasil. I have a couple of urgent questions more in terms of design and architecture. I have provided the solution of shared interafces (instead of two different links from the contexts to the FWSM/Switch, just using one link - same subnet). I am not very sure if the shared interfaces design would actually work for them.

One question i have on implementing shared interfaces, if there are static nats created on the fwsm for example (shared,vlan10) and (shared,vlan11) for processing traffic to the respective context, then

How would you create static nats on virtual context 2 for internet traffic?

Can we still have a default route pointing towards VLAN 14 towards the Internet?

Is there any better ways but less complex ways of doing it?

I have other alternatives like sticking to just one context instead of multi context as anyway vlans need to access other contexts (see below)

I have attached a diagram of how they want the solution  to be implemented.

The following are required

1. VLAN 10 and 11 should be able to access VLAN 12 and 13 in the other context

2. Traffic from the IP VPN cloud should be able to access VLAN 14 and out to the Internet

3. A default route will be on the FWSM to go towards VLAN 14 to the Internet

Thanks

[vmilanov]

Hi,

Reasonable questions you have. But, IMHO, you have stick with rather complex design (with the shared interface and so on), which would virtually bring no benefits by itself.

If there is no explicit reason for using shared interface, I would get rid off it:

1. segregate the shared vlan into 2 vlans, each dedicated/allocated to a particular FW context.

Thus FW would classify packets based on the vlan membership explicitly and will not use NAT records for this purpose.

2. issue 'no nat-control' within each context, so that the traffic not requiring NAT can pass without having explicit NAT translations. I don't see any benefits of having nat-control, even as a security feature, because any security control you can have with it can be achieved with the interface ACLs either, and even more.

3. Configure explicit NAT translations only for the traffic required to be NAT-ed.

As for the routing, yes, you can have the 0.0.0.0/0 record in the FW's context, but then you have to configure explicit routes back toward the IP VPN or any other particular network of interest. In FWSM still, the more particular is a route, the higher precedence it has over less particular ones (and 0/0 is at the bottom of this order).

Back to your question about NAT in context 2:

- It is not clear from your post, if the traffic to vlan14 shall be NAT-ed or not but this gives two options - NAT exemption (no nat), or to have NAT, and further,

- two more options regarding the translation types - either dynamic NAT, or static NAT. Dynamic NAT would not allow outside to inside traffic to create a nat translation for a connection, but only inside-to-outside. Thus outside originated conns are not allowed. As opposed, static NAT allows translation creation for a connection to be made when it originates from either interface.

So, if you have to have NAT exemption:

Dynamic - 'nat (shared) 0 0.0.0.0 0.0.0.0', or nat (shared) 0 10.0.0.0 255.0.0.0', or 'nat (shared) 0 access-list ', where the access-list ACL-NAME denotes traffic you would like to have nat-excluded

Static - 'static(shared,vlan14) 10.0.0.0 10.0.0.0 netmask 255.0.0.0' for an example is a static NAT exemption, where all source ips from network 10./8 remain unchanged.

If you have to NAT the traffic, it is a rare case when you can fit the whole inside network 1:1 into a global network statically, so in the most cases it would be a dynamic NAT:

'global (vlan14) 14 interface', or 'global (vlan14) 14 ', and,

'nat (shared) 14 10.0.0.0 255.0.0.0' for an example.

So, in few words it is a rather complex case, where you shall track the interface pairs, between which traffic flows, NAT policy you would like to achieve, and NAT order of operation, as documented.

HTH,

Vasil

[sidcracker]

Hello Vasil,

Thank you so much for your reply and taking the time out to draft an explanation. This has become much clearer now. I can now go back and provide two solutions - one to retain the single context and the other as a multi context VLAN without shared interfaces

Thanks