06-26-2008 08:44 AM - edited 02-21-2020 02:53 AM
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.
Solved! Go to Solution.
06-30-2008 12:16 PM
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
06-26-2008 09:28 AM
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.
06-26-2008 10:38 AM
How bout an ASA config?
06-26-2008 10:56 AM
06-26-2008 11:51 AM
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
06-26-2008 12:00 PM
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.
06-26-2008 01:31 PM
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.
06-26-2008 01:42 PM
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
06-26-2008 01:47 PM
Thanks. I agree with your verdict.
I decided to go with 192.168.111.0/24. Plain and simple.
06-26-2008 01:46 PM
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.
06-30-2008 08:57 AM
Keyword "any" is not supported in split tunnel ACL. Put specific networks, and you should be good to go.
06-30-2008 09:39 AM
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.
06-30-2008 12:16 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: