How bout an ASA config?

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.

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

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.

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.

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

Thanks. I agree with your verdict.

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

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.

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

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.