thinkbot
asked on
Need to access a PC connected to corporate network via Cisco VPN client
Hi,
We have a Cisco ASA firewall which has VPN access configured on it. Currently it assigns IP address to clients from the address pool administered by itself (ASA). User authentication is done by a RADIUS server (MS Network Policy Server). We also have Microsoft Active Directory environment.
Few of the PCs (Windows 7 OS) which do NOT belong to the company domain have Shrew Soft VPN clients installed. We need to access resources on them via this dynamic VPN connection (i.e. access them via hostname.contoso.com:1234).
To do that, I presume we need them to either have static IP addressess which we would have in advance or have these clients update DNS server with their current VPN adapter IP address.
We have tried so far:
- Configuring static IP address on Shrew Soft VPN client software. Doesn't work - ASA will refuse to establish VPN tunnel with the device if VPN software has static IP defined. If we could make ASA accept this static IP, this could be a solution.
- Configuring ASA to use MS DHCP server as a source to get IP address for clients. Addresses are issued just fine, the problem is that we cannot make a DHCP reservation because we see no MAC address. In the "Unique ID" field we have some very long hex string (~60 characters). Tried to create DHCP reservation using that field, but it appears that this string has one character which auto-increments with each VPN connection attempt. If we could make it static - this could be a solution.
- There is an option (I would say, an ugly one) to create local user accounts on Cisco ASA for these users in question and assign them IP addresses via ASA policy, keep all the other users connect via RADIUS authentication as before via their current VPN profile. This would perhaps be our last resort..
- Currently we are exploring option to use PowerShell script which would run locally on the PC which would
a) call VPN client and establish tunnel
b) find out the IP address assigned to the virtual VPN adapter
c) ask DNS server to delete old "A" entry for that host and create new "A" entry with the new IP address.
The problem with the last one is that to send an update to DNS server you need to have proper rights to access DNS server (which is also AD Domain Controller), that would mean embedding these credentials in the script which is not also a pleasant option.
Is there anything we are missing? Anything which we could use in addition to the above mentioned? Or tweak some existing option and get it to work somehow?
Would appreciate any help!
We have a Cisco ASA firewall which has VPN access configured on it. Currently it assigns IP address to clients from the address pool administered by itself (ASA). User authentication is done by a RADIUS server (MS Network Policy Server). We also have Microsoft Active Directory environment.
Few of the PCs (Windows 7 OS) which do NOT belong to the company domain have Shrew Soft VPN clients installed. We need to access resources on them via this dynamic VPN connection (i.e. access them via hostname.contoso.com:1234).
To do that, I presume we need them to either have static IP addressess which we would have in advance or have these clients update DNS server with their current VPN adapter IP address.
We have tried so far:
- Configuring static IP address on Shrew Soft VPN client software. Doesn't work - ASA will refuse to establish VPN tunnel with the device if VPN software has static IP defined. If we could make ASA accept this static IP, this could be a solution.
- Configuring ASA to use MS DHCP server as a source to get IP address for clients. Addresses are issued just fine, the problem is that we cannot make a DHCP reservation because we see no MAC address. In the "Unique ID" field we have some very long hex string (~60 characters). Tried to create DHCP reservation using that field, but it appears that this string has one character which auto-increments with each VPN connection attempt. If we could make it static - this could be a solution.
- There is an option (I would say, an ugly one) to create local user accounts on Cisco ASA for these users in question and assign them IP addresses via ASA policy, keep all the other users connect via RADIUS authentication as before via their current VPN profile. This would perhaps be our last resort..
- Currently we are exploring option to use PowerShell script which would run locally on the PC which would
a) call VPN client and establish tunnel
b) find out the IP address assigned to the virtual VPN adapter
c) ask DNS server to delete old "A" entry for that host and create new "A" entry with the new IP address.
The problem with the last one is that to send an update to DNS server you need to have proper rights to access DNS server (which is also AD Domain Controller), that would mean embedding these credentials in the script which is not also a pleasant option.
Is there anything we are missing? Anything which we could use in addition to the above mentioned? Or tweak some existing option and get it to work somehow?
Would appreciate any help!
ASKER
Hi ArneLovius,
Yes, you've got exactly what I meant.
Thanks for suggestions. The 1st option is something we have thought of, but didn't want to have separate VPN groups for every user who needs to be "accessed" plus separate VPN group for the rest of "normal" users, who do not have any resources on their PCs that we need to access.
The 2nd option seems very attractive. Could you please elaborate a bit on this option? What is being pushed, from where and to where?
Thanks
Yes, you've got exactly what I meant.
Thanks for suggestions. The 1st option is something we have thought of, but didn't want to have separate VPN groups for every user who needs to be "accessed" plus separate VPN group for the rest of "normal" users, who do not have any resources on their PCs that we need to access.
The 2nd option seems very attractive. Could you please elaborate a bit on this option? What is being pushed, from where and to where?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for the details.
Meanwhile it seems we have successfully implemented PowerShell script which will run locally on the PC, get adapter IP and pass it on to DNS server (it involves storing credentials required to access DNS server on that machine, but they can be at least stored encrypted and then decrypted (with the key which is also in the script, so yes, it only protects from the user which doesn't have bad intentions...). Since it only involves just 3 end-points, we will try the script first and later on will look into implementing your suggestion.
Thanks again!
Cheers
Meanwhile it seems we have successfully implemented PowerShell script which will run locally on the PC, get adapter IP and pass it on to DNS server (it involves storing credentials required to access DNS server on that machine, but they can be at least stored encrypted and then decrypted (with the key which is also in the script, so yes, it only protects from the user which doesn't have bad intentions...). Since it only involves just 3 end-points, we will try the script first and later on will look into implementing your suggestion.
Thanks again!
Cheers
if you store the key and the script together, you only have minimal obscurity from storing unencrypted...
You could of course use a different internal domain name (or a subdomain) for the computers to register against and not require secure updates to it...
You could of course use a different internal domain name (or a subdomain) for the computers to register against and not require secure updates to it...
ASKER
Yes, fully agree on your note, it's just minimal "security", for now it will do the job - we trust these users and if someone of them loses their endpoint or it potentially becomes compromised, we can block this account.
For DNS - since we have only 3 such users, it lowers the risk, so we will keep our current DNS setup. I think, eventually we will either implement your suggestion (with LDAP auth), or migrate our primary VPN access point to CheckPoint FW (and deal with what CheckPoint has to offer in this situation), whichever comes first on the timeline.
Thanks again!
For DNS - since we have only 3 such users, it lowers the risk, so we will keep our current DNS setup. I think, eventually we will either implement your suggestion (with LDAP auth), or migrate our primary VPN access point to CheckPoint FW (and deal with what CheckPoint has to offer in this situation), whichever comes first on the timeline.
Thanks again!
If this is the case, there are two other methods that you might look at
1/ use a different VPN group for each client with just one address in the pool that the VPN group uses
2/ push the IP address to be used as a RADIUS attribute