Manually recreating Tunnels\Cryptomaps

[keithcclark71]

I tried to migrate using the Firewall Migration Tool the settings from ASA 5505 into FMC and it worked great for NAT, ACL, Route, Objects but unfortunately failed on the Site-to-site and vendor tunnel groups and outside crypto maps. 

Has anyone any experience with manually configuring FMC Sitye to Site VPN's based off of settings found on a legacy ASA 5505? I mean if this was ASA gen 1 to ASA next gen migration it be easy cause I could have two asdm's side by side to duplicate settings but here in the FMC it has totally changed 

[Rob Ingram]

@keithcclark71 It's the same principle on the FMC, just a different GUI. Everything is referenced in the VPN topology, you specify your outside interface, the peer IP address, the local/remote networks, IKEv1/IKEv2 settings, PSK and IPSec configuration and deploy. Example here.

If you run "show run crypto" on the ASA you can easily translate that into the FMC configuration.

[keithcclark71]

I think I'm ok with the Site to Site based on the info you provided. Where I am really concerned is it seems there are alot of crypto maps with vendors it seems doing a site to site to HQ but also I think VPN using outside crypto Map to Tail sites through HQ

Im trying to figure out how to read these entries so that I can figure out what i need to do in the FMC . I attached a line at what i am looking at and trying to understand that flow . It appears the local host Audry in attached screenshot is accessing defined host destinations via a vendor tunnel group to the vendors peer IP. I would assume I would create the tunnel to the vendor in the same way that I configure intrasite HQ to Tail Site tunnels.

There  is one in this crypto map (Attachment CryptoMapsA) sourced with NAT Hosts specified with private IP range not local to the ASA and then destined for diff host in private range with a public peer IP. 

If have any thoughts on how I should read these maps to help me get my head straight I'd appreciate it.

[Rob Ingram · Accepted solution]

@keithcclark71 well it looks like you are NATTING the source, in which case define objects for these source addresses on the FMC. Use the objects as the local network in the VPN topology. Create Manual NAT rules, to translate original source to translated source and use the object as previously defined as the translated source. The original and translated destination look the same.

FYI, run "show nat detail" on the FTD (once deployed), the configuration syntax would be the same as the CLI output on the ASA - so that will help you confirm the configuration is ok.

[keithcclark71]

Thanks for the Tip Rob I wish I had yourself and Marvin on this project in real life. Been a struggle but hope tp win in the end

[Rob Ingram]

@keithcclark71 no problem, sounds like an interesting project. You know where to find us if you need more assistance.

[keithcclark71]

Rob last question on this today here. These statements don't seem to reference the Tunnel Peer public IP address which is weird to me. How do traffic flows know to use the tunnel-group peer when sourcing from internal side of the ASA (192.168.2.18 host)? I read this Nat statement as 192,168.2.18 HOST gets translated to 172.16.31.8 when trying to access 172.16.30.5 which is associated with an external Vendor Tunnel Peer. So in other words this 192.168.2.18 host needs to communicate with 172.16.30.5 IP address at the Vendor location over the tunnel. Is there like a routing table entry added when creating NAT objects like this? Am I close to understanding this ? Just to add here there is no ACL in firewall rules that is defining this traffic flow?

(inside) to (outside) source static 192.168.2.18 172.16.31.8 destination static 172.16.30.5 172.16.30.5
translate_hits = 0, untranslate_hits = 0
Source - Origin: 192.168.2.18/32, Translated: 172.16.31.8/32
Destination - Origin: 172.16.30.5/32, Translated: 172.16.30.5/32

[Rob Ingram · Accepted solution]

@keithcclark71 No routing entry for the NAT rule, the traffic needs to be routed to the ASA, the destination will likely match the default route and be routed via the ASA OUTSIDE interface. Traffic from 192.168.2.18 to the destination 172.16.30.5, the source is translated to 172.16.31.8. The new translated source 172.16.31.8 to the destination 172.16.30.5 matches the crypto ACL for that tunnel group, is encrypted and sent over the VPN tunnel.

This NAT rule is not explictly referenced within the tunnel-group configuration (at least from the CLI anyway, not sure of ASDM).

If using Reverse Route Injection (RRI) you create a routing table entry on the ASA for the remote network.