Question about Site-to-site VPN with two ASA 5505s

Unanswered Question
Sep 27th, 2009

Hi,

I'm still what I would consider a newbie to ASAs. They're the first HW firewall I've worked with and have been using them for a few months successfully. Since I know absolutely nothing about VPNs, I figured I'd give the GUI a try.

First question: Step1, it asks me on what intrface will the VPN tunnel be. I suppose this should be the outside interface...

Step 5: it's asking me to define the local and remote networks that will take part of this tunnel.. Is this supposed to be the un-translated IPs???

Thanks!

I'm currently at step 5 of 6 where it asks me to specify the local and remote networks which will be communicating. I do believe this is meant to be the internal IPs, not the external ones

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
JORGE RODRIGUEZ Sun, 09/27/2009 - 15:28

Hi,

Step1: answer is yes for outside interface, assuming your outside interface is where other end peer will be coming in.. e.g internet facing interface.

Step 5: You got it.. the local networks you want to be part of the tunnel policy.. your side, remote the other end.. yes.. un-translated (NONAT) ... provided they do not overlap.

you may want to keep this link handy for future references..

http://www.cisco.com/en/US/products/ps6120/prod_configuration_examples_list.html

godinerik Sun, 09/27/2009 - 15:40

I seem to be getting stuck here:

1 Sep 27 2009 22:34:13 713900 Group = REMOTEPEERIP, IP = REMOTEPEERIP, construct_ipsec_delete(): No SPI to identify Phase 2 SA!

Everything I've read so far told me that it had to do with mis-matched subnets between my config and mty cryto map.

vlan1:

interface Vlan1

nameif inside

security-level 100

ip address 192.168.10.1 255.255.255.240

show run crypto:

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 1 match address outside_1_cryptomap

crypto map outside_map 1 set peer REMOTEPEERIP

crypto map outside_map 1 set transform-set ESP-3DES-SHA

crypto map outside_map interface outside

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

show run access-list:

access-list outside_1_cryptomap extended permit ip 192.168.10.0 255.255.255.240 192.168.100.0 255.255.255.240

access-list inside_nat0_outbound extended permit ip 192.168.10.0 255.255.255.240 192.168.100.0 255.255.255.240

Everything on the other side is the same, except that vlan1 is 192.168.100.1 255.255.255.240.

TIA,

Erik

godinerik Sun, 09/27/2009 - 15:42

And of course.. in the ACLs on the remote host, 192.168.100.0 would come before 192.168.10.0 sincei t would be a mirror of the above.

godinerik Sun, 09/27/2009 - 16:28

Hi,

still no luck. Here are the configs that I have at both ends. I tried pinging from AC-FW to gatekeeper however no luck (I was told this is how you bring the tunnel up??)

PS: Default gateway, static translations and any other external IPs were replaced with a placeholder... "RemotePeerIP" was used in the cryptomap to represent the remote peer, which is the IP of the device on the other side.

JORGE RODRIGUEZ Sun, 09/27/2009 - 16:45

Configs seems fine..could you try ping from an actual host on the LANs not from the firewall to bring the tunnel up.

godinerik Sun, 09/27/2009 - 17:42

Hi,

to be more specific, the error message was different,however the tunnel still isn't coming up. When connecting to AC and trying to ping gatekeeper by pinging 192.168.10.2 I get:

5 Sep 27 2009 17:26:11 713041 IP = REMOTEPEERIP, IKE Initiator: New Phase 1, Intf inside, IKE Peer REMOTEPEERIP local Proxy Address 192.168.100.0, remote Proxy Address 192.168.10.0, Crypto map (outside_map)

6 Sep 27 2009 17:25:16 713219 IP = REMOTEPEERIP, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.

a few times until I see:

3 Sep 27 2009 17:25:37 713902 IP = REMOTEPEERIP, Removing peer from peer table failed, no match!

4 Sep 27 2009 17:25:37 713903 IP = REMOTEPEERIP, Error: Unable to remove PeerTblEntry

I tried pinging continually..

JORGE RODRIGUEZ Sun, 09/27/2009 - 19:56

Sorry for late reply.. had a look at config again.. have pfs either enable or disable at both ends I beleieve that is where the issue is, there is crypto map outside_map 1 set pfs in AC_firewall but not in gatekeeper .. pfs is part of phase2 negosiations..

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml#pfs

in ACfirewall modify that statement

crypto map outside_map 1 set pfs group2

add the same in gatekeeper

crypto map outside_map 1 set pfs group2

then try again.. otherwise we have to debug tunnel to give more details where it fails in phase2

Regards

godinerik Sun, 09/27/2009 - 22:07

nop, that still doesn't do it. Here's what the packet tracer says:

Phase: 9

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Result:

input-interface: inside

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

I did, from AC:

packet-tracer input inside 192.168.100.2 3956 192.168.10.2 3223

JORGE RODRIGUEZ Mon, 09/28/2009 - 07:48

acl looks fine to me at either side.

telnet to one of the firewall and debug ipsec phase , save the output of it.

if you ping from a host in gatekeeper firewall 192.168.10.x towards a host in AC firewall 192.168.100.x do the debug ipsec in AC firewall side ..

say

AC(config)#logging console 7

AC(config)#debug crypto ipsec

then send ping from GK to a host in AC side.. in your terminal emulator u can use save output ... post the debug information.

then you can disable debugg

AC(config)#no debugg all

godinerik Mon, 09/28/2009 - 14:37

Hi Jorge,

I'm happy to say the tunnel came up. In the end, the problem was combination of a few different things:

- Indeed the PFS settings didn't match. This seemed to be caused by the fact that I was configuring this tunnel using two different versions of the ASDM software.. on one, I was prompted asking if I wanted pfs and I said no. On the other one, I was never even prompted about it..

- I was missing an ACL on gatekeeper.. I should of had an ACL for inbound traffic coming from 192.168.100.2

- Even after all of the above being done, when I was testing with the packet-tracer, the first hit would never get through (stating it was dropped due to the ACL) however the second hit (second time I use packet-tracer) will always get through.. it takes at least one hit to get the tunnel up.

Thanks for your help. I guess the next step is to read about tunnel-groups and crypto map settings and familiarize myself wit this stuff at a CLI level. I'm also looking into a client/server tunnel.. I keep getting an error but I think I'll spend more time reading about this one first before asking questions.

have a good one!

Erik

godinerik Mon, 09/28/2009 - 17:45

Actually I do have a follow-up about L2L VPNs. All of this was testing for upcoming site-to-site I need to configure. This company I'm dealing with sent me some type of form providing me all the required information. Two of those fields are:

Interesting traffic:

Remote hosts:

For both of those, it is specified (No internal IP addresses)

Does this mean that, when I create my crypto map, I can assign translated (i.e.: external) IPs to it instead, as long as the internal IPs are NAT'ed to those external IPs? Also, would this mean that those external IPs couldn't be used for Internet communications? Or am I totally mis-understanding this?

godinerik Mon, 09/28/2009 - 19:00

Actually I guess I'll answer myself on this one..

I tried assigning an extra (external) IP to each device and creating the tunnel between the two IPs. This was actually successful. I used the packet-tracer as follow:

packet-tracer input inside 192.168.10.3 3945 AA.BB.CC.DD(EXTERNAL IP on remote device) 3389

The first time I did this of course, it was denied by the ACL. This seems to be usual behavior until the tunnel comes up.. the second time I did this, the traffic passed through... The only dis-advantage to this is, the new external IP won't be able to route internet traffic I believe.. not sure why this is a requirement, maybe for security reasons? Still to be done:

RA VPN and then to route RA VPN through the tunnel... So to complicate things, like mentioned before, the other side of the tunnel are not interested in adding any internal networks as "interesting traffic". they want everything to be external IPs. It seems like I'll have to map at least a cpl of IPs (one for the actual server, one for the remote access VPN) to map to this new external IP.

JORGE RODRIGUEZ Mon, 09/28/2009 - 20:59

Erick good testing, interesting traffic means the hosts or subnets at your end that will be part of the tunnel policy.

As for NATing the internal IP with public yes you can NAT as seen in your test, simply create static one-to-one NAT private-public IP then in your crypto acl instead of using private you use the public IP. Host will no go through the tunnel for internet; it will use its public IP for regular internet traffic separated from l2l tunnel.

say public IP for 192.168.1.10 host is 20.20.20.20 GK side, and host from other end AC side will be 192.168.100.30 as part of tunnel policy.

static (inside,outside)20.20.20.20 192.168.1.10 netmask 255.255.255.255

access-list outside_2_cryptomap extended permit ip host 20.20.20.20 host 192.168.100.30

access-list inside_nat0_outbound extended permit ip host 20.20.20.20 host 192.168.100.30

When 192.168.100.30 access 20.20.20.20 asa will translate to local host.

For RA VPN is another topic.

Regards

Actions

This Discussion