Question about FTD order of operations with IPSEC and NAT.

[Joebananas]

Hello,

I am confused about what I am seeing based on other posts/documentation and what I see in packet-tracer.

Example:

Example:

----Objects----

object-group network LOCAL

 network-object 10.1.1.0 255.255.255.0

object-group network LOCAL-NAT

 network-object 10.2.2.0 255.255.255.0

object-group network REMOTE-NAT

 network-object 20.20.20.0 255.255.255.0

object-group network REMOTE

 network-object 192.168.1.0 255.255.255.0

----NAT----

nat (INSIDE,OUTSIDE) source static LOCAL LOCAL-NAT destination static REMOTE-NAT REMOTE

----Crypto ACL----

access-list vpnacl extended permit ip object-group LOCAL-NAT object-group REMOTE

When I do a packet tracer (packet-tracer input inside icmp 10.1.1.1 8 0 20.20.20.1) I am seeing that UN NAT (Destination 10.1.1.1 to 10.2.2.2) happens, then NAT (20.20.20.1 to 192.168.1.1) THEN VPN phase occurs which makes sense....since this is how the crypto map is written. (permit ip 10.2.2.2 to 192.168.1.1)

When I do a packet tracer from the other direction (packet-tracer input outside icmp 192.168.1.1 8 0 10.2.2.1) I see that again, UN NAT happens (destination 10.2.2.1 to 10.1.1.1) and then again, NAT (source 192.168.1.1 to 20.20.20.1) . At what point, if the remote end initiates traffic to create a new tunnel, does the VPN phase happen? I don't see it in my packet tracer. The logic here says the VPN ACL would not match since inside > out NATS first then matches VPN ACL, but seems outside > in also NATS first then VPN which then does not match the acl but the tunnel passes traffic fine....but I am not sure what to make of this.Can someone help explain this?

Additionally, I've seen documentation that says if you were to add an access policy, it lands between UN NAT and NAT. Again, how would this work in the reverse direction? If I were to write an access policy from inside> out perspective I would write:

permit ip 10.1.1.1 192.168.1.1(UN NAT)

but if coming in from the outside, the packet would be

src 20.20.20.1 dst 10.2.2.1 when the access policy hits and following the UN NAT happening first the Access policy entry would have to be 20.20.20.1 to 10.1.1.1? (UN NAT) Is this right?

Can someone shed some light on this please?

[Sheraz.Salim]

When you check from the inside of your network, first, the destination of the data is changed (UN-NAT), and then the source gets changed (NAT). This happens because the inside of your network is where the address changes are set up. After that, the data is secured with a VPN.

If you check from the outside, it's the opposite. First, the source address is changed (NAT), and then the destination gets changed (UN-NAT). This is because the outside is where the VPN tunnel is set up. After these address changes, the data is encrypted for the VPN.

The VPN rules are applied after the address changes. This means that to use the VPN tunnel, the data must match the rules. In your case, the rules say it's okay for data from the LOCAL-NAT network to go to the REMOTE network.

So, when data starts from the inside, its destination address is changed, it matches the VPN rules, and it goes through the tunnel. When data starts from the outside, its source address changes, but it doesn't match the VPN rules, so it doesn't go through the tunnel.

The access rules come into play after the destination address has been changed (UN-NAT). This means that to pass through your firewall, the data must match these rules too. In your case, the rules say it's okay for data from the 10.1.1.0/24 network to go to the 192.168.1.0/24 network.

So, when data starts from the inside, its destination address is changed and matches the access rules, so it goes through your firewall. When data starts from the outside, its source address changes, and it also matches the access rules, so it goes through your firewall.

 For Firepower Threat Defense the order of operations for NAT and VPN(FTD)

1. Unified NAT. This is the first NAT that occurs, and it is applied to the traffic before it is encrypted by the VPN. The destination address of the traffic is translated to the NAT pool address, and the source address is left unchanged.
2. VPN encryption. The traffic is encrypted according to the crypto map.
3. NAT. This is the second NAT that occurs, and it is applied to the traffic after it is encrypted. The source address of the traffic is translated to the NAT pool address, and the destination address is left unchanged.

[Joebananas]

Hello Sheraz,

Thank you for the response.

Are you sure that those order of operations are correct? What you posted seems to contradict how the crypto map is written and contradicts what I see in my packet-tracer tests.

When you write a crypto map ACL, you write it based on the destination and source nat already having occured. The VPN encryption comes after that. So UN NAT, NAT, VPN.

According to this order of operations I have found below this is what I think happens in both directions:

Initiating from inside out

Src: 10.1.1.1

Dst 20.20.20.1

1.Decrypt (Not applicable)

2. UN NAT (packet becomes src 10.1.1.1 dst 192.168.1.1)

3. Access policy and ACL

4. NAT (packet becomes src 10.2.2.1 dst 192.168.1.1)

5. VPN encryption

6. Route

From Outside in:

src 192.168.1.1

dst 10.2.2.1

1. decrypt (matches ACL for decryption I think?)

2. Un nat (packet becomes src 192.168.1.1 dst 10.1.1.1)

3.Access policy and ACL

4.NAT (packet becomes src 20.20.20.1 dst 10.1.1.1)

5. Encrypt(Not applicable)

6.Route normally to inside network

 Please let me know if I am misunderstanding.

[Sheraz.Salim]

@Joebananas no your understand is right. Even I have to go back and double check my understanding regarding to the flow of VPN NAT. My apologies for not providing you the correct information. while I have to look into the flow of the packet tracer tool. I also noted if you put decrypted at the very end of the packet tracer it will break it down the flow its going through fromt the vpn tunnel. In my case the VPN-Tunnel is up and running and it did packet tracer from inside to outside and from outside to inside.

packet-tracer input outside tcp x.x.x.x ssh y.y.y.y 443  decrypted  detailed

[Joebananas]

Thank you!