Solved: NAT exempt for RFC1918 to RFC1918 traffic (VPN traffic) on ASA 8.4

shamax_1983 · ‎10-16-2012

Hi,

I want to NAT exempt all traffic from inside interface with source address in "RFC1918" to any RFC1918 destination to be NAT exempted. Can I use all 3 IP ranges in one single Object and use as follows:

!

object-group network RFC1918

network-object 192.168.0.0 255.255.0.0

network-object 172.16.0.0 255.240.0.0

network-object 10.0.0.0 255.0.0.0

!

nat (inside,any) source static RFC1918 RFC1918 destination static RFC1918 RFC1918

!

Would this work as exepted OR would this start to do weired things?

Thanks for your input.

Julio Carvajal · ‎10-17-2012

Shamal,

On my last message I said try to avoid the keyword any on the interface nat setup.

That would be my last recommendation on this setup.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

View solution in original post

Julio Carvajal · ‎10-16-2012

Hello Shamal,

Would this work as exepted OR would this start to do weired things?

Option B ;D no doubt.

The ASA will not know where to send the packets if the source and destinations are on different interfaces,etc,etc,etc

Regards,

Any other question..Just remember to rate all the helpful posts.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

shamax_1983 · ‎10-17-2012

Hi jcarvaja,

Thanks for your reply.

So the only way we can do is this (shown below)? Or is there any other easy way.. OR am I doing this all wrong..

object network obj_192

subnet 192.168.0.0 255.255.0.0

object network obj_172

subnet 172.16.0.0 255.240.0.0

object network obj_10

subnet 10.0.0.0 255.0.0.0

nat (inside,any) source static obj_192 RFC obj_192 RFC destination static obj_192 RFC obj_192

nat (inside,any) source static obj_192 RFC obj_192 RFC destination static obj_172 RFC obj_172

nat (inside,any) source static obj_192 RFC obj_192 RFC destination static obj_10 RFC obj_10

nat (inside,any) source static obj_172 RFC obj_172 RFC destination static obj_192 RFC obj_192

nat (inside,any) source static obj_172 RFC obj_172 RFC destination static obj_172 RFC obj_172

nat (inside,any) source static obj_172 RFC obj_172 RFC destination static obj_10 RFC obj_10

nat (inside,any) source static obj_10 RFC obj_10 RFC destination static obj_192 RFC obj_192

nat (inside,any) source static obj_10 RFC obj_10 RFC destination static obj_172 RFC obj_172

nat (inside,any) source static obj_10 RFC obj_10 RFC destination static obj_10 RFC obj_10

Thanks in advance.

Julio Carvajal · ‎10-17-2012

Hello Shamal,

The configuration is good, I have no doubt on that,

The thing is why would you do something like that???

I mean you cannot have same source and destination on a packet, and that is what you are doing with some of the NAT statements you have....

Remembe ro rate all of the helpful posts

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

shamax_1983 · ‎10-17-2012

Hi Julio,

Thanks for that.

This is for a Hub and spoke setup with more than 10 spokes. VPN terminated at Hub site. The RFC1918 ranges are used everywhere without proper planning. For instance, 192.168.1.0/24 , 192.168.100/24 , 192.168.254.248/2 .. etc. in the hub and some other 192.168.168.X/24 ranges on spokes. (this configuration is for the Hub)

So for the VPN to work, I need NAT exemptions. Currently the Nat exemption is based on ASA 8.0 and has about 70 specific ACL lines included in the "nat 0" statement. I am in the process of migrating this to ASA 8.4 and I really want to shrink everything down to few lines.

I know that the statements,

nat (inside,any) source static obj_192 RFC obj_192 RFC destination static obj_192 RFC obj_192

nat (inside,any) source static obj_172 RFC obj_172 RFC destination static obj_172 RFC obj_172

nat (inside,any) source static obj_10 RFC obj_10 RFC destination static obj_10 RFC obj_10

would include overlapping source destination combinations, for example if a packet goes from 192.168.1.22 to

192.168.1.22. But this is not gonna happen and there is no practical reason why a packet wants to do that. But it include all other combinations, for example packet from 192.168.1.22 to 192.168.168.100. which will be a valid hit when spoke.

I also understand that, by using this method, it will allow all RFC1918 traffic and will not have the original "specificity". But doing it this way, we wouldn't have to touch this anymore even if we want to add more subnets.

That's my thinking.

Please let me know if this make sense or I am better off doing it the longer way... are there any drawbacks to this approach

Julio Carvajal · ‎10-17-2012

Hello Shamal,

I do understand the requirement and for VPN to work yes you will need it,

So based on what you have point and the configuration you are good to go.

The NAT configuration is the one required

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

shamax_1983 · ‎10-17-2012

Hi Julio,

Thanks for the quick reply and for the patience.

I didn't get this "The NAT configuration is the one required". Are you saying the originally posted "one liner" is the way to go ? OR I have to use the NAT (with 9 lines) as in my second post.

Thanks so much.

Julio Carvajal · ‎10-17-2012

Hello Shamal,

Okay for VPN purposes with no overlapping networks I will go with the following ( I will use inside, outside . DO not use the keyword ANY)

nat (inside,any) source static obj_192 RFC obj_192 RFC destination static obj_192 RFC obj_192

nat (inside,any) source static obj_172 RFC obj_172 RFC destination static obj_172 RFC obj_172

nat (inside,any) source static obj_10 RFC obj_10 RFC destination static obj_10 RFC obj_10

Regards,

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

shamax_1983 · ‎10-17-2012

Hi Julio,

Sorry I think I have done a serious typo I have addedd additional RFC part everywhere, it should be:

nat (inside,any) source static obj_192 obj_192 destination static obj_192 obj_192

nat (inside,any) source static obj_192 obj_192 destination static obj_172 obj_172

nat (inside,any) source static obj_192 obj_192 destination static obj_10 obj_10

nat (inside,any) source static obj_172 obj_172 destination static obj_192 obj_192

nat (inside,any) source static obj_172 obj_172 destination static obj_172 obj_172

nat (inside,any) source static obj_172 obj_172 destination static obj_10 obj_10

nat (inside,any) source static obj_10 obj_10 destination static obj_192 obj_192

nat (inside,any) source static obj_10 obj_10 destination static obj_172 obj_172

nat (inside,any) source static obj_10 obj_10 destination static obj_10 obj_10

-------------------

Julio Carvajal · ‎10-17-2012

Shamal,

On my last message I said try to avoid the keyword any on the interface nat setup.

That would be my last recommendation on this setup.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

shamax_1983 · ‎12-25-2012

I have finally managed to find the best way to tackle this scenario. I will try to illustrate the general idea behind it.

Lets's say you've got following networks behind inside interface,

192.168.1.0/24

192.168.2.0/24

10.10.1.1/24

10.10.2.1/24

and following subnets either on IPSec VPN branches or on other interfaces on the ASA.

192.168.100.0/24

192.168.200.0/24

10.10.100.0/24

10.10.200.0/24

172.19.100.0/24

And you have Dynamic PAT turned on for the networks living behind the inside interface.

Now lets say you have full range of RFC1918 defined and used it in identity NAT as follows ,

!

object-group network RFC1918

network-object 192.168.0.0 255.255.0.0

network-object 172.16.0.0 255.240.0.0

network-object 10.0.0.0 255.0.0.0

!

nat (inside,any) source static RFC1918 RFC1918 destination static RFC1918 RFC1918

!

In this scenario, your Identity NATs will only work properly if your packets going from

10.10.1.1/24 -> 192.168.100.0/24

10.10.1.1/24 -> 192.168.200.0/24

10.10.1.1/24 -> 172.19.100.0/24

............

.............

but,

10.10.1.1/24 - > 10.10.100.0/24 : WILL NOT WORK

10.10.1.1/24 - > 10.10.200.0/24 : WILL NOT WORK

192.168.1.0/24 -> 192.168.100.0/24 : WILL NOT WORK

192.168.1.0/24 -> 192.168.200.0/24 : WILL NOT WORK

Why?, Because the ASA likes to see the source address and the destination address of the packet in two seperate networks ( or two seperate entries) in the object-group.

The only way I could tackle this scenario is by creating a object group that seperately identifies the networks I want to be "Identity NAT'd" in like this,

!

object-group network ALL_NETS

network-object 192.168.1.0 255.255.255.0

network-object 192.168.2.0 255.255.255.0

network-object 10.10.1.1 255.255.255.0

network-object 10.10.2.1 255.255.255.0

network-object 192.168.100.0 255.255.255.0

network-object 192.168.200.0 255.255.255.0

network-object 10.10.100.0 255.255.255.0

network-object 10.10.200.0 255.255.255.0

network-object 172.19.100.0 255.255.255.0

!

Once all the networks are defined, you can now use the one liner for all Identity NAT's as follows,

!

nat (inside,any) source static ALL_NETS ALL_NETS destination static ALL_NETS ALL_NETS

!

Or you can even use nat(any,any) without any iusses.

!

nat (any,any) source static ALL_NETS ALL_NETS destination static ALL_NETS ALL_NETS

!

I have tested this in ASA 8.4.5 and works fine.

Disclaimer: This may not be Cisco's best practise.

Guys, please don't hesitate to correct any technical info I have mentioned here as I am not a guru in this area..