IPSEC two Consecutive NAT attempts Failure

[Aaron_un]

I am the Network On the left hand side(FW1 and R1), and FW1 Outside int IP is a nat from R1(so I need to enable NAT-T on FW1 for that).

I can reach behind the FW3 as long as it does not nat the IP that I am trying to reach, due to the IP limitations to many vendors that they have, they have to nat certain IPs behind the FW3, so basically I can reach any IPs behind FW3 as long as not Natted by FW3.

As soon as FW3 nat that IP, I can't reach it anymore....

From what I understand this should be a HW limitation, if you nat the source on FW1 once, and after packet reaches the other end of the tunnel, and the packet destination address become Natted as well(that should somehow compromise the integrity of the packet), I can't reach it anymore or maybe receive the packet that I sent anymore....

is there some obvious mistake that I am doing here, all routes are correct btw, and I am doing NAT exempt(Twice NAT) on FW1, and FW2...

If the FW1 doesn't do PAT overload and instead use the real source subnet, I can reach the destination behind the FW3 even if it's Natted.

Again I can reach the IP behind the FW3, as long as either I don't Nat(pat overload many to 1) the packet before sending it over the tunnel from FW1, or the other end(FW3) not nat(static 1 to 1) the destination IP of the packet.

In other word, as long as one party do the nat it works, if we both nat the packet, it stops working...

no need to mention tunnel is up all the time..

Note: I did not include all the IPs I am using inside of the diagram, and those IPs are random, but I think I pretty much explained it all...

[Aaron_un]

.....

[Rob Ingram]

Hi @Aaron_un 

Please can you confirm what hardware you are using, FTD or ASA?

How are you testing the VPN? From a device connected behind FW1 or from FW1 itself?

Are the IKE/IPSec SA formed?

If you are natting does the crypto map reflect the natted ip address?

[Aaron_un]

Both ASA

Behind the firewall(not the firewall)

Yes, Tunnel is formed, both Phase 1 and 2

Yes

[Rob Ingram]

@Aaron_un 

Can you please provide the output of "show crypto ipsec sa" from both ASAs.

Can you run packet-tracer from the CLI on both ASA and upload the output.

[Aaron_un]

packet tracer you mean, capturing the packets? or run a trace, cause the trace doesn't show anything, since the other(right) firewall hasn't configed to allow the hops for trace(my jurisdiction is the left side, I have no control over the right, but I saw the config today)...

[Rob Ingram]

@Aaron_un 

No, the packet-tracer command allows you to simulate the traffic flow and allows you to evaluate how the existing routing configuration, NAT rules, and policy configurations, affect that packet. Example syntax:-

packet-tracer input <source interface> <protocol> <source IP> <source port> <destination IP> <destination port> [detailed]

Provide the output with and without NAT configured to compare.

[Aaron_un]

sorry my mistake, yes I know this, yes again obviously it passes this step,

INSIDE

UP

UP

OUTSIDE

UP

UP

Action: allow

[Aaron_un · Accepted solution]

sorry everyone there was a mistake on FW2(the other vendor) and I forgot to update the community lol, it was not related to nat at all!

so this is how ASA algorithm does the matching process with peers which is kind of odd

it first goes over the subnets(Interesting traffic ACL) that are going to be encrypted over each tunnel and then the peer/tunnel addresses itself,

where in reality it has to go first over the peer address(which is more unique) and then the subnets/hosts inside of the tunnel, which can make things easier to manage and easier to expand.

so if you have e.g. many IPsec tunnels, you should look close at not having colliding subnets with different peers..

or if you have no control over the firewall at the remote location like my case, if you e.g. using the tunnel to encrypt the traffic for many to one(n:1) like I did, so I was in reality encrypting only one address over the tunnel, 10.1.1.1/32, you have to make sure that the other end does not have a tunnel with another remote location that they are encrypting their whole 10.0.0.0/8 addresses over the tunnel!

Because that way they will need to accordingly readjust the crypto map placement manually,

ASA does not go from most specific to least specific,

unfortunately it does not go over the peer address first and then the encrypted traffic either which is kinda joke to me!