One way traffic in IPSec

[Eduard A.]

Let me start with this statement I've red:

“The main difference between identity NAT and NAT exemption is that with identity NAT, the traffic must be sourced from the address specified with the nat 0 statement, whereas with NAT exemption, traffic can be initiated by the hosts on either side of the security appliance. NAT exemption is a preferred method to bypass traffic when it is flowing over a VPN tunnel.”

is that correct? my issue of which i've been dealing for three weeks now, we have a main ASDM and three sites with FTD connected to it via S2S VPN, and Remote Access VPN via anyconnect. Sometimes when the tunnel is already up i check the ipsec sas to each tunnel and obviously they are not complete (some subnet pairs are missong, i presume this is normal because no traffic were generated between(?)), but if i generate some traffic say ping i cannot trigger an ipsec sa to that tunnel anymore, is that also normal? 

[Gustavo Medina]

wow that statement takes me back in time... it refers only to NAT behavior pre 8.3.

Today for NAT exemption you use Manual NAT. 

For your issue:

SAs will get created based on traffic, even if they are up but at the time of rekey there is no traffic going through they will go down.

That being said, the ping you do to trigger the SA must match the Proxy IDs for that SA to bring it up. A common mistake is just doing a ping without the source interface (e.g just ping x.x.x instead of ping inside x.x.x.x).

If your interfaces do not match the subnets you are testing with, then an easy option to trigger the SAs is with packet-tracer and simulate the source and destination you want.

-Gustavo

[Eduard A.]

What do you mean by proxy id in this particular situation?. What I did to troubleshoot is match everything about IKE and IPsec first, for a faster smoother isolation. After that, problem still exist, whether I am generating https or ping traffic and whether this comes from a computer at an S2S site or a computer with a Remote VPN client, I can't trigger an SA for a particular subnet. But if I set a continous ping to all the subnets I'm interested in and issue the clear crypto ipsec sa peer command on the ASDM everything between the site im in and the site im pinging works fine.

[Cristian Matei]

Hi,

    1. If you use FTD, FTD uses the new NAT architecture of the ASA, the one after 8.3 code.

    2. In general, VPN traffic is exempted from NAT, and this is done through twice-NAT rules, where you configure static identity NAT for both source and destination (there is no more NAT exempt). VPN traffic has to be NAT'ed when there is overlapping subnets (protected subnets are identical, like 10.10.10.0/24 on both sides), i which case you configure static NAT for both sides. If for whatever reason you want to NAT your VPN traffic, you can do it. What you need to remember is that form an order of operation perspective, NAT happens before encryption, does the encryption domain has to match on the NAT'ed addresses.

  3. As for NAT exempt vs identity NAT in before 8.3 code, identity NAT means there are translations being done, but into itself, and if these are static (Static statements), traffic can be initiated both ways, as long as other firewall policies (like ACL/ACP, security level, security zones) also allows the traffic; if these are dynamic (nat 0 statements with no matching global) can only be initiated one way. NAT exempt was only for VPN traffic, and because traffic was not NAT'ed, likewise traffic could be initiated both ways, as long as other firewall policies allow it as well.

Regards,

Cristian Matei.

[Eduard A.]

Thanks for your reply also. My keyword on your statement is "likewise" for the identity and nat exempt. I am attaching my FTD devices version and the option it has for nat exemption (this is under S2S config). Now as per identity nat or twice nat as you say, we have all that in place, interestingly I already run a packet tracer on an FTD which have a problematic subnet (one that is included on the ipsec sas when the tunnel went up, and cant create/trigger its ipsec sa), the packet is being drop at phase 9 which a nat, a nat supposedly hitting the identity nat but its hitting the nat (dynamic interface) for internet connection. For the other subnet that successfully created an ipsec sa over the tunnel im pretty sure they are hitting the correct nat. What do you think could cause this?

[Eduard A.]

Correction: *(one that is ""NOT"" included on the ipsec sas when the tunnel went up, and cant create/trigger its ipsec sa)