VPN IPSec Client connectivity to ASA5510

Answered Question
Jun 26th, 2008

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.

I have this problem too.
0 votes
Correct Answer by Farrukh Haroon about 8 years 5 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
kerryjcox Thu, 06/26/2008 - 09:28

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.

kerryjcox Thu, 06/26/2008 - 10:56

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.

acomiskey Thu, 06/26/2008 - 11:51

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

kerryjcox Thu, 06/26/2008 - 12:00

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.

kerryjcox Thu, 06/26/2008 - 13:31

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.

Farrukh Haroon Thu, 06/26/2008 - 13:42

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

kerryjcox Thu, 06/26/2008 - 13:47

Thanks. I agree with your verdict.

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

kerryjcox Thu, 06/26/2008 - 13:46

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.

kaachary Mon, 06/30/2008 - 08:57

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

kerryjcox Mon, 06/30/2008 - 09:39

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.

Correct Answer
Farrukh Haroon Mon, 06/30/2008 - 12:16

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

Actions

This Discussion