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

Unanswered Question
Sep 27th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
JORGE RODRIGUEZ Sun, 09/27/2009 - 15:28
User Badges:
  • Green, 3000 points or more

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
User Badges:

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
User Badges:

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.

JORGE RODRIGUEZ Sun, 09/27/2009 - 15:48
User Badges:
  • Green, 3000 points or more

Erik , revise the configuration from both ends.. use this link as example.. that message seems to be failing in phase 2. .. both ends must exactly agree in policy.. so you have to look at both asa configurations.. if still no joy post both asa configs to see.


http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080950890.shtml


regards


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

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
User Badges:
  • Green, 3000 points or more

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:08
User Badges:

Hi,



Pinging from the host has the same result.



thanks,



Erik

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

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
User Badges:
  • Green, 3000 points or more

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
User Badges:

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
User Badges:
  • Green, 3000 points or more

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
User Badges:

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

JORGE RODRIGUEZ Mon, 09/28/2009 - 17:32
User Badges:
  • Green, 3000 points or more

Erik, glad you got it resolved and posted final resolution.


Regards


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

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
User Badges:

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
User Badges:
  • Green, 3000 points or more

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