For example, I connect using Cisco Any Connect, and then use another VPN client (such as HotSpot Shield or proXPN) to connect through another tunnel.
I assume that you are using both clients on a single computer, so you have two parallel tunnels, not one inside the other (as you would have if you connected from your computer to Server1, and there you fired up VPN2 to connect Server1 with Server2).
In the first (parallel) scenario, each VPN client will create its own virtual interface, with its own address, netmask, remote gateway and related routing.
Any data sent through a tunnel will be encrypted by that tunnel and no other, so the question becomes: how does your computer determine what data send down which tunnel?
This is done through routing rules on the client. For example, you might receive address 192.168.42.17/24 on VPN1, and address 192.168.77.13/24 on VPN2. If you tried to link with host .42.33, you would go through VPN1, and VPN2 would know nothing of it.
Now, 192.168.42.0/24 might only be the private network used between you and the server, i.e. the one assigned by Server1 to all its VPN clients; the real network served by Server1 could be 10.20.30.0/24, and therefore Server1 would also add a routing to 10.20.30.0/24 through 192.168.42.1; then when you try to connect to 10.20.30.137, that connection would flow through VPN1, be encrypted, and again VPN2 would not even know this is taking place (why should it?).
Possible problems: what happens if both VPN1 and VPN2 broadcast a route for the same subnet, which does not correspond to the same physical hosts? E.g., you have two offices with the exact same configuration, and ServerAtOffice1 has address 10.20.30.137, while ServerAtOffice2 has address 10.20.30.195. Since those two networks never talk to each other, this ensues no conflicts at all.
Until you fire up VPN1, which tells that 10.20.30.0 goes through VPN1, and then also fire up VPN2, which tells that, no, 10.20.30.0 goes through VPN2 and no one else.
What happens in that case depends on the VPN client. A smart client would tell you "Hey, I was about to route 10.20.30.0 but, what do you know?, this route already goes somewhere else, and maybe I could notify this to my System Administrator, just in case you were up to something frisky".
Or you might have two stupid clients, and the last to overwrite the other's configuration requests stands to profit.
Or something even weirder might go on, and connections might start working and then die messily a few packets later.
A final possibility could be that both clients want to set up a default route - one for addresses you don't know about - through themselves.
Then, when connected to Server1, all your Internet navigation could be encrypted through Server1. Then you also fire up VPN2, and the "default" navigation gets routed through VPN2. Now all your Google queries about Customer #1 are routed, in clear, through Customer #2's network, firewalls, packet analyzers and so on and so forth; which could spell no end of troubles, depending on your role and the two customers' amicableness of terms.
Tweaks
How could I do other version, not the two clients in parallel? If I
have DD-WRT running on a router ALPHA which has a PPTP VPN server running,
to whom you connect from client CHARLIE,
can I make it connect to VPN server BRAVO? Is that chaining on
tunnelling? In any case, the final server would see my traffic coming
from the router in between, right? –- László
We can have two scenarios here (I have added names to your machines).
In the first scenario ALPHA is itself also client DELTA of server BRAVO. In this case the packet from CHARLIE is normally masqueraded by server ALPHA, so that any client served by BRAVO sees the packets as coming from DELTA. This can be difficult or impossible to do if BRAVO's clients have the same scheme as ALPHA's clients, for in that case you might have an ambiguity as to who has, say, address 192.168.112.17; is it the 17th client of ALPHA or is it the 17th client of BRAVO?
In the second scenario ALPHA just routes, so that BRAVO is now available to you via ALPHA's VPN. So you open a second VPN tunnel inside the first one, and get assigned a second IP address by BRAVO. You are now at the same time both client CHARLIE of server ALPHA and (unbeknownst to ALPHA) client DELTA of server BRAVO.
BRAVO's clients will see you as DELTA, while BRAVO will of course be aware that you are ALPHA's client CHARLIE.
Again you can have trouble here if the addresses and their routing conflict (e.g. the connection to BRAVO relies on a default route, but BRAVO itself installs its own default route upon connect, replacing the one by ALPHA).
Also (even if nowadays this is becoming irrelevant), the load on ALPHA is lower in this second scenario, and the load on your CPU is proportionally higher (all packets to BRAVO's network are encrypted by BRAVO-Driver, then passed to ALPHA-Driver and reencrypted, before finally being passed to ADSL-Driver and sent on their way).
