09-06-2008 06:08 AM - edited 02-21-2020 02:59 AM
I've got a new 5505, and I've run through two wizards: one to start up, one to add client VPN. As a result, I can now connect from a client, the client gets the right info (ip adress, dns, gateway), but it cannot connect to any of the servers on the 'inside' network. The config is here:
http://www.dubbele.com/asaconfig.txt.
I've tried a lot of different things, but I cannot seem to get what's going wrong. Any clues would be very welcome!
09-06-2008 07:16 AM
John,
I strongly suggest to always use different ip-scheme for each of vpn RA tunnels and that they not be the same any of the asa inside interfaces.
interface Vlan1
ip address 192.168.6.25 255.255.255.0
ip local pool vpnhaarlem 192.168.6.150-192.168.6.175 mask 255.255.255.0
for vpnhaarlem do the following.
use a unique private IP scheme for it as you have done with rotterdam , as an example lets use 10.20.20.0/24
remove
no ip local pool vpnhaarlem 192.168.6.150-192.168.6.175 mask 255.255.255.0
add
ip local pool vpnhaarlem 10.20.20.1-10.20.20.254 mask 255.255.255.0
This first line acl is ok but persoannly I suggest to be more granular allowing specific RA tunnel group networks and not just permit ip any, again example for 10.20.20.0/24 network .
stick with one no NAT acl for RA tunnels like inside_nat0_outbound remove the 1 and 2 otherwise you will have to create more
nat (inside) access-list statements for RA networks.
remove
no access-list inside_nat0_outbound_1 extended permit ip any 192.168.6.0 255.255.255.0
no access-list inside_nat0_outbound extended permit ip 192.168.6.0 255.255.255.0 192.168.6.0 255.255.255.0
add
access-list inside_nat0_outbound extended permit ip 192.168.6.0 255.255.255.0 10.20.20.0 255.255.255.0
for the rotterdam tunnel group it is fine with unique IP scheme , I would apply my suggestion above
no access-list inside_nat0_outbound_2 extended permit ip 192.168.6.0 255.255.255.0 192.168.6.128 255.255.255.192
access-list inside_nat0_outbound extended permit ip 192.168.6.0 255.255.255.0 192.168.5.0 255.255.255.0
re-adjust the no-nat acl statement bellow
no nat (inside) 0 access-list inside_nat0_outbound_2
nat (inside) 0 access-list inside_nat0_outbound
Let us know how it works out
Rgds
Jorge
09-06-2008 07:22 AM
I saw the same behaviour with the rotterdam scheme, but I'll go back and try your suggestions. I'll be back with results later..
09-06-2008 09:59 AM
Here's what I did: I gave the outbound interface the ip address it is going to get when I move it to the datacenter, and gave a laptop an address in the same class C for testing. I removed one of the policies (rotterdam) and moved haarlem to 10.0.0.0/24. I changed the acls you mentioned, and no change.
The VPN client gets a 10.0.0.10 address, and a default gateway 10.0.0.1 (which it cannot ping, by the way).
Still no luck accessing any of the 192.168.6.x servers.
New config is here:
http://www.dubbele.com/asaconfig2.txt
did I overlook any of your suggestions?
09-06-2008 02:45 PM
Did you do this through asdm? beter do it through cli.
you are missing
nat (inside) 0 access-list inside_nat0_outbound
try again
also you have removed split tunnel acls, unless you will do full tunnel to allow RA internet acces through your asa you will have to add these two lines
same-security-traffic permit intra-interface
nat (outside) 1 10.0.0.0 255.255.255.0
09-07-2008 01:38 AM
Just did all three things in the cli, as can be seen at http://www.dubbele.com/asaconfig3.txt.
No change - the client gets 10.0.0.10, default gateway 10.0.0.1 (which it cannot ping), and it fails to reach 192.168.6.x
(oh, and by the way: thank you for all the effort you're putting in this - it is much appreciated!)
09-07-2008 05:10 AM
Enable NAT-T, and try
crypto isakmp nat-traversal 20
[edit]
have a look here as well
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008060f25c.shtml
09-07-2008 05:25 AM
I did that through the cli, saw no difference in client behaviour.
The weird thing is that if I compare the running-config after that cli command with the asaconfig3.txt file linked earlier, there's no difference at all.
09-07-2008 05:45 AM
just to make sure, are your servers in 192.168.6.0/24 off inside interface?
check servers hosts ensure they don't have windows firewall turned on, otherwise we'll have to debug
09-07-2008 05:50 AM
Yes they are connected the network on the "inside" interface - and they can reach each other, so firewalls aren't an issue there. They can also reach the asa, and the asa can reach them.
09-07-2008 06:28 AM
are you able to see asdm realtime log when client is connected, it would help to see logs while they try pinging inside host
also while client is connected login to firewall and issue bellow : post outpot of this.
show crypto ipsec sa
09-07-2008 06:35 AM
Before the client connects:
Result of the command: "show crypto ipsec sa"
There are no ipsec sas
After the client connects:
Result of the command: "show crypto ipsec sa"
The command has been sent to the device
(and no further output)
Contact me off the mailing list at john@dubbele.com, I may be able to give you access to the device after I've put it in a datacenter tomorrow morning (greenwich+1 time)
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