Breaking a NAT to Allow connectivity

[RANT]

Hello, 

I have a location that comes in via a VPN.  We are moving this Site-to-Site VPN connection to a 5gb link.  The prior engineer created NATs to allow comms.  They created many of them linking a large amount of traffic to these NATs.  Now I have to break these network objects up.  How can this be accomplished without breaking the entire network?  The image shows how they are redirecting traffic to another location.  Should I create a new NAT rule doing the same or edit this rule?

[aleabrahao]

Your question wasn't clear. What do you mean by "We are moving this Site-to-Site VPN connection to a 5GB link"?

[Rob Ingram]

@RANT Did you mean to include an image? I assume the new 5Gb link is a different interface with a different nameif, thus the existing NAT rules won't apply? If so, I personally would create new NAT rules speciifc for the new nameif. Else look to eliminate the requirement to use NAT, update crypto ACL that defines the interesting traffic to encrypt or use a route based VPN.

[RANT]

@rob- Yes I did mean to send the image.  I thought it would help in explaining but, it was too little information. We are tasked with trying to NAT information through a L2L connection. the information must go from client to a server farm at the same time going to another server farm within our network.  My first thought was to use twice NAT'g, but when we implement that, it still went to the first location and nothing at second location.  I have a diagram showing the thought process.

[Rob Ingram]

@RANT run "show nat detail" and packet-tracer to simulate the traffic flow, confirm what NAT rule is matched and then compare the order to the NAT rules from "show nat detail". You just may need to disable the old NAT rule when you cutover.

[RANT]

@rob - 8 (Inside) to (Inside) source static LubbockHeart-PACS-192.168.50.100 LubbockHeart-PACS-192.168.50.100 destination static CNTRAD-FUJI_PACS-192.168.

70.38 COMPASS2-DICOM-192.168.72.145 description jking 04242026Source - Origin: 192.168.50.100/32, Translated: 192.168.50.100/32143 (Inside) to (Outside) source static RANT-VPN-nodes RANT-VPN-nodes destination static VPN-LubbockHeart-PACS-NAT-192.168.250.65 LubbockHeart-PACS-192.168.50.100 no-proxy-arp description bkoch 2023-02-01Destination - Origin: 192.168.250.65/32, Translated: 192.168.50.100/32Destination - Origin: 192.168.50.100/32, 192.168.50.65/32, 192.168.50.106/32, 192.168.50.111/32170.71.43.86/32, 170.71.43.100/32, 170.71.43.54/32, 170.71.43.49/32, Translated: 192.168.50.100/32, 192.168.50.65/32, 192.168.50.106/32, 192.168.50.111/32

Right now, it is dropping traffic.   Yes, I tried a twice NAT and that did not work.

[Rob Ingram]

@RANT your NAT rule seems wrong, the source and destination interfaces are unlikely to both be "Inside".

What about run packet-tracer to determine the NAT rule matched?