01-14-2023 03:05 AM - edited 01-14-2023 03:06 AM
Hi,
We are migrating to FPR 1010 from ASA 5500X series. Attached is the topology for the site to site VPN.
The VPN tunnel established well and traffic is passing through.
The challenge that we are facing is for the NAT on the the tunnel. We have very specific requirement that the source and destination both should be translated on the NAT (through VPN)
The NAT config on the old ASA (9.4 Version) looks like this:
nat (inside,outside) source static H_10.201.68.194 H_10.244.81.49 destination static H_10.244.81.62 H_172.31.38.28
For testing purpose, IP any any is allowed on outside and inside interfaces.
NAT config on FPR1010 (Not working):
nat (inside,outside) source static |10.201.68.194 |10.244.81.49 destination static |10.244.81.62 |172.31.38.28
The ultimate goal is:
- the host 172.31.38.28 should be able to ping host 10.244.81.49
- this packets from 172.31.38.28 should actually reach 10.201.68.194
- Host 10.201.68.194 should see as if packets are coming from 10.244.81.62 and respond back to same ip.
Please advise.
Saif
Solved! Go to Solution.
01-14-2023 08:05 AM
Thank you for the suggestion. I have already gone through this document and configured accordingly.
My problem is that there is an ugly looking IPV6 nat translation which is always hit first and so the manually created entries are not hit. This ipv6 nat entry is automatically created (i cant figure it out why is this rule here?), its only visible in CLI and not FMC. So I cant remove it either. Here is what is looks like.
1 (inside) to (outside) source static |s2sAclSrcNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 |s2sAclSrcNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 destination static |s2sAclDestNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 |s2sAclDestNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 no-proxy-arp route-lookup
translate_hits = 5, untranslate_hits = 9
2 (inside) to (outside) source static|10.200.68.104 |10.224.91.60 destination static |10.244.91.61 |172.31.38.24 translate_hits = 0, untranslate_hits = 0
Please advise.
Saif
01-14-2023 03:16 AM
01-14-2023 08:05 AM
Thank you for the suggestion. I have already gone through this document and configured accordingly.
My problem is that there is an ugly looking IPV6 nat translation which is always hit first and so the manually created entries are not hit. This ipv6 nat entry is automatically created (i cant figure it out why is this rule here?), its only visible in CLI and not FMC. So I cant remove it either. Here is what is looks like.
1 (inside) to (outside) source static |s2sAclSrcNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 |s2sAclSrcNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 destination static |s2sAclDestNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 |s2sAclDestNwgV4|535a552f-8c29-11ed-a956-6b610fa63302 no-proxy-arp route-lookup
translate_hits = 5, untranslate_hits = 9
2 (inside) to (outside) source static|10.200.68.104 |10.224.91.60 destination static |10.244.91.61 |172.31.38.24 translate_hits = 0, untranslate_hits = 0
Please advise.
Saif
01-15-2023 04:07 AM
Factory reset and reconfiguration has resolved the issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide