09-25-2007 06:42 AM - edited 02-21-2020 03:17 PM
I'm trying to setup the ASA 5510 as a ssl vpn/ Remote Access VPN Device.. I can connect, but no traffic passes between the connected pc, and the inside, or the outside networks..
I'm trying to set it up so that all remote vpn connections are created from a pool of ip's that is nat'd behind the ASA..
I've attached my current config..
the vpn routing doesnt work, but the ldap authorization and radius authentication do, if anyone needs that..
Thanks for any help.
09-25-2007 06:50 AM
I would start here...
sysopt connection permit-vpn
then post the results.
09-25-2007 07:00 AM
Added sysopt connection permit-vpn (I may of had this already)
disconnected, reconnected received ip 10.4.1.1
from the ASA
ping 10.4.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.1.1, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
09-25-2007 07:10 AM
Are you sure the host is pingable? Check windows firewall etc.
09-25-2007 07:46 AM
I've been testing it from a linux box that I disabled the firewall, flushed iptables before testing.. I'll try it again from a windows machine w/ firewall disabled also but i'm pretty sure i'll get the same results.
(no traffic passing between remote host, and ASA, or internal network)
09-25-2007 11:05 AM
I connected from a windows machine, and I can now ping the ASA's External interface from the remote machine, but nothing else is pingable.
09-28-2007 10:40 AM
09-28-2007 11:08 AM
1. From the looks of your diagram, the following route statements are not correct. As these networks are located on the outside of the ASA, not the inside.
route inside 10.0.0.0 255.0.0.0 172.16.14.1 1
route inside 172.16.0.0 255.255.0.0 172.16.14.1 1
This may have also prevented you from pinging the vpn client, 10.4.1.1, since the route on the ASA for the 10.0.0.0/8 network points to is 172.16.14.1.
2. Also looks like you're trying to hairpin on the outside interface of the ASA. Never tried that before unless I wanted traffic to nat on the outside interface to go to the internet or to hairpin traffic over another vpn tunnel. If the ASA is hairpinning the traffic to the inside network, the return traffic would have to be directed back to the ASA. So you could try to nat the 10.4.1.0/24 network on the outside of the ASA.
global (outside) 1 interface
nat (outside) 1 10.4.1.0 255.255.255.0
3. You would then also need to allow the traffic between 10.4.1.0 and your inside networks in an acl applied into your dmz interface on the pix.
09-28-2007 11:26 AM
This is where I'm running into confusion.. all of these networks are behind the PIX..
192.168.1.x is our DMZ subnet on the pix anything in this subnet is NAT'd in the pix to a "real" external address..
from the asa's POV.. 192.168.1.100 is the outside interface, w/ the NAT config on the pix, it's logically the internet facing side of the ASA..
I guess I should of drawn another network connection line between the inside interface of the ASA to the main switch..
w/ the way its configured right now.. I can connect w/ anyconnect, and from the connected host (10.4.1.1) I can ping 192.168.1.100, and from the ASA I can ping 10.4.1.1 on the outside interface..
I'll attach "new" current config as i'm sure its changed..
09-28-2007 11:38 AM
10.4.1.0 is on the outside of the ASA. So this route would be wrong. Actually you don't need to add a route to the vpn client network anywhere.
route inside 10.4.1.0 255.255.255.0 172.16.14.100 1
If there is a connection between the inside of the ASA and the main switch, then your only real problem would be getting the inside hosts to route to the ASA when replying to 10.4.1.0. I assume their default gateway is the pix?
09-28-2007 11:43 AM
Yes.. all internal hosts main gateway is the pix, and on the pix there is a route set pointing 10.4.1.0/24 to 172.16.14.100 (the inside interface of the ASA)
09-28-2007 11:39 AM
09-28-2007 11:52 AM
What version is the pix?
The pix will not hairpin traffic by default. You are attempting to have the traffic bounce off the inside interface of the pix. You need to enable that functionality.
To test, you could also add a route on one of the inside hosts which points 10.4.1.0 to 172.16.14.100.
Something like...i think...
route add 10.4.1.0 netmask 255.255.255.0 172.16.14.100
Or temporarily make the gateway for a host 172.16.14.100. This will rule out any issues with the vpn, which will only leave the routing problem.
09-28-2007 02:02 PM
I dont think the pix is doing any traffic in/out thru the same interface..
When running the packet trace on the asdm, it looks like the problem is getting packets to go from the outside interface (10.4.1.x) into the inside interface because of the different security levels.. (0 and 100) but setting both to 100 doesnt change this either..
I think monday I'm going to try this again taking the ASA out from behind the pix..
09-28-2007 03:28 PM
Ok, but the return traffic from the inside client will go to it's default gateway which is the pix because the machine has no more specific route to 10.4.1.0. You need this traffic to go back to the inside of the ASA.
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