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.
Added sysopt connection permit-vpn (I may of had this already)
disconnected, reconnected received ip 10.4.1.1
from the ASA
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)
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)
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.
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.
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..
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?
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)
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.
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..
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.
all hosts on the internal network have the pix set as default gateway, 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)
Is this what you mean?
Yes. The traffic will hit the inside of the pix and you're attempting to route it back out the same interface of the pix to the asa. This is called hairpinning.