12-02-2011 01:21 PM - edited 03-11-2019 02:58 PM
I have been fighting this for longer than I would want to admit. So any help would be greatly appreciated
Basically we need to connect a client via IPSEC to an ASA 5510 in Brazil and then using the same 5510 send that traffic source and destination NAT'd over another IPSEC tunnel that connects back to our data center in the US where the service the client needs is located.
Why don't we just connect directly from the client device to the US you ask? Good question, and it involves the typical politics and sales promises.
I have attached a sanitized diagram of what we are trying to accomplish with the relevant configlets.
The IPSEC tunnel from the client to the ASA 5510 in Brazil is up. The IPSEC tunnel to between Brazil and US has not come up because I do not think the interesting traffic is making it there. The best I can tell is that NATing does not work how I would expect when all the traffic stays on the same interface and comes from an IPSEC tunnel.
I should note that we had no problem with the same setup when we did not have an IPSEC tunnel between the client and 5510. We were able source and destination NAT outside to outside and send the new translated IP's through the Brazil-US tunnel.
Thank you in advance for any help!
12-02-2011 02:03 PM
James,
I'd look at your NAT statements. A vpn in will place them on the inside and if your are carrying out a translation then it would only need to be carried out once on the outbound. e.g:
A.A.A.A = A.A.A.A when on VPN the traffic leaving the 5510 will be translated to B.B.B.B.
However, if you have a distinct requirement to hide their address the NAT could be drawn as:
A.A.A.A=Z.Z.Z.Z when routed into VPN then Z.Z.Z.Z =B.B.B.B when routed out. In summary an:
(OUTSIDE,INSIDE) and a Policy (INSIDE,OUTSIDE)
not sure about the legal obligations..FOMCL
12-02-2011 02:19 PM
Thank you for the reply.
I am not sure I understand why the VPN would place the traffic on the inside. I thought that the order of operations was for it to decrypt the traffic, perform NAT translation, routing (points back to the outside in this case), and there it would match the other IPSEC tunnel I have going back to the US. In which case the traffic would never leave the outside interface.
12-02-2011 02:24 PM
It will place the VPN on the inside of the firewall, as the traffic attempts to leave you should see it in a debug or a capture if you wish to verify the connectivity. Work backwards, if you can get the first vpn running and the traffic becomes the address you want. Then build on teh second tunnel and your seatination policy nat.
12-02-2011 02:45 PM
The problem is that we never want the traffic to be decrypted and placed on the inside interface. If that happens it will have no where to go to be routed back to the US.
Basically what we want to happen is this:
Inbound IPSEC traffic hits ASA -> decrypt -> destination NAT -> source NAT -> routing points to outside -> NAT'd IP's match BR-US IPSEC tunnel -> encrypt
12-02-2011 03:20 PM
Hi James,
I think you need a command "global(inside) 7 PAT_ADDRESS".
you will have make sure that your hairpin is working correctly. please read the following for more info :-
Also, test it before make changes to production device ;-).
Manish
12-02-2011 03:47 PM
Manish,
I went ahead and tried that and it is still not working. If you look at the diagram the inside interface should really never come in to the picture.
However, I am almost positive that it has to do with the source NAT (global) not being applied and therefore not matching the second tunnel's (Brazil-US) encryption domain. Just for testing I changed the static NAT to be (outside,inside), and tried the same global NAT on the inside interface to see what packets a capture would give me.
It showed the destination address tranlated, but the source IP address to be the same. I don't get why I could do all this on the outside interface when ther was not a client IPSEC tunnel originally.
12-02-2011 04:06 PM
James,
run a paket tracer on the outside interface of Br fw.
packet-tracer input outside icmp Client-source 0 0 US-site-dest detail
Lets see where is it failing.
Manish
12-02-2011 06:29 PM
12-04-2011 11:04 AM
I have configured on a few occasions this type of "Hub VPN" with NAT, and you need to double check your " no-nat" back to the US side. You do not want to "Double NAT" it into the US side VPN.
HTH>
12-05-2011 09:51 AM
Interesting.
Would this be an issue even if I don't have Nat control enabled?
12-05-2011 12:21 PM
if you are natting in one direction, then you are natting. You do not want to "double nat"
Sent from Cisco Technical Support iPad App
12-05-2011 12:33 PM
Here is a trace:
5510# packet-tracer input outside tcp 1.1.1.2 1025 2.2.2.2 6011
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (outside,outside) 2.2.2.2 10.3.3.3 netmask 255.255.255.255
match ip outside host 10.3.3.3 outside any
static translation to 2.2.2.2
translate_hits = 0, untranslate_hits = 766
Additional Information:
NAT divert to egress interface outside
Untranslate 2.2.2.2/0 to 10.3.3.3/0 using netmask 255.255.255.255
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl0 in interface outside
access-list acl0 extended permit tcp host 1.1.1.2 host 2.2.2.2 eq 6011
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (outside) 8 access-list Leawoodtest-Source-NAT outside
match ip outside host 1.1.1.2 outside host 10.3.3.3
dynamic translation to pool 8 (10.2.2.2)
translate_hits = 0, untranslate_hits = 0
Additional Information:
Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (outside,outside) 2.2.2.2 10.3.3.3 netmask 255.255.255.255
match ip outside host 10.3.3.3 outside any
static translation to 2.2.2.2
translate_hits = 0, untranslate_hits = 766
Additional Information:
Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (outside,outside) 2.2.2.2 10.3.3.3 netmask 255.255.255.255
match ip outside host 10.3.3.3 outside any
static translation to 2.2.2.2
translate_hits = 0, untranslate_hits = 766
Additional Information:
Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (ipsec-spoof) IPSEC Spoof detected
12-05-2011 01:31 PM
Happily I have no experience of that tool, I am old school, I use command line and debug. I have no idea what version if iOS you are using, i use 8.2 and below. On every VPN hub network I have configured, i have always used "no-nat" they have worked 100% for me every time. I think in 8.3 and about it's now called "identity nat or double nat" either way you want a packets ip to remain the same, when a form is nat is being used, afaik.
Please update this thread if you get it working without no-nat, if nat is the issue. And You may have other config errors.
Sent from Cisco Technical Support iPad App
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