Reverse NAT on ASA 8.3+

pascal · ‎02-06-2014

I'm trying to migrate from a PIX to an ASA but the new NAT commands are driving me nuts. I got most of it working but I still can't figure out my reverse NATs. On the PIX the command is:

static (outside,inside) tcp 1.1.1.1 bgp 2.2.2.2 bgp netmask 255.255.255.255

Where 1.1.1.1 is the old IP, the one devices are sending traffic to, and 2.2.2.2 is the new IP, the one the traffic actually needs to goto.

What is the equivilant ASA 8.3+ command?

Jouni Forss · ‎02-06-2014

Hi,

So seems that this is a Static PAT essentially.

Seems to me that you should be fine with

object network STATIC-PAT-BGP

host 2.2.2.2

nat (outside,inside) static 1.1.1.1 service tcp bgp bgp

Hope this helps

- Jouni

pascal · ‎02-06-2014

That is what I have, and that does not work. Thank you for trying though.

Jouni Forss · ‎02-06-2014

Hi,

The configuration should be the exact replication of the original configuration you mention.

The problem might be in some other "nat" configuration causing problems or even an ACL.

You can test that the NAT rule is matched with the "packet-tracer" command

packet-tracer input inside tcp 12345 1.1.1.1 bgp

Is the 1.1.1.1 IP address configured on the "inside" interface itself or is it some NAT IP address that is not configured on any interface directly?

- Jouni

pascal · ‎02-06-2014

Neither IP is configured on the ASA or in any subnet the ASA is in. Output of the packet-tracer command is below. The source IP appears to be being PAT'd correctly but the destination IP is not being modified.

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside in interface inside

access-list inside extended permit ip any any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

object network obj-192.168.0.0

nat (inside,outside) dynamic 3.3.3.3

Additional Information:

Dynamic translate c4510/12345 to 3.3.3.3/12345

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 135567453, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

Jouni Forss · ‎02-06-2014

Hmm,

You might need a Manual NAT configuration that does NAT for both source and destination in a single "nat" command

Maybe this might work

object network SOURCE

host

object network SOURCE-MAPPED

host 3.3.3.3

object network DESTINATION-MAPPED

host 1.1.1.1

object network DESTINATION

host 2.2.2.2

object service BGP

service tcp destination eq bgp

nat (inside,outside) source dynamic SOURCE SOURCE-MAPPED destination static DESTINATION-MAPPED DESTINATION service BGP BGP

See if the below explanation of the behaviour of the above command fits your requirement.

The above configuration looks for traffic from SOURCE to DESTINATION-MAPPED with the destination port BGP and NATs the SOURCE to SOURCE-MAPPED and UN-NATs the DESTINATION-MAPPED to DESTINATION.

- Jouni

pascal · ‎02-06-2014

When I run the packet-tracer with a nonsense internal IP then the destination NAT is correctly applied. So it looks like the ASA doesn't bother with the destination NAT if the packet matches a source PAT rule.

Jouni Forss · ‎02-06-2014

Hi,

The earlier "packet-tracer" output you shared with us shows a Section 2 Auto NAT being applied to the source address.

The above configuration should match the traffic I described before that Section 2 Auto NAT as this is a Section 1 Manual NAT. You should see the destination UN-NAT at the very start of the output.

Naturally I did not add the line number to the above command so it would be in the end of Section 1 Manual NAT and might still be possible that other NAT rules might be matched before it.

To add it at the top you could have added it like this

nat (inside,outside) 1 source dynamic SOURCE SOURCE-MAPPED destination static DESTINATION-MAPPED DESTINATION service BGP BGP

Also, now that I think of it, if you are doing NAT for 2 Routers for BGP and we are not talking about using interface addresses as NAT addresses then I think you could even loose the "service" section of the command and also make it a Static Policy NAT (for both source and destination) and just open the services you need

nat (inside,outside) 1 source static SOURCE SOURCE-MAPPED destination static DESTINATION-MAPPED DESTINATION

- Jouni

pascal · ‎02-06-2014

There are multiple sources that all need to be PAT'd to the outside IP of the ASA, as happened in phase 5 of the above packet-tracer.

Jouni Forss · ‎02-06-2014

Hi,

The original configuration only had a Static PAT configuration and no Dynamic PAT mentioned.

If you want to match a source translation and destination translation for certain connections then you generally have to configure it as Manual NAT.

In the Manual NAT with the Dynamic PAT configuration I only suggested adding a single host IP address to the source addresses. I guess you would have to substitute that with a "subnet" if you are doing Dynamic PAT for several sources.

object network SOURCE

subnet

object network SOURCE-MAPPED

host 3.3.3.3

object network DESTINATION-MAPPED

host 1.1.1.1

object network DESTINATION

host 2.2.2.2

object service BGP

service tcp destination eq bgp

nat (inside,outside) 1 source dynamic SOURCE SOURCE-MAPPED destination static DESTINATION-MAPPED DESTINATION service BGP BGP

If the above doesnt match the connection coming from "inside" to "outside" so that both source and destination have NAT applied then there either must be an error in the IP addresses used, this doesnt match the requirements of the connections or there is some bug.

To be honest its hard to say without seeing any configurations.

There is no clear reason why the above Manual NAT should not match traffic going from "inside" to "outside". Though maybe if you are running a software that is 8.4(2) or below there might actually be some problem regarding the "nat" behaviour. On the software 8.4(5) for example this should work just fine.

- Jouni