cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2317
Views
0
Helpful
29
Replies

Site-To_Site_DMZ

Stephen Sisson
Level 1
Level 1

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

5 Accepted Solutions

Accepted Solutions

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

View solution in original post

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

View solution in original post

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

View solution in original post

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

View solution in original post

Hi.

Good to hear

Took some time but finally got it working

Please do remember to mark a reply as the correct answer.

- Jouni

View solution in original post

29 Replies 29

Jouni Forss
VIP Alumni
VIP Alumni

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

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

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

My Bad, should read Packet-tracer

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.

--
Please remember to select a correct answer and rate helpful posts

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

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.

--
Please remember to select a correct answer and rate helpful posts

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


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

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

What should I do - wipe both ASA's then start over?

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

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.

--
Please remember to select a correct answer and rate helpful posts

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

Review Cisco Networking for a $25 gift card