Remote Access VPN - ASA 5510 - 8.0 Code

Unanswered Question
Sep 25th, 2007

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
acomiskey Tue, 09/25/2007 - 06:50

I would start here...

sysopt connection permit-vpn

then post the results.

alblanton Tue, 09/25/2007 - 07:00

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)

acomiskey Tue, 09/25/2007 - 07:10

Are you sure the host is pingable? Check windows firewall etc.

alblanton Tue, 09/25/2007 - 07:46

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)

alblanton Tue, 09/25/2007 - 11:05

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.

alblanton Fri, 09/28/2007 - 10:40

Would this make a difference as to why its not working? (see attached file) When I connect now, I can ping the ASA's External interface from the client, but still can't reach anything internally..

Attachment: 
acomiskey Fri, 09/28/2007 - 11:08

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.

alblanton Fri, 09/28/2007 - 11:26

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..

acomiskey Fri, 09/28/2007 - 11:38

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?

alblanton Fri, 09/28/2007 - 11:43

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)

acomiskey Fri, 09/28/2007 - 11:52

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.

alblanton Fri, 09/28/2007 - 14:02

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..

acomiskey Fri, 09/28/2007 - 15:28

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.

alblanton Fri, 09/28/2007 - 21:21

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?

acomiskey Sat, 09/29/2007 - 04:46

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.

Actions

This Discussion