Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VPN IPSec Client connectivity to ASA5510

I have an ASA5510 at a remote location. I used the IPSec VPN Wizard to configure Remote Access for the developers into the DMZ portion of the network, 192.168.100.0/24.

I can connect using both the latest Cisco client on Windows and using VPNC on my Linux box. A tunnel is created, I receive a valid IP within the 192.168.100.0 subnet and all looks great.

But when I attempt to ssh to one of the servers, the SYN packet times out. I can see the connection attempt to be established looking at the logs on the firewall.

There is no issue with the Linux servers themselves to which I am attempting to connect. I flushed iptables and even attempted to connect without any firewall rules. Still no dice.

I can post my running-config here if necessary.

Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions

Re: VPN IPSec Client connectivity to ASA5510

Well just make sure the desired ISAKMP policy on your firewall is at the top. This will decrease the negotiation time for Phase 1. Also make sure there is no fragmentation (MTU issues).

Regards

Farrukh

12 REPLIES
New Member

Re: VPN IPSec Client connectivity to ASA5510

Update: Am attaching a screenshot of my home connection to the VPN. As you can see, I am connected just fine and have an internal IP, 192.168.100.232 as well as viable outside IP. Split tunneling is enabled.

Note, the Bytes transmitted (Tx) and received (Rx). Plenty received, but nothing transmitted.

Am guessing that something on the firewall is preventing outside VPN'ed hosts from connecting to internal servers.

Green

Re: VPN IPSec Client connectivity to ASA5510

How bout an ASA config?

New Member

Re: VPN IPSec Client connectivity to ASA5510

You betcha...

Have removed any incriminating evidence.

Attempting to use the group "smiremoteusers" to connect. Can connect just fine, but not access any internal servers in the DMZ or 192.168.100.0 subnet.

Green

Re: VPN IPSec Client connectivity to ASA5510

Ok here goes.

1. Don't use the same subnet for your vpn users that you use for your dmz or inside. You used the same subnet for vpn client and dmz.

2. You have nat exemption set up for the dmz but not for the inside.

access-list dmz_nat0_outbound extended permit ip 192.168.100.0 255.255.255.0 192.168.100.224 255.255.255.224

nat (dmz) 0 access-list dmz_nat0_outbound

you also need...

access-list inside_nat0_outbound extended permit ip

nat (inside) 0 access-list inside_nat0_outbound

New Member

Re: VPN IPSec Client connectivity to ASA5510

Understood. I had suspected that, but had not followed through. Ran into a similar issue awhile back doing something similar on a 2821 router.

So, would you recommend using a neighboring Class C, such as 192.168.101.0 or something different such as 172.16.x.x for the VPN user subnet?

I am not so much concerned about users getting to the inside subnet, as simply being able to access ONLY the DMZ.

I'd also prefer to turn on hairpin'ing, but know this would involve more NAT'ing and my skills have rusted from disuse.

New Member

Re: VPN IPSec Client connectivity to ASA5510

Now I am really confused. Whereas before I was able to connect and still route to outside sites, now when I connect I am cut off entirely. Even though I did enable split tunneling.

Here is the current running config. Maybe someone else, besides me, can make heads or tails of it.

Again, I simply want users to connect using Remote VPN access to the outside firewall at our collocation facility. Then, once in they use the VPN users IP address range, 192.168.111.0/26. They should be able to access the internal servers in the DMZ or 192.168.100.0/24 subnet.

Rather than having to create rules to allow home IP addresses in, let them authenticate via the VPN and then have access.

It should not be this difficult.

Re: VPN IPSec Client connectivity to ASA5510

Kerry it all depends on your policy. It just should be different enough to differentiate between the DMZ subnet and the VPN pool (to reduce human errors during configuration changes etc.).

I would go for another class C like 192.168.150.0/24 etc.

Regards

Farrukh

New Member

Re: VPN IPSec Client connectivity to ASA5510

Thanks. I agree with your verdict.

I decided to go with 192.168.111.0/24. Plain and simple.

New Member

Re: VPN IPSec Client connectivity to ASA5510

Now I am really confused. Whereas before I was able to connect and still route to outside sites, now when I connect I am cut off entirely. Even though I did enable split tunneling.

Here is the current running config. Maybe someone else, besides me, can make heads or tails of it.

Again, I simply want users to connect using Remote VPN access to the outside firewall at our collocation facility. Then, once in they use the VPN users IP address range, 192.168.111.0/26. They should be able to access the internal servers in the DMZ or 192.168.100.0/24 subnet.

Rather than having to create rules to allow home IP addresses in, let them authenticate via the VPN and then have access.

It should not be this difficult.

Cisco Employee

Re: VPN IPSec Client connectivity to ASA5510

Keyword "any" is not supported in split tunnel ACL. Put specific networks, and you should be good to go.

New Member

Re: VPN IPSec Client connectivity to ASA5510

Understood. I removed all references to ACL_Tunnel_1 and _2 that had any and left in place _3 which defined the subnets.

I can connect to the VPN from my home account and do receive an IP of 192.168.111.2.

I am now able to connect, but it takes about a minute or two for the connection to get established.

So, I am nearly there. Just wondering why it is taking so long. Perhaps it is my home connection?

Anyways, I will keep debugging, but it looks like I am nearly there. Thanks.

Re: VPN IPSec Client connectivity to ASA5510

Well just make sure the desired ISAKMP policy on your firewall is at the top. This will decrease the negotiation time for Phase 1. Also make sure there is no fragmentation (MTU issues).

Regards

Farrukh

382
Views
0
Helpful
12
Replies