cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1218
Views
0
Helpful
6
Replies

Twice NAT configration does not make sense

I am reading my CCNP Firewall guide and attempting the understand twice NAT. It described a scenario where twice NAT is used to resolve the condition of overlapping IP ranges as follows:

setup.png

For the most part I understand the setup. The ASA is "tricking" the network on the left that the network on the right is 192.168.10.0/24 and conversely it is tricking the network on the right that the network on the left is 192.168.20.0/24.

However the matching criteria seems to be that if something is from 10.0.0.0/24 going TO 10.0.0.0/24 then translate the source and destination:

Add NAT Rule.png

INSIDE-SEGMENT and PARTNER-VPN-SEGMENT are the same. So in essence NAT will only take place if a packet is coming in on the inside interface (from 10.0.0.0/24) and going out on the outside interface (to 10.0.0.0/24). But in my mind this makes no sense - nothing would match that criteria. If a local host needs to go to something on its local network it will clearly not send it to its default gateway (the firewall). it will use ARP and L2 to get to the destination. Clearly the host in the original diagram above is going to be sending a packet to the 192.168.20.0/24 network. But there are no criteria for that source/destination combo...

I hope this makes sense. Please help if you can. Thanks in advance.

The CLI code (from the book) is as follows:

object network PARTNER-VPN-NAT-INBOUND

subnet 192.168.20.0 255.255.255.0

!

object network PARTNER-VPN-NAT-OUTBOUND

subnet 192.168.10.0 255.255.255.0

!

object network PARTNER-VPN-SEGMENT

subnet 10.0.0.0 255.255.255.0

!

nat (inside,outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND

destination static PARTNER-VPN-SEGMENT PARTNER-VPN-NAT-INBOUND

1 Accepted Solution

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Is the above CLI format configuration truly from the CCNP book? I have not yet read that myself but if it is then its wrong.

The "destination" parameters, in other words the "object" are the wrong way around.

The general format of the "nat" command for Manual NAT is

nat (sourceint,destint) source static destination static

So in the example situation the overlapped networks would be handled on a single device though usually I prefer to have the remote site do a NAT for their side so that I wont have to resort to these NAT configurations I consider a bit special.

So in your example the configuration should be

nat (inside,outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND

destination static  PARTNER-VPN-NAT-INBOUND PARTNER-VPN-SEGMENT

The traffic flow from the local internal network would go like this

  • local 10.0.0.x to remote 192.168.20.x
  • remote 192.168.20.x UN-NAT to remote 10.0.0.x
  • local 10.0.0.x NAT to local 192.168.10.x
  • Packet matches Crypto ACL (source 192.168.10.x destination 10.0.0.x) and traffic sent to VPN or the VPN negotiaton starts and traffic forwarded to VPN

Hope this helps

- Jouni

View solution in original post

6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Is the above CLI format configuration truly from the CCNP book? I have not yet read that myself but if it is then its wrong.

The "destination" parameters, in other words the "object" are the wrong way around.

The general format of the "nat" command for Manual NAT is

nat (sourceint,destint) source static destination static

So in the example situation the overlapped networks would be handled on a single device though usually I prefer to have the remote site do a NAT for their side so that I wont have to resort to these NAT configurations I consider a bit special.

So in your example the configuration should be

nat (inside,outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND

destination static  PARTNER-VPN-NAT-INBOUND PARTNER-VPN-SEGMENT

The traffic flow from the local internal network would go like this

  • local 10.0.0.x to remote 192.168.20.x
  • remote 192.168.20.x UN-NAT to remote 10.0.0.x
  • local 10.0.0.x NAT to local 192.168.10.x
  • Packet matches Crypto ACL (source 192.168.10.x destination 10.0.0.x) and traffic sent to VPN or the VPN negotiaton starts and traffic forwarded to VPN

Hope this helps

- Jouni

Hi,

By the way, isnt the configuration on the ASDM screen capture in the right order?

I don't personally use ASDM for configurations. Pretty much only to check logs and perhaps do some VPN related configurations changes.

EDIT: Think I'll check ASDM on my own ASA just to be sure.

- Jouni

Nevermind,

I missunderstood the ASDM screencapture. Its wrong also, same as the CLI

- Jouni

It is taken from Pages 370 to 373 of CCNP Security FIREWALL 642-618 Official Cert Guide. Everything is either a screenshot or copy/paste.

I agree with your answer. It makes much more sense in my head. A host on the local LAN with be sending TO 192.168.20.0/24 and that is what the criteria should be matching.

Thanks for your help.

I will flag it in the my notes and make sure I test it in GNS3 once I finish the chapter.

Hi,

I think they usually release the correct information for the printed Certifications books.

Seems that the correction to your above problem is included in the file found below

http://www.ciscopress.com/store/ccnp-security-firewall-642-618-official-cert-guide-9781587142710

Check the tab  "Updates" where you should be able to download the list of information that was wrong in the book and the correct informatio.

Hope this helps

- Jouni

Correction from the Official Document

 

Pg

Error

Correction

372

Chapter 7, add paragraph under Figure 7-53

 

Add paragraph:

 

In the Match Criteria section of the dialog box, specify the inside interface and object INSIDE-SEGMENT as the source information for this twice NAT rule. Select the outside interface as the destination interface.

372

Chapter 7, add last sentence to paragraph 2

 

 

Add last sentence:

This completes the configuration of translation for your internal network.  You must now configure the translation for the partner network.

372

Chapter 7, remove third paragraph and replace with new paragraph

 

Replace with:

Because the partner network uses overlapping addressing to your own, it is also necessary to translate the destination address in packets. For instance, if one of your inside hosts were to attempt to send packets to the destination address 10.0.0.50, it would be considered local segment traffic, and would not be routed to the ASA as the default gateway for the inside host. Therefore, inside hosts must use a destination address which requires routing the packet to the ASA, which will then translate that address into the corresponding 10.0.0.0 address used on the partner network.

You have decided to use the network address 192.168.20.0/24 to represent the partner network.  This means that internal hosts will use that address space as the destination address in packets intended to be transmitted to the partner site.  Because this network is non-local, internal hosts will route such packets to the ASA, where they will have their destination address translated to the actual 10.0.0.0/24 addresses in use at the partner site.  They will then be sent across the VPN tunnel, having had both source and destination addresses translated.

Therefore, using procedures already demonstrated, in the Destination Address field within the Match Criteria section of the dialog box, create and assign a new object named PARTNER-VPN-NAT-INBOUND, defined as the network 192.168.20.0/24.

Finally, to specify the translated destination address for selected packets, using procedures already demonstrated, in the Action section of the dialog box, create and assign a new network object named PARTNER-VPN-SEGMENT, defined as the network 10.0.0.0/24, in the Destination Address field. These settings are shown in Figure 7-53.

 

372

Chapter 7, Figure 7-53, Figure incorrect

Remove figure and replace

Replace with:

 

 

 

373

Chapter 7, Last Nat command

Reads:

Nat (inside, outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND destination static PARTNER-VPN-SEGMENT PARTNER-VPN-NAT-INBOUND

Should read:

 

Nat (inside, outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND destination static PARTNER-VPN-NAT-INBOUND-PARTNER-VPN-SEGMENT

373

Chapter 7, Insert paragraph before  - Configuring Translations Using Manual NAT After Auto NAT

Add:

 

Note the order of objects in the nat command generated by this configuration.  While the source objects are listed in the order real, then mapped, the destination objects are listed in the order mapped, then real.  This is because the original source packets generated by internal hosts would have the real source, and mapped destination IP addresses in them, prior to translation.  Following translation, it has the mapped source, and real destination IP addresses.  Thus, the pre-translation objects are both listed first, and the post-translation objects second, in each section of the command.

 

Pg

Error

Correction

372

Chapter 7, add paragraph under Figure 7-53

 

Add paragraph:

 

In the Match Criteria section of the dialog box, specify the inside interface and object INSIDE-SEGMENT as the source information for this twice NAT rule. Select the outside interface as the destination interface.

372

Chapter 7, add last sentence to paragraph 2

 

 

Add last sentence:

This completes the configuration of translation for your internal network.  You must now configure the translation for the partner network.

372

Chapter 7, remove third paragraph and replace with new paragraph

 

Replace with:

Because the partner network uses overlapping addressing to your own, it is also necessary to translate the destination address in packets. For instance, if one of your inside hosts were to attempt to send packets to the destination address 10.0.0.50, it would be considered local segment traffic, and would not be routed to the ASA as the default gateway for the inside host. Therefore, inside hosts must use a destination address which requires routing the packet to the ASA, which will then translate that address into the corresponding 10.0.0.0 address used on the partner network.

You have decided to use the network address 192.168.20.0/24 to represent the partner network.  This means that internal hosts will use that address space as the destination address in packets intended to be transmitted to the partner site.  Because this network is non-local, internal hosts will route such packets to the ASA, where they will have their destination address translated to the actual 10.0.0.0/24 addresses in use at the partner site.  They will then be sent across the VPN tunnel, having had both source and destination addresses translated.

Therefore, using procedures already demonstrated, in the Destination Address field within the Match Criteria section of the dialog box, create and assign a new object named PARTNER-VPN-NAT-INBOUND, defined as the network 192.168.20.0/24.

Finally, to specify the translated destination address for selected packets, using procedures already demonstrated, in the Action section of the dialog box, create and assign a new network object named PARTNER-VPN-SEGMENT, defined as the network 10.0.0.0/24, in the Destination Address field. These settings are shown in Figure 7-53.

 

372

Chapter 7, Figure 7-53, Figure incorrect

Remove figure and replace

Replace with:

 

 

 

373

Chapter 7, Last Nat command

Reads:

Nat (inside, outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND destination static PARTNER-VPN-SEGMENT PARTNER-VPN-NAT-INBOUND

Should read:

 

Nat (inside, outside) 3 source static INSIDE-SEGMENT PARTNER-VPN-NAT-OUTBOUND destination static PARTNER-VPN-NAT-INBOUND-PARTNER-VPN-SEGMENT

373

Chapter 7, Insert paragraph before  - Configuring Translations Using Manual NAT After Auto NAT

Add:

 

Note the order of objects in the nat command generated by this configuration.  While the source objects are listed in the order real, then mapped, the destination objects are listed in the order mapped, then real.  This is because the original source packets generated by internal hosts would have the real source, and mapped destination IP addresses in them, prior to translation.  Following translation, it has the mapped source, and real destination IP addresses.  Thus, the pre-translation objects are both listed first, and the post-translation objects second, in each section of the command.

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card