Is there a path around VPN?

This wwould kinda toast hte entire point of the VPN. When VPN'ed your machine is inside the private network of your company, and is only able to see and connect to whatever your office PC can.

If you could also connect to non-office resrouces, your PC would be a bridge between the private and public internets and would be a huge security hole.

Thats its purpose.

I use a laptop for my VPN connection. When I am on my laptop, I just open a remote desktop connection to a PC on my home network. I have to use the IP address to get the remote desktop connection to work. ( command line = mstsc /v 192.168.x.x) The remote desktop PC uses my home network' s Internet connection and not the VPN for stuff like email. I can ping between the 2 machines using their 192.168.x.x addresses - I cannot ping from the home desktop to the laptop using the IP that the VPN assigns, nor can I access anything on the VPN network from the home machine. I can see shares and map drives on either computer from either computer. If I want to get something from work onto the home PC, I have to download it to a share on the laptop then copy over on the home network.

mike in montana

That's not the purpose of a VPN. The purpose of a VPN is to get that client machine connected into the remote network. Now, while it might be considered somewhat advantageous to force "all" traffic into the VPN pipe it's not necessary, nor really any more secure.

Wrong. VPN client software acts as a connection for that client machine ALONE. Not as a router between that machine and whatever other networks might be connected. If you've got compromised software on the client machine it's not going to matter what the VPN "thinks" it has control over.

You can do this by removing the default route. When the VPN software makes it's connection it tells windows about the new TCP/IP network route. Most VPNs I've seen feed it a 'default' route. That is, 0.0.0.0 routed to the remote side of the VPN. Remove that default route and your packets will revert to using whatever other local routes exist. But if you remove the default route you'd need to make sure the remote subnets that ARE needed are setup in it's place.

The hassle with doing this is you have to know the remote subnet numbers and set them up properly. If the remote network only has one then it's not that bad. But some remote networks might have a lot more than just the one remote network and then you get into some pretty complicated routing hassles. There are ways for the remote network and the VPN client to automagically negotiate routes but few are setup well enough to do this properly. Thus using the 0.0.0.0 default route is the lazy way out of it.

-Bill Kearney

So, to make it work, I need to know that I want to connect to

192.104.0.0 and 10.0.0.0 via VPN and 192.174.0.0 via my gateway. Then, I route 192.104.0.0 and 10.0.0.0 via VPN and let everything else go to the gateway (the old default route).

Now, is there (windows) software the allows one to view and edit (and better yet programatically edit) the routing tables in my pc? If so, what do I go looking for (on google or whatever)? This sounds like a fun little learning exercise.

I'd guess that this works because your company has opened the RDP ports on their firewall.

Eh? Thats what the Virtual and Private parts mean.

I beg to differ. If you could see both networks simultaneously, you would be bridging the two. For instance if /you/ can copy a file, then so can a background process.

Saying it don't make it so. Can you copy a file from one network to the other? Then you've bridged between them.

I agree, thats whats its supposed to do. This is my point, so I'm puzzled as to the relevance of this comment!

Open a command window and type "route print" or "route" by itself for help info.

Virtual and Private THROUGH whatever other networks are present. Not to the exclusion of whatever other networks might ALREADY be present. It's a virtual route being made through whatever interim networks are present without transmitting native packets on it. It's private in that the sessions are generally encrypted. It's not private in the sense that it's an 'exclusive' connection.

No, that's entirely incorrect. Unless the client PC is configured as a ROUTER then no packets would get passed between the local network and the VPN. That and the VPN software would have to be configured to allow it, and most WILL NOT.

That's not bridging. That's a client on both networks engaging in client actions. Bridging would be some OTHER computer on the local network being able to cross through the client, over the VPN and out onto the remote network.

Now, might an admin desire such a thing perhaps. But if you remove the ability for the local client to see it's own network then you'd also lose the pipe through which the VPN is tunneled. You'd also lose the ability to print to any local networked printers (and users would certainly dislike this). If you want to isolate a user so that they cannot copy anything locally then you'd be much better served using remote terminal sessions. That way everything would stay at the distant end. That and it wouldn't require a VPN, just a port mapped on the firewall. Using an encrypted RDP session over an encrypted VPN would be adding more overhead than is necessary.

Apparently because you've got a fundamentally incorrect understanding of what VPNs are designed to offer. That's fine, but if you're going to give advice you'd do well to have a better understanding of what you're commenting about.

-Bill Kearney

WTF? Again, entirely incorrect. If he's on the laptop, at home, using work's computer and the work VPN is active then the laptop may not be properly resolving the addresses for local machines. But if he uses the local machine's IP address then the TCP/IP stack can route it just fine. That is, when he's at home, let's say, the network is 192.168.10.0. The laptop gets IP address 192.168.10.4 (or whatever). And there's another PC at home, named "home pc" at IP address of 192.168.10.3. If the laptop doesn't make the VPN connection there's a good chance it'll resolve the "home pc" using netbios or wins. When he makes the VPN connection to work, however, the VPN client software changes his name resolution methods to use the machines at work. Thus a lookup of "home pc" won't work because the resolvers at work don't have a record for it. Nor can the "home pc" machine make a connection to work to register itself anyway (which is part of the original thread). But since VPN connections are NOT exclusive of local subnets then a direct IP address connection to 192.168.10.3 will work just fine.

If he wanted the work laptop to remain able to resolve the home machines via names he'd either have to rejigger the DNS and/or WINS lookup information or put static entries into the %WINDIR%\\system32\\drivers\\etc\\hosts file.

VPNs, DNS, WINS and routing are not '101 level classes' and if you're not familiar with them then don't give people bad advice.

-Bill Kearney

Excuse the top post.

The home laptop gets a 192.168.0.x IP from DHCP - when it connects to the corp VPN it gets a 172.x.x.x IP *in addition to* the 192.x.x.x. I wont even mention the wireless connection as it doesn't affect behavior whether on or off. On the corp VPN I can use remote desktop to hop over to another internal corp network or I can RDC to any machine on my home lan by IP and or by machine name, but machine name is way slower to connect and times out frequently. I suspect it is trying to resolve on the corp DNS, doesnt find it there and then goes to the local DNS to resolve.

mike in montana

And how do you think a file gets copied? Without packets being passed between the two networks that is?

*shrug*. You know as well as I do that there's no difference. If a user at a PC is able to copy data from network a to network b, then a user not at the PC can do it too.

WTF to you too, Bill. I may have misunderstood but I read the above as saying that on his laptop, when VPN'ed, he can open a remote desktop connection to a PC on his home network. In order to do that from within the VPN, he has to pass out through his company firewall.

Thanks for the advice. I'll take it in the light that its offered.

Bear in mind that I think you're mistaken, not me, and neither of us can prove our credentials. The OP should probably stop using usenet as a source of knowledge and get some reference books.

You're clueless about this thread, and I daresay about networking in general.

The original post was about the office being able to invade the home network. No, VPN clients won't do this. Nor would a VPN client allow a HOME computer to route through the connected client.

You're absolutely, positively, 100% WRONG.

(office network)--VPN---(the internet)--VPN--laptopA--(home network)---homePC

In the above scenario it's NOT POSSIBLE for homePC to access anything on the office network. Nor is possible for anything else on the office network to contact the homePC, or anything else on the home network. Not via a VPN client on laptopA, that is.

If, in the above scenario, it's certainly possible for laptopA to copy a file from the homePC to the something on the office network. That's NOT BRIDGING or even routing. That's the laptopA machine making two network connections and using itself to control the activity. Whether or not the office network adminstrators WANT this behavior is another question, and not related to this thread.

Now where things start getting more interesting is if you're using Citrix or other remote desktop clients. Then it's possible to run sessions on a server on the office network, not be able to copy files back to the home network, yet still be able to print to a network printer at home. Again, this is NOT BRIDGING or routing of packets, it's a client-side activity.

So, please, go read a couple of years worth of network administration and networking manuals and THEN offer advice. Meanwhile, save people from your newbie mistakes.

-Bill Kearney

Bzzzt, wrong. Thanks for playing, now go home.

That laptop, when at home, can't make a text named connection to the home PC. It can, as it rightly should be able, make an IP address connection. And none fo the laptop's packets would be travelling back to the company and back out the firewall. That's not how TCP/IP packet routing works, with or without a VPN.

Well, I've been doing this sort of work since 1979. I've no clue how long you've been making people suffer from bad advice, I'm hoping it's not been too long. Let it go, you're just plainly in over your depth.

Could have been an interesting thread if the 'point scoring' stopped.

I connect to a client's network using Netscreen. I setup the VPN but have no special expertise and can only comment on the way this one works.

My office network is on a 10.0.0.x network. My client is on a

192.168.1.x network.

I have specified in Netscreen client the gateway address (ie the client's external ip address) and the subnet to connect to (ie

192.188.1.0).

At no time does my machine have a 192.168.1.x address but I can browse the client network (easier if I put some host names into HOST and LMHOSTS) but similarly I continue to have normal internet access which does not pass through the client network. I'm pretty sure there is no way for anyone on the client's network to access anything on my

10.0.0.x network.

It actually doesn't matter what network I'm on (eg even dial-up)., access to the client's network remains the same.

There appear to be other VPN's where the initial login is onto the remote site. The behaviour presumably would be quite different to my experience.

Browse or actually connect to one of them? Browsing does not mean you have a link to the machines. If the client machine making the connection to your side is running a WINS browsing service then it's hosting the names of the remote machines. That'll let you see them in a Network Neighborhood list. But it wouldn't normally let you actually make connections to them, at least not with TCP/IP.

As in, 1st login screen on the desktop computer? Sure, but that's still going to be using the local TCP/IP subnet and be routed out to the remote network via VPN.

Wrong. Though its true that you're offensive, but thats the nature of usenet.

Define, please, the difference between a client acessing both networks, and a router accessing both networks. Hint: both are software running on the machine in the middle.

Which, if the client can do it, the other computer could do, by engaging a suitable piece of s/w on the intermediary.

Right. And Caesar murdered Pompey.

*shrug*. I have no further interest in this thread. I recommend anyone still bothering to tune in to buy some books and find out from an actual source of knowledge, since neither Bill nor I have any means of proving we have a clue.

Dork.

Mark McIntyre hath wroth:

Wrong. I'm the most offensive person on Usenet (without using profanity or becoming abusive) or at least in this newsgroup. I've even written and posted offensive techno poetry. Exerts of some hate mail I've received on request.

It was just getting interesting. Oh well.

This has little to do with wireless, but I just can't resist muddying the waters.

I recently had a similar (not identical) issue over a VPN setup problem. The question was whether the local router could be "seen" once one entered the VPN in order to obtain a DHCP IP renewal. (Renewals are unicast, DHCP requests are broadcasts). I tested it using two conditions: with a local default gateway and with a remote default gateway. Most of the arguments in this thread could be settled if the various proponents would try it and disclose their router tables to determine where their packets are really going. If there's no route to anything outside the VPN, then there's no way around the VPN without changing the router table. Note that once I connected to the VPN with my desktop, I lost all connectivity to local devices except the local gateway router. See: |