08-02-2013 08:13 AM - edited 03-11-2019 07:20 PM
Hello all,
I worked with you a few days back on a site-to-site using to 5505 ASA's in a lab before deploying, with your help that is working.
We are moving to deploy into production with some different settings, as the customers site remains the same but we will move from using the local interface nameif inside to our DMZ - first thing is will this work through site-to-site?
We have the ASA on our end configured to use site-to-site through our DMZ interface, we created the ACL, then the NAT, we can't ping anything on their local subnet or they ping our local subnet.
I really need you help to show what I missed or failed to implement
Thank you
Solved! Go to Solution.
08-02-2013 09:37 AM
Hi,
PCS-EW-VPN ASA is missing a "crypto map" related command
Add this
crypto map outside_map 1 match address outside_1_cryptomap
- Jouni
08-02-2013 09:54 AM
Hi,
Can you issue the "packet-tracer" command again on that same ASA unit (twice)
Could you also tell us between which devices are you attempting to ICMP? This cant be done from the ASA directly atleast so I assume that you are ICMP between hosts? Have you confirmed that those hosts are attached to the correct ports and have the correct IP addresses and gateways if you have change the INSIDE -> DMZ for this setup on the other ASA?
I cant see no problem with the configurations at the moment. They should enable the L2L VPN negotiation to go through. But as you saw, you didnt have the configuration above on the other ASA that defines the local and remote networks on the L2L VPN connection so I think the ASDM might have removed that during some configurations.
You can naturally add the following commands on both ASAs for ICMP
fixup protocol icmp
fixup protocol icmp error
Those are old format commands but should convert to "inspect" command
Alternatively you can add them in the following way
policy-map global_policy
class inspection_default
inspect icmp
inspect icmp error
Can the ASAs ping eachothers WAN interfaces at the moment?
When you issue the "packet-tracer" command or have a continuous ICMP from some host behind the "EWVPN" interface or "inside" on the other ASA, what can you see with the command
show crypto ikev1 sa
Try to issue it several times during testing to see what it shows
You could also use the command
show crypto ipsec sa
To view if the Phase2 has gone through and if packets have gone through the L2L VPN in either direction.
There is always a chance that something else than the ASA is stopping the ICMP traffic.
- Jouni
08-02-2013 10:29 AM
Hi,
The ASA PCS-lab-EW-VPN with the "packet-tracer" is not even matching to the VPN Phase
Either we are still talking about a configuration error or some wierd bug
Can you issue the command "show run" on this ASA and share the configuration again.
This just doesnt make any sense.
- Jouni
08-02-2013 10:38 AM
Hi,
Typo in the configuration
Remove
crypto map outside-map 1 match address outside_1_cryptomap
Add
crypto map outside_map 1 match address outside_1_cryptomap
Current one has - in the "outside-map" while it should have _ , as in "outside_map"
The typo in the Crypto Map name basically attached the L2L VPN ACL to a different Crypto Map which was not used. This is why on the other ASA the traffic is not matching to any VPN configuration.
- Jouni
08-02-2013 10:47 AM
Hi.
Good to hear
Took some time but finally got it working
Please do remember to mark a reply as the correct answer.
- Jouni
08-02-2013 08:19 AM
Hi,
So I assume that on the ASA PCS-EW-VPN you want to use the "EWVPN" interface instead of "inside"?
Notice that you have to modify the NAT rule there
no nat (inside,outside) source static net-local net-local destination static net-remote net-remote
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
This is because it still has the old source interface. The current rule only applies between "inside" and "outside" interface. Since you want to change the local interface for the VPN you will also have to change the local interface for the NAT configuration.
Also I would suggest changing this NAT configuration also to avoid future problems
no nat (EWVPN,outside) source dynamic any interface
nat (EWVPN,outside) after-auto source dynamic any interface
The configuration I suggest removing is at so high priority that you might have problems in the future if you try to configure some additional NAT rules for interface "EWVPN". So a bit pre-emptive change to the configuration.
- Jouni
08-02-2013 08:38 AM
Hello Jouni, I'm very sorry to bother you with this again my friend, really nice to have your expertise...
I made the changes as shown for both NAT's, we still can't ping local network.
I'm running packet tracer on both with ASA -PCS-lab-EW-VPN completes with all green check marks, the ASA-PCS-EW-VPN fails to complete the trace route at VPN.
Thank you
08-02-2013 08:43 AM
Hi,
Do you mean a "packet-tracer" fails on some ASA or a Traceroute? Traceroute to what?
If you mean "packet-tracer" then can you share the output from the CLI.
- Jouni
08-02-2013 08:44 AM
My Bad, should read Packet-tracer
08-02-2013 08:47 AM
In addition to what Jouni has said, you might also need to clear the xlate table to get this working right away instead of having to wait for it to timeout.
08-02-2013 08:52 AM
Jouni,
I figured out how to run the Packet-tracer from the command-line as shown below
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
NAT divert to egress interface outside
Untranslate 10.10.10.10/21 to 10.10.10.10/21
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: inspect-ftp
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
Static translate 172.16.5.2/21 to 172.16.5.2/21
Phase: 5
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Result:
input-interface: EWVPN
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
08-02-2013 08:57 AM
You will need to run the packet tracer twice. The first time it will show as drop because the VPN tunnel is most likely not up. The first trace will bring the tunnel up, and the second trace should give you the real result of the trace.
08-02-2013 08:58 AM
Hi,
Can you issue the command twice.
Usually when we have a L2L VPN connection and we use the "packet-tracer" to simulate a packet going to the L2L VPN the first "packet-tracer" will always produce a drop.
So can you issue the command again. Also mention the command used.
Though then again if you have issued a corresponding "packet-tracer" command on the other side and it goes through it doesnt make sense.
In that case you could perhaps try issue this command on both ASAs and then issue the "packet-tracer" commands again.
clear crypto ikev1 sa
- Jouni
08-02-2013 09:08 AM
Packet-trace 2 complete - looks good with green check marks - still not able to ping remote local network on either side
PCS-EW-VPN(config)# packet-tracer input EWVPN tcp 172.16.5.2 21 10.10.10.10 21
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
NAT divert to egress interface outside
Untranslate 10.10.10.10/21 to 10.10.10.10/21
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: inspect-ftp
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
Static translate 172.16.5.2/21 to 172.16.5.2/21
Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (EWVPN,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 2525, packet dispatched to next module
Result:
input-interface: EWVPN
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
08-02-2013 09:11 AM
Hi,
It doesnt seem to mention a VPN phase.
As if it was just sending the traffic to the Internet.
But on the VPN configurations it seemed to me that the networks matched on each side so there should be some phase.
If you are making configurations through the ASDM I would double check that no essential configurations were removed.
- Jouni
08-02-2013 09:16 AM
What should I do - wipe both ASA's then start over?
08-02-2013 09:22 AM
Hi,
You can try to attach the current configurations to the post.
Naturally if there is a chance that there is just some wierd problem with the ASAs you can save the configuration and reboot both devices since this is still a lab setup.
Though looking through your current CLI format configuration should tell what the problem is.
- Jouni
08-02-2013 09:25 AM
Is this lab setup using GNS3, If so, this can at time be a bit quirky and trashing the whole setup and rebuilding will resolve the problem most of the time.
08-02-2013 09:30 AM
Nope , using two brand new ASA's 5505, will deploy them next week - with one at my current location and the other at customer site
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