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???
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
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..
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.
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
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.
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.
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.
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.
Configs seems fine..could you try ping from an actual host on the LANs not from the firewall to bring the tunnel up.
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..
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..
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
nop, that still doesn't do it. Here's what the packet tracer says:
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
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 ..
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
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!
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:
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?
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.
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 188.8.131.52 GK side, and host from other end AC side will be 192.168.100.30 as part of tunnel policy.
static (inside,outside)184.108.40.206 192.168.1.10 netmask 255.255.255.255
access-list outside_2_cryptomap extended permit ip host 220.127.116.11 host 192.168.100.30
access-list inside_nat0_outbound extended permit ip host 18.104.22.168 host 192.168.100.30
When 192.168.100.30 access 22.214.171.124 asa will translate to local host.
For RA VPN is another topic.