gmpon
asked on
Cisco 5505 VPN & Local access
Have a Cisco 5505 router attached to our network. Users can currently log in and have access to our network via the VPN connections. They just log into a machine we have set up for remote access.
Is there a way that the users can access their resources while hooked on through the VPN?
We have the "Allow local access" box checked on the client, but it doesn't give the users the access they need (data & print).
Another wish is for the user to log in ... run a local app but send the print output to a printer on our network via the VPN.
Is this bridging of networks doable via a VPN link? If so, how?
Thanx ...
Ming ...
Is there a way that the users can access their resources while hooked on through the VPN?
We have the "Allow local access" box checked on the client, but it doesn't give the users the access they need (data & print).
Another wish is for the user to log in ... run a local app but send the print output to a printer on our network via the VPN.
Is this bridging of networks doable via a VPN link? If so, how?
Thanx ...
Ming ...
Garry Glendown
Check the routing on the client - most likely you're not using "split tunneling", which means once the VPN tunnel is up, you have the default route (0.0.0.0/0) sent through the tunnel. Change the settings in the VPN profile for the appropriate profile to just use certain networks or IPs (LAN) for the tunnel, keeping the rest of the network left to the users' connection instead of your firewall ...
ASKER
Went into the ASA configuration ... Under Remote Access, Group Policies, Advanced, Split Tunnelling ...
Changed the policy to "Tunnel All Networks" ...
User still can't see his network ... he also indicates that even with the "allow access" checked, the status shows up as disabled.
I'm still not fully knowledgable as to what all the options under split tunnelling are:
Policy: I've changed it to Tunnel All networks, ideally, it would be only be a specific network I'm looking at ...
Network list: can be either capo, capi or split ... I have it set to split currently. Is there something I have to set under the 'Manage' button?
Intercept DHCP Configuration message from M/S clients:
currently set to inherit .. don't know where it's inheriting from ... but I could always uncheck and specify the actions I want here ... options under here are 'yes', 'no' and subnet mask.
Thanx ...
Ming ...
Changed the policy to "Tunnel All Networks" ...
User still can't see his network ... he also indicates that even with the "allow access" checked, the status shows up as disabled.
I'm still not fully knowledgable as to what all the options under split tunnelling are:
Policy: I've changed it to Tunnel All networks, ideally, it would be only be a specific network I'm looking at ...
Network list: can be either capo, capi or split ... I have it set to split currently. Is there something I have to set under the 'Manage' button?
Intercept DHCP Configuration message from M/S clients:
currently set to inherit .. don't know where it's inheriting from ... but I could always uncheck and specify the actions I want here ... options under here are 'yes', 'no' and subnet mask.
Thanx ...
Ming ...
"Tunnel all networks" is the opposite of what you want ...
Go to Remote Access VPN, Network (Client) Access, Group Policies,
then edit the group used for your users. Under advanced, go to Split tunneling.
Policy: Tunnel Network Liste Below
Network List: <some list of local networks> (click "Manage" if you didn't define it earlier)
That way, only the subnets configured should be routed through the VPN ...
Go to Remote Access VPN, Network (Client) Access, Group Policies,
then edit the group used for your users. Under advanced, go to Split tunneling.
Policy: Tunnel Network Liste Below
Network List: <some list of local networks> (click "Manage" if you didn't define it earlier)
That way, only the subnets configured should be routed through the VPN ...
ASKER
Think I may have it .. yesterday's testing gave the user access to his network, but cut off access to mine ...
Changes made and we'll be testing this morning again ....
Where I goofed up was following the instructions in the link to the letter when I should have applied some common sense and looked at what was already there ... I generated a second split ACL with only the outside network listed ... However, I already had a split ACL which listed my DMZ, internal and external lines ... So this morning, I just added the ACE (external network) to the already existing split ACL.
Assuming this works .. my next question then is ... is it possible to add an entry so that all external networks are covered? I added the ACE 192.168.0.0/24 to cover this one user. Can I add a 192.168.*.* somehow to cover any person coming in via the VPN?
Thanx ...
Ming ...
Changes made and we'll be testing this morning again ....
Where I goofed up was following the instructions in the link to the letter when I should have applied some common sense and looked at what was already there ... I generated a second split ACL with only the outside network listed ... However, I already had a split ACL which listed my DMZ, internal and external lines ... So this morning, I just added the ACE (external network) to the already existing split ACL.
Assuming this works .. my next question then is ... is it possible to add an entry so that all external networks are covered? I added the ACE 192.168.0.0/24 to cover this one user. Can I add a 192.168.*.* somehow to cover any person coming in via the VPN?
Thanx ...
Ming ...
Just change the mask to /16. So you get 192.168.0.0 255.255.0.0
ASKER
OK ... Not working the way we envision it ...
Have the following:
The policy is set to "List Below"
The network list is set to "split"
split
1 - 192.168.123.0/24
2 - dmz-network/24
3 - inside-network/24
4 - 192.168.0.0/20
192.168.123.0/24 are the addresses in our internal network.
The user can connect through the VPN. .. thay have full acces to our devices (did a print this morning via an IP address).
When they try to run a local app talking a server on their side 192.168.10.xxx ... it can't find their server. Their logging into the VPN seems to upset their IP's ...
What are we missing here to permit the user to talk to both our network and their network?
Thanx ...
Ming ...
Have the following:
The policy is set to "List Below"
The network list is set to "split"
split
1 - 192.168.123.0/24
2 - dmz-network/24
3 - inside-network/24
4 - 192.168.0.0/20
192.168.123.0/24 are the addresses in our internal network.
The user can connect through the VPN. .. thay have full acces to our devices (did a print this morning via an IP address).
When they try to run a local app talking a server on their side 192.168.10.xxx ... it can't find their server. Their logging into the VPN seems to upset their IP's ...
What are we missing here to permit the user to talk to both our network and their network?
Thanx ...
Ming ...
You do know that the 192.168.0.0/20 subnet covers all IP networks from 192.168.0.0 through 192.168.15.0, so you transport the user's LAN through to your site ...
change to:
192.168.0.0/21
192.168.8.0/23
192.168.11.0/24
192.168.12./22
and you should be good
change to:
192.168.0.0/21
192.168.8.0/23
192.168.11.0/24
192.168.12./22
and you should be good
ASKER
OK .. now I'm confused ... I was aware of the range covered ... maybe I'm mistaken as to how it's applied within the router ....
Correct me if I'm wrong ... If I add the 192.168.0.0/20 ... the data path is to try to redirect anything in that range to my site?... so I should not use that range in my ACE listing?
Isn't that the same as saying if I don't add their IP's (192.168.0.0 to 192.168.15.256) or any range that includes their IP's .. there shouldn't be an issue?
It appears to me we should just remove that entry so there's no need for redirection through the router of any kind. The app they're running is all local to them .. nothing to do with me, except for the redirect to an IP on my side for the printing ...
I see what you're saying ... maybe somewhere along the line our testing got muddled up ....
originally, they said they couldn't see our printer when they hooked on to the VPN. Then when I added the split, they said they could see the printer but couldn't see their own network. So one of these statements must be incorrect ...
Back to the drawing board ...
Ming ...
Correct me if I'm wrong ... If I add the 192.168.0.0/20 ... the data path is to try to redirect anything in that range to my site?... so I should not use that range in my ACE listing?
Isn't that the same as saying if I don't add their IP's (192.168.0.0 to 192.168.15.256) or any range that includes their IP's .. there shouldn't be an issue?
It appears to me we should just remove that entry so there's no need for redirection through the router of any kind. The app they're running is all local to them .. nothing to do with me, except for the redirect to an IP on my side for the printing ...
I see what you're saying ... maybe somewhere along the line our testing got muddled up ....
originally, they said they couldn't see our printer when they hooked on to the VPN. Then when I added the split, they said they could see the printer but couldn't see their own network. So one of these statements must be incorrect ...
Back to the drawing board ...
Ming ...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
After many gyrations ... the truth came out as to what we really needed.
Split tunnelling wasn't actually needed ... and the source of our problems was an IP conflict between their network and our DMZ ...
Thanx ...
Ming ...
Split tunnelling wasn't actually needed ... and the source of our problems was an IP conflict between their network and our DMZ ...
Thanx ...
Ming ...