B
Bill Sanderson
I'm not sure this will be of interest to many here, but you can ignore it if
you aren't interested.
Anyone working with VPN connections is probably aware that you are told that
a split-tunnel VPN connection can be evil--that is, a tunnel where you
uncheck "use default gateway on remote network" in advanced properties of
TCP/IP of the VPN connection.
You do this because leaving that checked tends to either restrict Internet
connectivity, or perhaps remove it completely, while the VPN is connected,
and many remote users, including me, find this objectionable.
So--what can go wrong? Someone could create a malicious machine named in a
way that might result in your connecting to that machine, rather than the
one you were intending to connect, and thus sending critical data over an
unencrypted connection to an unknown machine, rather than through the VPN
connection to your expected target.
I've just had an experience that illustrates this issue rather well: I've a
machine at work somewhat unimaginatedly named "webmaster-pc." I just put a
new monitor on it but didn't have time to put the monitor driver in place
befor I went home, so I fire up the VPN connection, open Remote Desktop, put
in "webmaster-pc" and get "cannot connect."
So--I connect to the server at work, do a Remote Desktop connection from
there to webmaster-pc, which works fine. Verify that remote desktop is
enabled. Check OneCare's firewall to see that connections are allowed from
both same subnet and different subnets. Scratch head.
Disconnect Remote Desktop to webmaster-pc. Disconnect remote desktop to the
server.
ping webmaster PC.
AHA: response comes from "webmaster-pc.mshome" at 8.15.7.117 !
My home desktop is in workgroup mshome, so this suffix is added by default
to dns queries--and, somebody has a machine with the above name listed in
DNS. The work lan is 10.25.25.xxx, home is 192.168.2.xxx.
Open up remote desktop, and put in webmaster-pc.domain.local and it connects
just fine as expected.
So--in this case, when I had my VPN connection up and typed in
"webmaster-pc" I expected to be connected to "webmaster-pc" a vista
workstation on my work network a few miles away. Instead, I was attempting
to connect to a machine at 8.15.7.117, which is probably somewhere in the
northwestern part of the U.S.--I'm in the mid-east coast.
Fortunately, it isn't running Vista, and or doesn't have RDP enabled, so it
didn't respond to my attempts to connect, and I didn't end up typing
credentials into some phony dialog box--but it sure could have happened....
So--will I stop running with that box unchecked? Probably not--but I'll be
more careful! I can set up dns suffixes on the VPN connection at the client
end to fix this, I believe, and that's what I'll probably do first...
--
you aren't interested.
Anyone working with VPN connections is probably aware that you are told that
a split-tunnel VPN connection can be evil--that is, a tunnel where you
uncheck "use default gateway on remote network" in advanced properties of
TCP/IP of the VPN connection.
You do this because leaving that checked tends to either restrict Internet
connectivity, or perhaps remove it completely, while the VPN is connected,
and many remote users, including me, find this objectionable.
So--what can go wrong? Someone could create a malicious machine named in a
way that might result in your connecting to that machine, rather than the
one you were intending to connect, and thus sending critical data over an
unencrypted connection to an unknown machine, rather than through the VPN
connection to your expected target.
I've just had an experience that illustrates this issue rather well: I've a
machine at work somewhat unimaginatedly named "webmaster-pc." I just put a
new monitor on it but didn't have time to put the monitor driver in place
befor I went home, so I fire up the VPN connection, open Remote Desktop, put
in "webmaster-pc" and get "cannot connect."
So--I connect to the server at work, do a Remote Desktop connection from
there to webmaster-pc, which works fine. Verify that remote desktop is
enabled. Check OneCare's firewall to see that connections are allowed from
both same subnet and different subnets. Scratch head.
Disconnect Remote Desktop to webmaster-pc. Disconnect remote desktop to the
server.
ping webmaster PC.
AHA: response comes from "webmaster-pc.mshome" at 8.15.7.117 !
My home desktop is in workgroup mshome, so this suffix is added by default
to dns queries--and, somebody has a machine with the above name listed in
DNS. The work lan is 10.25.25.xxx, home is 192.168.2.xxx.
Open up remote desktop, and put in webmaster-pc.domain.local and it connects
just fine as expected.
So--in this case, when I had my VPN connection up and typed in
"webmaster-pc" I expected to be connected to "webmaster-pc" a vista
workstation on my work network a few miles away. Instead, I was attempting
to connect to a machine at 8.15.7.117, which is probably somewhere in the
northwestern part of the U.S.--I'm in the mid-east coast.
Fortunately, it isn't running Vista, and or doesn't have RDP enabled, so it
didn't respond to my attempts to connect, and I didn't end up typing
credentials into some phony dialog box--but it sure could have happened....
So--will I stop running with that box unchecked? Probably not--but I'll be
more careful! I can set up dns suffixes on the VPN connection at the client
end to fix this, I believe, and that's what I'll probably do first...
--