adowns
asked on
Using Cisco vpn client & local network
I connect to work via vpn with the cisco vpn client. When I am connected I cannot use the internet or my local network. Is there any way to configure my windows 2000 workstation so I can at least access my local network while I'm connected through vpn? I'm on an adsl connection and am behind a linsys dsl router at home if it matters. I can provide more info if needed.
This is a feature. The folks who setup your VPN don't want your machine to become a backdoor gateway between the Internet and the company network. You should speak to the VPN folks at your company about it.
I'm guessing the VPN client (or possibly the info it is receiving from the server) is misconfigured, or lazily configured. Your problems are likely due to a routing adjustment that is sending all traffic through the VPN, rather than simply sending traffic destined for the networks that are actually on the other side of the VPN connection. I would not see a proper config that allowed access to both the VPN nets and the internet to be any more of a security hazard - as long as your VPN client can turn off IP forwarding/routing, there should be no concern (or at least no more concern than if it was maladjusting your routes toward the same end)
Cheers,
-Jon
Cheers,
-Jon
Of course there's a concern. Companies spend lots of money on things like porn filters and malware filters and don't want their employees bypassing them to inject viri and/or porn into the organization.
You may consider this evil, depending on your political bent, but it's true.
You may consider this evil, depending on your political bent, but it's true.
My point is that manipulating the routing table is no more secure than disabling forwarding, but has the potential to make life miserable for no good reason for the end-user.
In other words - explain to me how it is more secure to deny access to the entire internet while connected to the VPN rather than simply denying traffic passage betwen the VPN and the internet...
-Jon
In other words - explain to me how it is more secure to deny access to the entire internet while connected to the VPN rather than simply denying traffic passage betwen the VPN and the internet...
-Jon
I thought I did that already.
Companies want you to pass through their virur/malware filters and porn filters. They can't do that if you can directly access the Internet without going through their proxy/firewall infrastructure.
Companies want you to pass through their virur/malware filters and porn filters. They can't do that if you can directly access the Internet without going through their proxy/firewall infrastructure.
>Companies want you to pass through their virur/malware
>filters and porn filters. They can't do that
>if you can directly access the Internet without going
>through their proxy/firewall infrastructure.
????
Somehow I don't think that's the case, since the original question clearly stated that the VPN connection does not route traffic (or proxy it) to the internet.
In any case, could you please enlighten me as to how a routing table change is more secure than disabling IP forwarding? If you are not making this claim, then I think we are in agreement (although I cannot then figure out why you object to simultaneous net/vpn access).
In any case, the inability to use the local LAN when the VPN is active is just plain silly (what if you are using a non-IP based protocol? Or does the VPN just crap all over the existing networking stack? What if you are using an additional 3rd party networking stack?) - it indicates a misconfigured VPN system.
The bottom line is that when you allow someone to connect to your VPN , you allow them a certain amount of trust which is greater than that given to the general public. I've yet to see a VPN system that could enforce remote security - that is accomplished by a good understanding of security on both ends.
adowns - just get a router that supports connections to a cisco VPN, and then just add routes to your windoze config for the VPN subnets, pointing at the VPN router. Done and done.
-Jon
>filters and porn filters. They can't do that
>if you can directly access the Internet without going
>through their proxy/firewall infrastructure.
????
Somehow I don't think that's the case, since the original question clearly stated that the VPN connection does not route traffic (or proxy it) to the internet.
In any case, could you please enlighten me as to how a routing table change is more secure than disabling IP forwarding? If you are not making this claim, then I think we are in agreement (although I cannot then figure out why you object to simultaneous net/vpn access).
In any case, the inability to use the local LAN when the VPN is active is just plain silly (what if you are using a non-IP based protocol? Or does the VPN just crap all over the existing networking stack? What if you are using an additional 3rd party networking stack?) - it indicates a misconfigured VPN system.
The bottom line is that when you allow someone to connect to your VPN , you allow them a certain amount of trust which is greater than that given to the general public. I've yet to see a VPN system that could enforce remote security - that is accomplished by a good understanding of security on both ends.
adowns - just get a router that supports connections to a cisco VPN, and then just add routes to your windoze config for the VPN subnets, pointing at the VPN router. Done and done.
-Jon
adowns,
To allow local lan access while connected, there is a checkbox under the VPN client properties, General tab. Checking this will allow you to access your local network at the same time as the corporate network.
Regarding connection to the Internet while connected, this is configurable by the network admin only. They must allow "split tunneling" at the connection point. There is nothing on the client end that will allow it. As Chris pointed out, this is a security concern and most admins will not allow split tunneling. However, if their end is configured correctly, and they want to allow it, you should be able to access the Internet through THEIR connection.
To allow local lan access while connected, there is a checkbox under the VPN client properties, General tab. Checking this will allow you to access your local network at the same time as the corporate network.
Regarding connection to the Internet while connected, this is configurable by the network admin only. They must allow "split tunneling" at the connection point. There is nothing on the client end that will allow it. As Chris pointed out, this is a security concern and most admins will not allow split tunneling. However, if their end is configured correctly, and they want to allow it, you should be able to access the Internet through THEIR connection.
ASKER
Irmoore
I have tried that setting and have had no success getting it to work for LAN access.
I have tried that setting and have had no success getting it to work for LAN access.
lrmoore - I don't think you are correct. The very fact that a cisco vpn client for linux exists suggests that the client does nothing more than adjusts the routing table, ip forwarding, or another common network parameter. This would seem to indicate (as I originally stated) that the client networking config, if readjusted, could overcome any such modifications by the vpn client software. Also, the fact that the cisco vpn client uses IPSEC only underscores by point - there is nothing to limit "split tunneling" in the IPSEC standard...
Folks, let get this clear - a vpn is used to simulate a secure (usually meaning heavily encrypted) point-to-point wan link between two networks. Period. It the same thing as if you had a T1 (or other leased line) between two locations. The responsibility for securing the traffic that passes over the link falls upon the admins of the respective networks on the ends of the link. VPNs are not intended to be a security panacea - just a nice way to get your traffic across the public internet without being able to be intercepted (or at least in a meaningful way).
In any case:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/linux30x/user_gd/intro.htm
>The VPN client distinguishes between tunneled and
>nontunneled traffic and, depending on your server
>configuration, allows simultaneous access to the
>corporate network and to Internet resources.
so adowns, you should be able to do what you want - may I suggest examining the differences between your network config before and after connecting to the vpn?
Cheers,
-Jon
Folks, let get this clear - a vpn is used to simulate a secure (usually meaning heavily encrypted) point-to-point wan link between two networks. Period. It the same thing as if you had a T1 (or other leased line) between two locations. The responsibility for securing the traffic that passes over the link falls upon the admins of the respective networks on the ends of the link. VPNs are not intended to be a security panacea - just a nice way to get your traffic across the public internet without being able to be intercepted (or at least in a meaningful way).
In any case:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/linux30x/user_gd/intro.htm
>The VPN client distinguishes between tunneled and
>nontunneled traffic and, depending on your server
>configuration, allows simultaneous access to the
>corporate network and to Internet resources.
so adowns, you should be able to do what you want - may I suggest examining the differences between your network config before and after connecting to the vpn?
Cheers,
-Jon
Actaully, I realize I was over-generalizing a bit - the IPSEC standard could do that if the remote side is claiming a remote network range of 0.0.0.0/0.0.0.0, which is a misconfig if the remote side does not allow access to the public net over the vpn. However, this could be easily corrected/defeated in linux (so my original point remains) - not sure what the commands would be in windoze, though...
Cheers,
-Jon
Cheers,
-Jon
adowns - just get a linux router, and all will be well.
adowns,
What version of client are you using? What is the termination point, a VPN concentrator or a PIX FW? Other?
I'm using 3.5 client to PIX and have no problem accessing local LAN at the same time I access the corporate LAN, and my own Internet connection all at the same time. Of course, I own the PIX, too, so I have complete control of both sides of the equation.
Jon -
You are correct, and as I stated earlier, that the ADMINISTRATOR of the ENDPOINT (server configuration) controls whether or not the client has simultaneous access to the corporate lan and the Internet. It is not something you can configure on the client end.
It also uses a deterministic network enhancer. It does not merely update or change the routing table. If you do a ROUTE PRINT, you will see no evidence of a connection through the secure tunnel, unlike with a PPTP client that uses an NDIS wrapper and does change the route table, and is completely configurable by the end user (bad).
What version of client are you using? What is the termination point, a VPN concentrator or a PIX FW? Other?
I'm using 3.5 client to PIX and have no problem accessing local LAN at the same time I access the corporate LAN, and my own Internet connection all at the same time. Of course, I own the PIX, too, so I have complete control of both sides of the equation.
Jon -
You are correct, and as I stated earlier, that the ADMINISTRATOR of the ENDPOINT (server configuration) controls whether or not the client has simultaneous access to the corporate lan and the Internet. It is not something you can configure on the client end.
It also uses a deterministic network enhancer. It does not merely update or change the routing table. If you do a ROUTE PRINT, you will see no evidence of a connection through the secure tunnel, unlike with a PPTP client that uses an NDIS wrapper and does change the route table, and is completely configurable by the end user (bad).
ASKER
I will look at the version, but I don't think its as new as 3.5
Where can I get 3.5 to try it?
Where can I get 3.5 to try it?
If you have a CCO login, you can download it from Cisco's Software Center...
Jon/Captain,
You're right that I didn't address the specific issue of routing tables. Sorry about that. Meanwhile, I think the answer is yes, it craps all over your IP stack.
From the standpoint of someone who might admin a large corporate network, this is a good thing.
It's not that you don't trust your users in general, it's that you want to verify that that they're not doing stupid things (like bypassing the corporate virus scanners).
You're right that I didn't address the specific issue of routing tables. Sorry about that. Meanwhile, I think the answer is yes, it craps all over your IP stack.
From the standpoint of someone who might admin a large corporate network, this is a good thing.
It's not that you don't trust your users in general, it's that you want to verify that that they're not doing stupid things (like bypassing the corporate virus scanners).
I guess my point is this -
Whatever the client is doing to the network stack is indicative of a misconfig. The terms "client" and "server" have no more place in vpn discussions than the do in leased line discussions, despite the fact that cisco marketing would have you believe otherwise. Yes, there may be a perceived server, just as in a leased line scenario, where one (or both) end(s) must authenticate to another, but that's all there is to it. To claim to route to IPs that you will not (via an overly large IPSEC subnet export) is a misconfiguration, regardless of any perceived benefits of said misconfiguration. Another hint that this is a misconfiguration is that you can fix it on linux, which does not allow cisco to proprietarily adjust the network stack.
Once again, for those who missed it (or misunderstood). The admin of each end is responsible for security on their end, and their end only. A mututally acceptable vpn security policy *has* to be arrived at between these two administration entities, since it *cannot* be enforced technologically across every platform.
As much as we would all love to give vpn users free and clear access to our internal networks just as if they were physically present, it is a pipe dream. Unless you have security people on both sides who are going to secure each end of the pipe (make sure it is not connected to external nets), you are begging for breaches galore if you do not implement some sort of firewall or other restricted access at your endpoint of the vpn.
If this is what adowns's company is doing (attempting to enforce security externally, rather than internally), I am laughing at the admins... They are as good as hacked already.
Personally, just so you know, I set up VPNs with no regard to end-user config/software - they can have one billion sub-seven infestations, for all I care. All I know is that they are not getting through the vpn firewall to do any damage - they only have access to the internal resources I have granted. Why is this so hard to understand?
Cheers,
-Jon
Whatever the client is doing to the network stack is indicative of a misconfig. The terms "client" and "server" have no more place in vpn discussions than the do in leased line discussions, despite the fact that cisco marketing would have you believe otherwise. Yes, there may be a perceived server, just as in a leased line scenario, where one (or both) end(s) must authenticate to another, but that's all there is to it. To claim to route to IPs that you will not (via an overly large IPSEC subnet export) is a misconfiguration, regardless of any perceived benefits of said misconfiguration. Another hint that this is a misconfiguration is that you can fix it on linux, which does not allow cisco to proprietarily adjust the network stack.
Once again, for those who missed it (or misunderstood). The admin of each end is responsible for security on their end, and their end only. A mututally acceptable vpn security policy *has* to be arrived at between these two administration entities, since it *cannot* be enforced technologically across every platform.
As much as we would all love to give vpn users free and clear access to our internal networks just as if they were physically present, it is a pipe dream. Unless you have security people on both sides who are going to secure each end of the pipe (make sure it is not connected to external nets), you are begging for breaches galore if you do not implement some sort of firewall or other restricted access at your endpoint of the vpn.
If this is what adowns's company is doing (attempting to enforce security externally, rather than internally), I am laughing at the admins... They are as good as hacked already.
Personally, just so you know, I set up VPNs with no regard to end-user config/software - they can have one billion sub-seven infestations, for all I care. All I know is that they are not getting through the vpn firewall to do any damage - they only have access to the internal resources I have granted. Why is this so hard to understand?
Cheers,
-Jon
Obviously you've never worked for a company with 10,000 VPN users who all have access to "everything" (since there are too many to give them specific access only to the things they need given staffing of the remote access group).
Yes, you can get around whatever stuff you put in place on the PC, but at least it helps.
Yes, you can get around whatever stuff you put in place on the PC, but at least it helps.
>since there are too many to give them specific access
>only to the things they need given staffing of
>the remote access group
I don't see how management's refusal to implement proper security is relevant to this question.
I'm sticking to my guns.
Cheers,
-Jon
>only to the things they need given staffing of
>the remote access group
I don't see how management's refusal to implement proper security is relevant to this question.
I'm sticking to my guns.
Cheers,
-Jon
Actually, I guess it may be relevant in the respect that it may be what is happening to adowns, but it does not change the fact that
a. it can be worked around
b. it constitutes a misconfig, and a security hole.
adowns should point this out and ask for a raise hehe..
Cheers,
-Jon
a. it can be worked around
b. it constitutes a misconfig, and a security hole.
adowns should point this out and ask for a raise hehe..
Cheers,
-Jon
http://www.zonelabs.com/corpsales/intOverview.html
These guys are making an effort at endpoint security.
These guys are making an effort at endpoint security.
Captain-
Since you compared a VPN tunnel to a "Virtual" T1 line, do you see a lot of companies providing a dedicated internet connection to everyone of their locations? Yeah sure, I can bypass the security mechanism that the VPN Client provides, but can an average user? The CiscoVPN client's support of Linux was an effort to be a "complete" solution. I can roll out a very simple and elegant solution with linux as easily as windows. When you are building a security solution, you must look at it as "If it can happen, it will happen." You must look at users (No offense here) as having the intelligence (about computer security) of cows. Yes there are exceptions, but mostly there are not. Since the majority is what gets you in trouble, that is who you cater to. I can bypass the security mechanism, but is it worth it if I get caught, and get fired over not following the "computer usage policy"?
Since you compared a VPN tunnel to a "Virtual" T1 line, do you see a lot of companies providing a dedicated internet connection to everyone of their locations? Yeah sure, I can bypass the security mechanism that the VPN Client provides, but can an average user? The CiscoVPN client's support of Linux was an effort to be a "complete" solution. I can roll out a very simple and elegant solution with linux as easily as windows. When you are building a security solution, you must look at it as "If it can happen, it will happen." You must look at users (No offense here) as having the intelligence (about computer security) of cows. Yes there are exceptions, but mostly there are not. Since the majority is what gets you in trouble, that is who you cater to. I can bypass the security mechanism, but is it worth it if I get caught, and get fired over not following the "computer usage policy"?
adowns,
Yes, it is possible to bypass the non split tunneling policy of your company, but what happens if you unwittingly cause a problem either with security, a virus, or something else. Is it worth your job to have internet access while VPN'd into your company although it is against the security policy of your company?
Yes, I can tell you that your company's non split tunneling policy is intentional. I manage a cisco VPN solution, and it is my intention not to allow split tunneling also.
Yes, it is possible to bypass the non split tunneling policy of your company, but what happens if you unwittingly cause a problem either with security, a virus, or something else. Is it worth your job to have internet access while VPN'd into your company although it is against the security policy of your company?
Yes, I can tell you that your company's non split tunneling policy is intentional. I manage a cisco VPN solution, and it is my intention not to allow split tunneling also.
If you are wanting to share files.....
Just turn on netbeui.
Just turn on netbeui.
>The CiscoVPN client's support of Linux was an
>effort to be a "complete" solution
Which perfectly illustrates why cisco's view of things in this case is rather broken (from a technical standpoint - from a marketing standpoint, it's flawless). Sorry to burst your bubble, but cisco != correct (necessarily). Or shall I dregde up countless IOS bugs(/features) to prove my point?
>Yes, I can tell you that your company's non split
>tunneling policy is intentional. I manage a cisco
>VPN solution, and it is my intention not to allow split
>tunneling also.
t1n0m3n - Let us know when your security policy winds up getting you hacked. Also, please play nice and submit your comments as such rather than as an "answer", since all you did is duplicate things that have already been said. I would hope adowns notices this and rejects your answer.
adowns - as I and others have said, this should be an AUP issue, not a technical one. Broken technical solutions like this are generally an excuse to point the finger elsewhere. CEO to Manager: "Why did we get hacked?". Manager to IT head: "Why dd we get hacked?". IT head to IT peon: "Why did we get hacked?". IT peon: "I dunno - cisco said it was OK - blame them". CEO hears: "It was a cisco problem", and doesn't have to fire wanyone (or maybe just IT peon).
An AUP solutuion allows instant accountability - imagine instead - IT peon: "Looks like John Smith was violating the AUP and opened up a backdoor". CEO cans John Smith. AUP violations drop to nearly zero. I assume it's political that this kind of solution is avoided where it's most needed.
Cheers,
-Jon
>effort to be a "complete" solution
Which perfectly illustrates why cisco's view of things in this case is rather broken (from a technical standpoint - from a marketing standpoint, it's flawless). Sorry to burst your bubble, but cisco != correct (necessarily). Or shall I dregde up countless IOS bugs(/features) to prove my point?
>Yes, I can tell you that your company's non split
>tunneling policy is intentional. I manage a cisco
>VPN solution, and it is my intention not to allow split
>tunneling also.
t1n0m3n - Let us know when your security policy winds up getting you hacked. Also, please play nice and submit your comments as such rather than as an "answer", since all you did is duplicate things that have already been said. I would hope adowns notices this and rejects your answer.
adowns - as I and others have said, this should be an AUP issue, not a technical one. Broken technical solutions like this are generally an excuse to point the finger elsewhere. CEO to Manager: "Why did we get hacked?". Manager to IT head: "Why dd we get hacked?". IT head to IT peon: "Why did we get hacked?". IT peon: "I dunno - cisco said it was OK - blame them". CEO hears: "It was a cisco problem", and doesn't have to fire wanyone (or maybe just IT peon).
An AUP solutuion allows instant accountability - imagine instead - IT peon: "Looks like John Smith was violating the AUP and opened up a backdoor". CEO cans John Smith. AUP violations drop to nearly zero. I assume it's political that this kind of solution is avoided where it's most needed.
Cheers,
-Jon
>I assume it's political that this kind of solution is
>avoided where it's most needed
Actually, I should remember to never attribute to malice which can be explained by laziness.
t1n0m3n - sure is easier to configure non-split tunneling than to actually set up security with regard to your VPN users, isn't it? At least until your boss comes around asking why all the servers are dead. Or will you just blame cicso, even though you were well aware of the problem?
For probably the fiftieth time, I will try to cram this all-important fact into your heads. VPN users cannot be trusted - you need to have more security in place for them above and beyond "Duh, well, they can't access the internet when they're talking to us". How does this in any way address trojans/zombies/virii that made it onto your VPN user's computer *before* they ever started talking to you?!?! If you think preventing simultaneous access is a VPN security panacea, then just remove all those code red patches from your NT boxes that your VPN users use, and watch how fast they get re-infected.
One more time, because I know some of you still missed it:
VPN do not imply any sort of trust between endpoints, with regard to the actual data to be exchanged (where folks got this idea is beyond me). They are simply a means to transport data securely (meaning no one can decrypt the transferred data in transit). Anyone that thinks or says otherwise is trying to sell you something (like cisco).
Does anyone have any evidence (other than anecdotal) to contradict what I am saying?
Cheers,
-Jon
>avoided where it's most needed
Actually, I should remember to never attribute to malice which can be explained by laziness.
t1n0m3n - sure is easier to configure non-split tunneling than to actually set up security with regard to your VPN users, isn't it? At least until your boss comes around asking why all the servers are dead. Or will you just blame cicso, even though you were well aware of the problem?
For probably the fiftieth time, I will try to cram this all-important fact into your heads. VPN users cannot be trusted - you need to have more security in place for them above and beyond "Duh, well, they can't access the internet when they're talking to us". How does this in any way address trojans/zombies/virii that made it onto your VPN user's computer *before* they ever started talking to you?!?! If you think preventing simultaneous access is a VPN security panacea, then just remove all those code red patches from your NT boxes that your VPN users use, and watch how fast they get re-infected.
One more time, because I know some of you still missed it:
VPN do not imply any sort of trust between endpoints, with regard to the actual data to be exchanged (where folks got this idea is beyond me). They are simply a means to transport data securely (meaning no one can decrypt the transferred data in transit). Anyone that thinks or says otherwise is trying to sell you something (like cisco).
Does anyone have any evidence (other than anecdotal) to contradict what I am saying?
Cheers,
-Jon
ASKER
t1n0m3n
it still doesn't work with netbeui on
it still doesn't work with netbeui on
Captain
Did I say that was all that I was doing to secure my network in regards to VPN? No I did not. It just makes it easier (and a lot less variables) to not allow split tunneling.
I apologize for pressing "answer."
This my 3rd time on this board after signing up.
I am sorry that 99% of the security teams out there cannot be as smart as you (including me) and configure split tunneling correctly.
I had split tunneling on for a while until I had VPN users' neighbors' windows domains show up in my Network Neighborhood. There was nothing I could do because the user's PC was configured wrong and was passing this information to my company. When your VPN User's neighbor chooses to put his/her computer in the "L337H4x0rz" domain, try explaining that to your CIO.
Did I say that was all that I was doing to secure my network in regards to VPN? No I did not. It just makes it easier (and a lot less variables) to not allow split tunneling.
I apologize for pressing "answer."
This my 3rd time on this board after signing up.
I am sorry that 99% of the security teams out there cannot be as smart as you (including me) and configure split tunneling correctly.
I had split tunneling on for a while until I had VPN users' neighbors' windows domains show up in my Network Neighborhood. There was nothing I could do because the user's PC was configured wrong and was passing this information to my company. When your VPN User's neighbor chooses to put his/her computer in the "L337H4x0rz" domain, try explaining that to your CIO.
Also, If the VPN client could manipulate the routing table to secure the VPN tunnel againt "backdooring", isn't it concievable that another program could reverse those changes?
I would think you don't have to be L337H4x0rz to understand how to manage your netbios network securely (why are you accepting traffic on port 137-139 from any hosts other than the client VPN endpoint? If the traffic *was* from the client endpoint, how could you tell the difference between traffic originated by a potential zombie/trojan and translated traffic from unauthorized sites connecting through the split tunnel?)
>I am sorry that 99% of the security teams out there
>cannot be as smart as you (including me) and configure
>split tunneling correctly.
Not sure where that came from - all I'm saying is that this whole split-tunneling argument is ridiculous. It's not a question of whether or not it's configured correctly, since it really doesn't matter in the end as far as the client is concerned. It's a question of whether or not the internal network is secure. If it's not, then no amount of mucking around with client-side workarounds will provide such security - to think so is to place trust where none should exist (which is the leading cause of hacks - misplaced trust).
adowns - I am getting tired of arguing an obvious point - how do you want to proceed here? Do you want help in working around your corporate security policy (which, as I have said, should not be too difficult, and will prove a valuable point to your IT folks), or are you content to live with your corporate security policy (flawed though it may be), since they could conceivably take you to task for violating it? I await your response.
Since we all agree working around such misguided policies is possible, can we stop splitting hairs arguing about just *how* misguided it is, and help adowns?
Cheers,
-Jon
>I am sorry that 99% of the security teams out there
>cannot be as smart as you (including me) and configure
>split tunneling correctly.
Not sure where that came from - all I'm saying is that this whole split-tunneling argument is ridiculous. It's not a question of whether or not it's configured correctly, since it really doesn't matter in the end as far as the client is concerned. It's a question of whether or not the internal network is secure. If it's not, then no amount of mucking around with client-side workarounds will provide such security - to think so is to place trust where none should exist (which is the leading cause of hacks - misplaced trust).
adowns - I am getting tired of arguing an obvious point - how do you want to proceed here? Do you want help in working around your corporate security policy (which, as I have said, should not be too difficult, and will prove a valuable point to your IT folks), or are you content to live with your corporate security policy (flawed though it may be), since they could conceivably take you to task for violating it? I await your response.
Since we all agree working around such misguided policies is possible, can we stop splitting hairs arguing about just *how* misguided it is, and help adowns?
Cheers,
-Jon
You obviously don't have experience in a big corporate environment. If you did you would be able to see my points.
2 Solutions here
1. Bypass security and risk getting terminated.
2. Live with it and be frustrated.
2 Solutions here
1. Bypass security and risk getting terminated.
2. Live with it and be frustrated.
Captain: I have a different take on this issue. Suppose for example, I allowed split-tunneling and protected my network via a firewall between my internal network and the inside of my VPN concentrator which limited access as strictly as possible. Then, the remote PC connected via VPN is "hijacked" (even via a common hole like VNC or PC Anywhere) by someone else via the internet because I can not control what other traffic is going to this user while they are connected to my network. No matter how good my ruleset is on the firewall between the VPN concentrator and the internal network, there is no way I can prevent this foriegn entity from gaining some form of access to the network. As you stated above, I would be placing trust where none should exist. How can I be sure the remote user's PC is secure? I would suggest a combination of very selective rules for network access (either on a firewall or via access-filters on the VPN platform) and not allowing split-tunneling. On another note, to guarantee that the user's authenticity I would suggest using a CA server instead a shared key and some form of token based user authentication. This at least gives greater assurance that the resources you have opened your network up to are being used by the users you intended to give access to. One last point, who cares if a user does not have access to the rest of the Internet while connected to VPN? Perhaps this can act as incentive for the user to connect, get the work done that the user needs to accomplish and then disconnect.
ASKER
I can think of a few good reasons.
Say a user is working from home in the summer, 5 days/week, 8 hours/day.
This user will connect via VPN and login with their account. While logged into their account they can access thier files, various applications, etc. But since they do not have internet connectivity they cannot do their normal internet research, or send or recieve email.
Say this user is an administrator in our company, and the superintendent emails this user with an important document or an employee emails a Purchase order which needs approval. The user does not have access to half of their every day tasks to sucessfully work at a remote location.
I know you guys are going to say just have them disconnect from the vpn session. But what if whet are connected via terminal services? Then every time they disconnect from vpn they loose their session with terminal services. etc., etc.
Say a user is working from home in the summer, 5 days/week, 8 hours/day.
This user will connect via VPN and login with their account. While logged into their account they can access thier files, various applications, etc. But since they do not have internet connectivity they cannot do their normal internet research, or send or recieve email.
Say this user is an administrator in our company, and the superintendent emails this user with an important document or an employee emails a Purchase order which needs approval. The user does not have access to half of their every day tasks to sucessfully work at a remote location.
I know you guys are going to say just have them disconnect from the vpn session. But what if whet are connected via terminal services? Then every time they disconnect from vpn they loose their session with terminal services. etc., etc.
>You obviously don't have experience in a big corporate
>environment. If you did you would be able to
>see my points.
Stop making grossly rash assumptions. The way I see it, you obviously have very little experience saying "no" to corporate managers who demand technically impossible solutions. I'll watch for you in the unemployment line when you get fired because you said it was secure rather then telling your boss the truth. At least we agree on the following:
>1. Bypass security and risk getting terminated.
>2. Live with it and be frustrated.
helmet - you make some good points - the only thing I would change is to not worry about split tunneling - just assume the worse (that the end user will circumvent it or get hacked, run trojans, etc) and rely on your internal security (which should be appropriately strong), since you can never be sure the end user is secure.
adowns - we seem to be quickly returning to flogging the dead horse wrt whether or not split-tunneling is a good idea (I agree there are very many good reasons to allow split-tunneling, and very few good reasons to disallow it [although there are plenty of bad reasons - just ask t1n0m3n, although I'm not sure he realizes that they are bad reasons]). I ask again - how would you like to proceed?
Cheers,
-Jon
P.S. Is EE *ever* going to fix their continuous problem regarding email notifications? I received 1 notification for the last 3 posts...
>environment. If you did you would be able to
>see my points.
Stop making grossly rash assumptions. The way I see it, you obviously have very little experience saying "no" to corporate managers who demand technically impossible solutions. I'll watch for you in the unemployment line when you get fired because you said it was secure rather then telling your boss the truth. At least we agree on the following:
>1. Bypass security and risk getting terminated.
>2. Live with it and be frustrated.
helmet - you make some good points - the only thing I would change is to not worry about split tunneling - just assume the worse (that the end user will circumvent it or get hacked, run trojans, etc) and rely on your internal security (which should be appropriately strong), since you can never be sure the end user is secure.
adowns - we seem to be quickly returning to flogging the dead horse wrt whether or not split-tunneling is a good idea (I agree there are very many good reasons to allow split-tunneling, and very few good reasons to disallow it [although there are plenty of bad reasons - just ask t1n0m3n, although I'm not sure he realizes that they are bad reasons]). I ask again - how would you like to proceed?
Cheers,
-Jon
P.S. Is EE *ever* going to fix their continuous problem regarding email notifications? I received 1 notification for the last 3 posts...
Hi adowns:
I've been watching this discussion for quite awhile now and so far haven't seen an answer to your problem posted, only discussion about why you have the problem and whether or not you should.
There have been many good points raised on this topic,
however no one is describing a clear solution, the fact is, depending upon the Cisco device to which you are trying to connect with your Cisco VPN client, it may not be possible to do split-tunneling without changes being made. Further, this is because in using the Cisco VPN client with Split-Tunneling, the network administration where you are trying to connect has to be willing to allow you to use split-tunneling. Certain configuration parameters in a Cisco Concentrator,PIX or Router must be configured for you to Split-tunnel with your Cisco client software on a Win2K machine. It is perhaps out of your control.
This is clearly stated in this link and I think that you will see an answer to your question
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel_3_5/user_gd/vc3.htm#xtocid1144518
This may not be what you want to hear, but is accurate. Sincerely, Chriskohn
I've been watching this discussion for quite awhile now and so far haven't seen an answer to your problem posted, only discussion about why you have the problem and whether or not you should.
There have been many good points raised on this topic,
however no one is describing a clear solution, the fact is, depending upon the Cisco device to which you are trying to connect with your Cisco VPN client, it may not be possible to do split-tunneling without changes being made. Further, this is because in using the Cisco VPN client with Split-Tunneling, the network administration where you are trying to connect has to be willing to allow you to use split-tunneling. Certain configuration parameters in a Cisco Concentrator,PIX or Router must be configured for you to Split-tunnel with your Cisco client software on a Win2K machine. It is perhaps out of your control.
This is clearly stated in this link and I think that you will see an answer to your question
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel_3_5/user_gd/vc3.htm#xtocid1144518
This may not be what you want to hear, but is accurate. Sincerely, Chriskohn
ASKER
Perhaps I'm not familliar enough with split tunneling to make an accurate statement here...but here goes.
From what I'm reading above, I agree using the internet at a remote location along with being connected through vpn at the same time is not a good idea.
What about setting up some routing so when the remote
location is connected via vpn they use the internet OF the remote location they are connecting to. This way your companies (filter, firewall, monitoring) still work for the remote user just as if he were in the actual building?
From what I'm reading above, I agree using the internet at a remote location along with being connected through vpn at the same time is not a good idea.
What about setting up some routing so when the remote
location is connected via vpn they use the internet OF the remote location they are connecting to. This way your companies (filter, firewall, monitoring) still work for the remote user just as if he were in the actual building?
>From what I'm reading above, I agree using the internet
>at a remote location along with being connected
>through vpn at the same time is not a good idea
Looks like I wasted my breath (sigh).
>What about setting up some routing so when the remote
>location is connected via vpn they use the internet OF
>the remote location they are connecting to. This
>way your companies (filter, firewall, monitoring) still
>work for the remote user just as if he were
>in the actual building?
This scenario is not unreasonable if you don't understand what a VPN is for (which should accurately describe your IT guys, from what you have been telling us). Why your company is choosing to ignore both points of view and go for an approach that completely breaks regular connectivity is beyond me.
Once again - I would really like to know what you want to do (I don't know why Chriskohn is accusing no one of providing answers - he obviously missed the past posts where I have asked how to proceed...) Do you want us to work with you on getting around your company's boneheaded policies resulting from their misunderstanding of what a VPN is for, or do you simply want to know that it is possible to have net connectivity through them? If so, then the answer is yes. Please elucidate...
Cheers,
-Jon
>at a remote location along with being connected
>through vpn at the same time is not a good idea
Looks like I wasted my breath (sigh).
>What about setting up some routing so when the remote
>location is connected via vpn they use the internet OF
>the remote location they are connecting to. This
>way your companies (filter, firewall, monitoring) still
>work for the remote user just as if he were
>in the actual building?
This scenario is not unreasonable if you don't understand what a VPN is for (which should accurately describe your IT guys, from what you have been telling us). Why your company is choosing to ignore both points of view and go for an approach that completely breaks regular connectivity is beyond me.
Once again - I would really like to know what you want to do (I don't know why Chriskohn is accusing no one of providing answers - he obviously missed the past posts where I have asked how to proceed...) Do you want us to work with you on getting around your company's boneheaded policies resulting from their misunderstanding of what a VPN is for, or do you simply want to know that it is possible to have net connectivity through them? If so, then the answer is yes. Please elucidate...
Cheers,
-Jon
ASKER
My interpretation of a vpn client is someone at a remote location who could securely connect to resources within their company. I understand the security involved in networking, but there is always a way to do something and do it right. I'm not ignoring all that was said above, but with the proper security, routes, firewalls, encryption, filtering, monitoring, etc. I don't see why it ultimately would not work and be secure. The ultimate use of a computer is for convenience, to say why sacrafice security for convenience I think is an inaccurate statement. There should never be a reason to sacrafice security though. First question which was answered, "Is it possible to use the internet and VPN at once?" Yes.
Is it secure? No.
Can we make it secure? How do we make it secure? Can we make the remote machine use the internet connection as if the remote computer was in the building behind all the companies firewalls and networking security? etc., etc.
Is it secure? No.
Can we make it secure? How do we make it secure? Can we make the remote machine use the internet connection as if the remote computer was in the building behind all the companies firewalls and networking security? etc., etc.
ASKER
My interpretation of a vpn client is someone at a remote location who could securely connect to resources within their company. I understand the security involved in networking, but there is always a way to do something and do it right. I'm not ignoring all that was said above, but with the proper security, routes, firewalls, encryption, filtering, monitoring, etc. I don't see why it ultimately would not work and be secure. The ultimate use of a computer is for convenience, to say why sacrafice security for convenience I think is an inaccurate statement. There should never be a reason to sacrafice security though. First question which was answered, "Is it possible to use the internet and VPN at once?" Yes.
Is it secure? No.
Can we make it secure? How do we make it secure? Can we make the remote machine use the internet connection as if the remote computer was in the building behind all the companies firewalls and networking security? etc., etc.
Is it secure? No.
Can we make it secure? How do we make it secure? Can we make the remote machine use the internet connection as if the remote computer was in the building behind all the companies firewalls and networking security? etc., etc.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That is a very well written description and I appreciate it very much! I am awarding you the points for having the knowledge and taking the time to write what seems to be the most accurate description in an understandable organized way.
I appreciate everyone elses time who contributed also
I appreciate everyone elses time who contributed also
ASKER
That is a very well written description and I appreciate it very much! I am awarding you the points for having the knowledge and taking the time to write what seems to be the most accurate description in an understandable organized way.
I appreciate everyone elses time who contributed also
I appreciate everyone elses time who contributed also
>That is a very well written description
Except that some of it is completely wrong.
Sigh. Sometimes I wonder why I bother. I guess such poor understandings of security pay my bills as a consultancy business owner, so I shouldn't complain, but I feel like strangling folks when 99% of people simply cannot understand technology at hand, and gladly fly in the face of logic every time. These are the same kinds of morons who ignore my security advice when configuring a network, and then want me to eat their costs when they get hacked... Pathetic.
To date, no one has answered my question: "How is enabling or disabling split tunneling effective given the numerous other ways to remotely control a computer (including trojans/zombies/etc)?", which to me indicates that 99% of the above arguments are complete BS.
Adowns - ever hear of a point split, or giving other experts time to rebut? ChrisK is definitely confused about some aspects of security, but I guess he told you what you wanted to hear... I also am confused about his "everyone doesn't do things the way he does because they don't know how" - why is someone working in network security if they don't know how to secure a network?!?!? This makes no sense. My main complaint with this situation is that ChrisK mostly replicated or expounded upon advice already given, and you [adowns] did *not*, despite my multiple requests, reply to my attempts to get you to explain exactly what kind of "answer" you were looking for. Thanks for playing, but I will have to avoid replying to your posts in the future.
VPNs do not manufacture trust - anyone who tells you that (or thinks so) is an idiot, and should be completely disregarded.
Grumble, grumble,
-Jon
P.S. Sorry for the rant, but I get rather annoyed when someone accepts an answer without obviously coming away with a greater understanding of their problem.
Except that some of it is completely wrong.
Sigh. Sometimes I wonder why I bother. I guess such poor understandings of security pay my bills as a consultancy business owner, so I shouldn't complain, but I feel like strangling folks when 99% of people simply cannot understand technology at hand, and gladly fly in the face of logic every time. These are the same kinds of morons who ignore my security advice when configuring a network, and then want me to eat their costs when they get hacked... Pathetic.
To date, no one has answered my question: "How is enabling or disabling split tunneling effective given the numerous other ways to remotely control a computer (including trojans/zombies/etc)?", which to me indicates that 99% of the above arguments are complete BS.
Adowns - ever hear of a point split, or giving other experts time to rebut? ChrisK is definitely confused about some aspects of security, but I guess he told you what you wanted to hear... I also am confused about his "everyone doesn't do things the way he does because they don't know how" - why is someone working in network security if they don't know how to secure a network?!?!? This makes no sense. My main complaint with this situation is that ChrisK mostly replicated or expounded upon advice already given, and you [adowns] did *not*, despite my multiple requests, reply to my attempts to get you to explain exactly what kind of "answer" you were looking for. Thanks for playing, but I will have to avoid replying to your posts in the future.
VPNs do not manufacture trust - anyone who tells you that (or thinks so) is an idiot, and should be completely disregarded.
Grumble, grumble,
-Jon
P.S. Sorry for the rant, but I get rather annoyed when someone accepts an answer without obviously coming away with a greater understanding of their problem.
ASKER
>P.S. Sorry for the rant, but I get rather annoyed when >someone accepts an answer without obviously coming
>away with a greater understanding of their problem.
There is no problem, from the beginning everything was speculation and questioning.
>adowns - just get a linux router, and all will be well
Why should I take comments like this seriously?
>Actually, I guess it may be relevant in the respect that >it may be what is happening to adowns, but
>it does not change the fact that
>a. it can be worked around
>b. it constitutes a misconfig, and a security hole.
>adowns should point this out and ask for a raise hehe..
How should I take comments like this seriously, I'm not even sure where this originated from. The original question was is it possibly to configure vpn and internet at the same time. This is a question I'm personally asking for no reason. So why should I be asking for a raise?
In addition, he has provided me with a satisfactory answer in my opinion. I'm sorry you are not happy with this but you kept jumping subjects and I couldn't follow a word you were saying.
>away with a greater understanding of their problem.
There is no problem, from the beginning everything was speculation and questioning.
>adowns - just get a linux router, and all will be well
Why should I take comments like this seriously?
>Actually, I guess it may be relevant in the respect that >it may be what is happening to adowns, but
>it does not change the fact that
>a. it can be worked around
>b. it constitutes a misconfig, and a security hole.
>adowns should point this out and ask for a raise hehe..
How should I take comments like this seriously, I'm not even sure where this originated from. The original question was is it possibly to configure vpn and internet at the same time. This is a question I'm personally asking for no reason. So why should I be asking for a raise?
In addition, he has provided me with a satisfactory answer in my opinion. I'm sorry you are not happy with this but you kept jumping subjects and I couldn't follow a word you were saying.
Thanks adowns glad to be of help. Chriskohn
>and I couldn't follow a word you were saying.
Is this also the case with ahoffman's comments?
https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxprog&qid=20287446
Not very nice to leave him hanging for over two months - he's a good guy.
Also, in the future you won't have to worry about understanding any words I am saying, because you will never hear them again (or if you do they will not be directed to you).
>but you kept jumping subjects and I couldn't follow a word you were saying
I think a repost of the above suffices here...
>>adowns - I am getting tired of arguing an obvious point - how do you want to proceed here?
>>I ask again - how would you like to proceed?
>>Once again - I would really like to know what you want to do
These exerpts from three seperate posts of mine (with no direct response from you) indicate how full of crap you are.
Thanks for playing,
-Jon
Is this also the case with ahoffman's comments?
https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxprog&qid=20287446
Not very nice to leave him hanging for over two months - he's a good guy.
Also, in the future you won't have to worry about understanding any words I am saying, because you will never hear them again (or if you do they will not be directed to you).
>but you kept jumping subjects and I couldn't follow a word you were saying
I think a repost of the above suffices here...
>>adowns - I am getting tired of arguing an obvious point - how do you want to proceed here?
>>I ask again - how would you like to proceed?
>>Once again - I would really like to know what you want to do
These exerpts from three seperate posts of mine (with no direct response from you) indicate how full of crap you are.
Thanks for playing,
-Jon
I told you jokers the cisco VPN client was broken - looks like it was more broken than even I guessed...
http://www.cisco.com/warp/public/707/vpnclient-multiple-vuln-pub.shtml
read em and weep
http://www.cisco.com/warp/public/707/vpnclient-multiple-vuln-pub.shtml
read em and weep
So it can be crashed. Hmm OK.
How is that "more broken than even I guessed"?
Is it a security breach? No.
Keep fishing please.
--------------------------
Impact
When the vulnerabilities are exploited they prevent the Cisco VPN Client software program from functioning correctly. The Cisco VPN Client software program's availability may be impacted. There is no impact to the confidentiality and integrity of the data.
--------------------------
How is that "more broken than even I guessed"?
Is it a security breach? No.
Keep fishing please.
--------------------------
Impact
When the vulnerabilities are exploited they prevent the Cisco VPN Client software program from functioning correctly. The Cisco VPN Client software program's availability may be impacted. There is no impact to the confidentiality and integrity of the data.
--------------------------
>Is it a security breach? No.
Do you have access to the source code that you can make such claims? Just because someone hasn't hacked it yet (or announced a hack) does not preclude the possibility (please retake logic 101).
I saw two instances of a buffer overflow in the bug report, and we all know too well where those can often lead...
In any case, it's certainly more broken that I guessed because I didn't claim it was broken in this way...
Thanks for playing,
-Jon
Do you have access to the source code that you can make such claims? Just because someone hasn't hacked it yet (or announced a hack) does not preclude the possibility (please retake logic 101).
I saw two instances of a buffer overflow in the bug report, and we all know too well where those can often lead...
In any case, it's certainly more broken that I guessed because I didn't claim it was broken in this way...
Thanks for playing,
-Jon
In any case, my post was to point out to those who would claim that cisco always does things the "right" way that this bug report clearly indicates cisco does things the "wrong" way at times, and more often than many would like to admit (and within the actual product that was being discussed).
Cheers,
-Jon
Cheers,
-Jon