Split Tunneling in the Windows VPN Client???

Is there any way to tunnel ALL network packets through an established VPN
connection??? Checking the "Use default gateway on the remote network"
option tunnels all remote traffic through the tunnel but as stated in the
description of this check box, it states "data that cannot be sent on the
local network is forwarded to the dial-up network". This implies that "local
network" traffic does not get pushed through the tunnel (causing a DNS
resolution issue in my case but irrelevant to this question!)

I think this is a security flaw that should be addressed by Microsoft as it
is still a form of split tunneling. This setting implies that I can still
communicate with devices on my home network (local) while having a VPN
connection established. This potentially allows someone on the internal
network hijack my workstation while I am connected to the VPN. This is in my
mind NOT disabling split tunneling.

Cisco's VPN client implementation does enforce no split tunneling by
forwarding ALL packets through the tunnel including any packet that would
normally be destined for a local network. This can confuse end users because
when connected to the VPN, they cannot even see anything on their home
network. However, this is truely disabling split tunneling and should be the
way it works.

I am supprised the Microsoft client would allow this and I suspect that
there may be a registry setting to forward ALL packets through an established
tunnel and truely disable split tunneling but I have been unsuccessful at
finding it. Any help or valid workaround would be greatly appreciated.

Why (and how) would you send local traffic through the tunnel? Local
traffic is sent "on the wire" using hardware addressing.

Whether local traffic should be blocked when the VPN is up is another
question altogether. I can't see any point in doing so myself.

Daniel Bartlett wrote:
> Is there any way to tunnel ALL network packets through an established
> VPN connection??? Checking the "Use default gateway on the remote
> network" option tunnels all remote traffic through the tunnel but as
> stated in the description of this check box, it states "data that
> cannot be sent on the local network is forwarded to the dial-up
> network". This implies that "local network" traffic does not get
> pushed through the tunnel (causing a DNS resolution issue in my case
> but irrelevant to this question!)
>
> I think this is a security flaw that should be addressed by Microsoft
> as it is still a form of split tunneling. This setting implies that
> I can still communicate with devices on my home network (local) while
> having a VPN connection established. This potentially allows someone
> on the internal network hijack my workstation while I am connected to
> the VPN. This is in my mind NOT disabling split tunneling.
>
> Cisco's VPN client implementation does enforce no split tunneling by
> forwarding ALL packets through the tunnel including any packet that
> would normally be destined for a local network. This can confuse end
> users because when connected to the VPN, they cannot even see
> anything on their home network. However, this is truely disabling
> split tunneling and should be the way it works.
>
> I am supprised the Microsoft client would allow this and I suspect
> that there may be a registry setting to forward ALL packets through
> an established tunnel and truely disable split tunneling but I have
> been unsuccessful at finding it. Any help or valid workaround would
> be greatly appreciated.

There is not necessarily a "reason" for tunneling all packets including local
but this is how Cisco's implements their VPN client as I understand it.

Let me give you a very specific reason why you would disable this capability:
a. Home user with home network with multiple computers (not uncommon nowdays
with a lot of teenagers having their own systems)
b. Teen computer is compromise (too much IM and other related activities)
c. Dad connects to office through Microsoft L2TP or PPTP client. He is
unable to communicate to the Internet because "split tunneling" has been
"disabled" but still is able to print to his home network base printer.
d. Dad leaves for a couple hours but forgets to disconnect his VPN connection
e. Teens laptop is hijacked and hacker finds dads laptop
f. Hacker compromises dads laptop and finds he has complete access to
business network

Yes, I completely understand there are SEVERAL security issues with this
scenario but this is why you do not implement Split Tunneling EVER! No
matter how much your user base screams. Unfortunately, we live in an age
where I see the above scenario playing out very easily regardless how hard IT
engineers work.

When a user is connected to the corporate network, that is ALL they should
be connected to. Microsoft has NOT disabled Split Tunneling...they still
allow split tunneling to the local network. Although you would not
necessarily want to send the packets through the tunnel (waste of bandwidth),
by doing this, Cisco has effectively eliminated split tunneling to the local
network. I dont know how this could be implemented without sending all
packets through the tunnel (we still have to get the packets to the local
router and eventually to the VPN endpoint)

I absolutely LOVE Microsoft products, but they are wrong here. This is a
security issue. It is just a matter of time before this type of exploit
would be "used" and some hotfix developed. I was just hoping there might be
a registry fix of some sort right now as this behavior causes me other issues
(DNS specific issues where I am getting External DNS resolution when I am
connected to the VPN because my home router is considered my External DNS
server and unfortunately this is a "local" address)



"Bill Grant" wrote:

> Why (and how) would you send local traffic through the tunnel? Local
> traffic is sent "on the wire" using hardware addressing.
>
> Whether local traffic should be blocked when the VPN is up is another
> question altogether. I can't see any point in doing so myself.
>
> Daniel Bartlett wrote:
> > Is there any way to tunnel ALL network packets through an established
> > VPN connection??? Checking the "Use default gateway on the remote
> > network" option tunnels all remote traffic through the tunnel but as
> > stated in the description of this check box, it states "data that
> > cannot be sent on the local network is forwarded to the dial-up
> > network". This implies that "local network" traffic does not get
> > pushed through the tunnel (causing a DNS resolution issue in my case
> > but irrelevant to this question!)
> >
> > I think this is a security flaw that should be addressed by Microsoft
> > as it is still a form of split tunneling. This setting implies that
> > I can still communicate with devices on my home network (local) while
> > having a VPN connection established. This potentially allows someone
> > on the internal network hijack my workstation while I am connected to
> > the VPN. This is in my mind NOT disabling split tunneling.
> >
> > Cisco's VPN client implementation does enforce no split tunneling by
> > forwarding ALL packets through the tunnel including any packet that
> > would normally be destined for a local network. This can confuse end
> > users because when connected to the VPN, they cannot even see
> > anything on their home network. However, this is truely disabling
> > split tunneling and should be the way it works.
> >
> > I am supprised the Microsoft client would allow this and I suspect
> > that there may be a registry setting to forward ALL packets through
> > an established tunnel and truely disable split tunneling but I have
> > been unsuccessful at finding it. Any help or valid workaround would
> > be greatly appreciated.
>
>
>

Are you sure that this is what is causing your DNS problems? It seems
pretty unlikely to me. Does your VPN client have the internal IP address of
your corporate DNS server and the correct domain suffix for the internal
corporate DNS name space?

Daniel Bartlett wrote:
> There is not necessarily a "reason" for tunneling all packets
> including local but this is how Cisco's implements their VPN client
> as I understand it.
>
> Let me give you a very specific reason why you would disable this
> capability: a. Home user with home network with multiple computers
> (not uncommon nowdays with a lot of teenagers having their own
> systems)
> b. Teen computer is compromise (too much IM and other related
> activities)
> c. Dad connects to office through Microsoft L2TP or PPTP client. He
> is unable to communicate to the Internet because "split tunneling"
> has been "disabled" but still is able to print to his home network
> base printer.
> d. Dad leaves for a couple hours but forgets to disconnect his VPN
> connection e. Teens laptop is hijacked and hacker finds dads laptop
> f. Hacker compromises dads laptop and finds he has complete access to
> business network
>
> Yes, I completely understand there are SEVERAL security issues with
> this scenario but this is why you do not implement Split Tunneling
> EVER! No matter how much your user base screams. Unfortunately, we
> live in an age where I see the above scenario playing out very easily
> regardless how hard IT engineers work.
>
> When a user is connected to the corporate network, that is ALL they
> should be connected to. Microsoft has NOT disabled Split
> Tunneling...they still allow split tunneling to the local network.
> Although you would not necessarily want to send the packets through
> the tunnel (waste of bandwidth), by doing this, Cisco has effectively
> eliminated split tunneling to the local network. I dont know how
> this could be implemented without sending all packets through the
> tunnel (we still have to get the packets to the local router and
> eventually to the VPN endpoint)
>
> I absolutely LOVE Microsoft products, but they are wrong here. This
> is a security issue. It is just a matter of time before this type of
> exploit would be "used" and some hotfix developed. I was just hoping
> there might be a registry fix of some sort right now as this behavior
> causes me other issues (DNS specific issues where I am getting
> External DNS resolution when I am connected to the VPN because my
> home router is considered my External DNS server and unfortunately
> this is a "local" address)
>
>
>
> "Bill Grant" wrote:
>
>> Why (and how) would you send local traffic through the tunnel?
>> Local traffic is sent "on the wire" using hardware addressing.
>>
>> Whether local traffic should be blocked when the VPN is up is
>> another question altogether. I can't see any point in doing so
>> myself.
>>
>> Daniel Bartlett wrote:
>>> Is there any way to tunnel ALL network packets through an
>>> established VPN connection??? Checking the "Use default gateway on
>>> the remote network" option tunnels all remote traffic through the
>>> tunnel but as stated in the description of this check box, it
>>> states "data that cannot be sent on the local network is forwarded
>>> to the dial-up network". This implies that "local network" traffic
>>> does not get pushed through the tunnel (causing a DNS resolution
>>> issue in my case but irrelevant to this question!)
>>>
>>> I think this is a security flaw that should be addressed by
>>> Microsoft as it is still a form of split tunneling. This setting
>>> implies that I can still communicate with devices on my home
>>> network (local) while having a VPN connection established. This
>>> potentially allows someone on the internal network hijack my
>>> workstation while I am connected to the VPN. This is in my mind
>>> NOT disabling split tunneling.
>>>
>>> Cisco's VPN client implementation does enforce no split tunneling by
>>> forwarding ALL packets through the tunnel including any packet that
>>> would normally be destined for a local network. This can confuse
>>> end users because when connected to the VPN, they cannot even see
>>> anything on their home network. However, this is truely disabling
>>> split tunneling and should be the way it works.
>>>
>>> I am supprised the Microsoft client would allow this and I suspect
>>> that there may be a registry setting to forward ALL packets through
>>> an established tunnel and truely disable split tunneling but I have
>>> been unsuccessful at finding it. Any help or valid workaround would
>>> be greatly appreciated.

In short (which I have difficulty doing), yes. This is causing my issue.

I am in a unique situation in which the client has an internal DNS name for
which they do not own. External DNS resolution of we will say host
server.xyz.com results in say 1.1.1.1 (not the clients IP). Internal DNS
resolution of host server.xyz.com is 2.2.2.2 (the IP address I want). My
home network (as with 99% of all home networks "protected" with a dlink or
linksys router) has a local DNS server which is the router itself and its IP
address is provided to my home computers via DHCP.

After connecting to the VPN, attempting to resolve host server.xyz.com
returns an IP address of 1.1.1.1 when I really am expecting 2.2.2.2. My VPN
connected machine is sending its DNS query to my "local" DNS server rather
than the corporate DNS server at the other end of the tunnel. (The corporate
DNS server does resolve queries which are not valid on the Internet so I know
it will work if it is queried)

And yes, I have done most of the obvious:
a. Performed an ipconfig /flushdns
b. Performed an ipconfig /displaydns to confirm no cashed records
c. Confirmed the VPN PPP adapter does have the corporate DNS server after
connection.

My problem is really irrelevant. If I was not split tunneling to the local
network the only way DNS would resolve is through the corporate server and
may problem would go away. This issue I see here is that Microsoft has not
"disabled" split tunneling. I believe this to be a security flaw for which I
can find no fix. I happened upon this issue not even knowing Microsofts
implementation did this. I unfortunately just assumed disabling split
tunneling meant disabling it, not just most of it.

"Bill Grant" wrote:

> Are you sure that this is what is causing your DNS problems? It seems
> pretty unlikely to me. Does your VPN client have the internal IP address of
> your corporate DNS server and the correct domain suffix for the internal
> corporate DNS name space?
>
> Daniel Bartlett wrote:
> > There is not necessarily a "reason" for tunneling all packets
> > including local but this is how Cisco's implements their VPN client
> > as I understand it.
> >
> > Let me give you a very specific reason why you would disable this
> > capability: a. Home user with home network with multiple computers
> > (not uncommon nowdays with a lot of teenagers having their own
> > systems)
> > b. Teen computer is compromise (too much IM and other related
> > activities)
> > c. Dad connects to office through Microsoft L2TP or PPTP client. He
> > is unable to communicate to the Internet because "split tunneling"
> > has been "disabled" but still is able to print to his home network
> > base printer.
> > d. Dad leaves for a couple hours but forgets to disconnect his VPN
> > connection e. Teens laptop is hijacked and hacker finds dads laptop
> > f. Hacker compromises dads laptop and finds he has complete access to
> > business network
> >
> > Yes, I completely understand there are SEVERAL security issues with
> > this scenario but this is why you do not implement Split Tunneling
> > EVER! No matter how much your user base screams. Unfortunately, we
> > live in an age where I see the above scenario playing out very easily
> > regardless how hard IT engineers work.
> >
> > When a user is connected to the corporate network, that is ALL they
> > should be connected to. Microsoft has NOT disabled Split
> > Tunneling...they still allow split tunneling to the local network.
> > Although you would not necessarily want to send the packets through
> > the tunnel (waste of bandwidth), by doing this, Cisco has effectively
> > eliminated split tunneling to the local network. I dont know how
> > this could be implemented without sending all packets through the
> > tunnel (we still have to get the packets to the local router and
> > eventually to the VPN endpoint)
> >
> > I absolutely LOVE Microsoft products, but they are wrong here. This
> > is a security issue. It is just a matter of time before this type of
> > exploit would be "used" and some hotfix developed. I was just hoping
> > there might be a registry fix of some sort right now as this behavior
> > causes me other issues (DNS specific issues where I am getting
> > External DNS resolution when I am connected to the VPN because my
> > home router is considered my External DNS server and unfortunately
> > this is a "local" address)
> >
> >
> >
> > "Bill Grant" wrote:
> >
> >> Why (and how) would you send local traffic through the tunnel?
> >> Local traffic is sent "on the wire" using hardware addressing.
> >>
> >> Whether local traffic should be blocked when the VPN is up is
> >> another question altogether. I can't see any point in doing so
> >> myself.
> >>
> >> Daniel Bartlett wrote:
> >>> Is there any way to tunnel ALL network packets through an
> >>> established VPN connection??? Checking the "Use default gateway on
> >>> the remote network" option tunnels all remote traffic through the
> >>> tunnel but as stated in the description of this check box, it
> >>> states "data that cannot be sent on the local network is forwarded
> >>> to the dial-up network". This implies that "local network" traffic
> >>> does not get pushed through the tunnel (causing a DNS resolution
> >>> issue in my case but irrelevant to this question!)
> >>>
> >>> I think this is a security flaw that should be addressed by
> >>> Microsoft as it is still a form of split tunneling. This setting
> >>> implies that I can still communicate with devices on my home
> >>> network (local) while having a VPN connection established. This
> >>> potentially allows someone on the internal network hijack my
> >>> workstation while I am connected to the VPN. This is in my mind
> >>> NOT disabling split tunneling.
> >>>
> >>> Cisco's VPN client implementation does enforce no split tunneling by
> >>> forwarding ALL packets through the tunnel including any packet that
> >>> would normally be destined for a local network. This can confuse
> >>> end users because when connected to the VPN, they cannot even see
> >>> anything on their home network. However, this is truely disabling
> >>> split tunneling and should be the way it works.
> >>>
> >>> I am supprised the Microsoft client would allow this and I suspect
> >>> that there may be a registry setting to forward ALL packets through
> >>> an established tunnel and truely disable split tunneling but I have
> >>> been unsuccessful at finding it. Any help or valid workaround would
> >>> be greatly appreciated.
>
>
>

If it really worries you, disable your LAN NIC while connectsd.

I believe most users would be very upset if making a VPN connection
disabled their LAN access. In the past there have been postings in this ng
and the ras_routing ng complaining when making a RAS/VPN connection disabled
local networking (as it can if the local network is segmented).

Daniel Bartlett wrote:
> In short (which I have difficulty doing), yes. This is causing my
> issue.
>
> I am in a unique situation in which the client has an internal DNS
> name for which they do not own. External DNS resolution of we will
> say host server.xyz.com results in say 1.1.1.1 (not the clients IP).
> Internal DNS resolution of host server.xyz.com is 2.2.2.2 (the IP
> address I want). My home network (as with 99% of all home networks
> "protected" with a dlink or linksys router) has a local DNS server
> which is the router itself and its IP address is provided to my home
> computers via DHCP.
>
> After connecting to the VPN, attempting to resolve host server.xyz.com
> returns an IP address of 1.1.1.1 when I really am expecting 2.2.2.2.
> My VPN connected machine is sending its DNS query to my "local" DNS
> server rather than the corporate DNS server at the other end of the
> tunnel. (The corporate DNS server does resolve queries which are not
> valid on the Internet so I know it will work if it is queried)
>
> And yes, I have done most of the obvious:
> a. Performed an ipconfig /flushdns
> b. Performed an ipconfig /displaydns to confirm no cashed records
> c. Confirmed the VPN PPP adapter does have the corporate DNS server
> after connection.
>
> My problem is really irrelevant. If I was not split tunneling to the
> local network the only way DNS would resolve is through the corporate
> server and may problem would go away. This issue I see here is that
> Microsoft has not "disabled" split tunneling. I believe this to be a
> security flaw for which I can find no fix. I happened upon this
> issue not even knowing Microsofts implementation did this. I
> unfortunately just assumed disabling split tunneling meant disabling
> it, not just most of it.
>
> "Bill Grant" wrote:
>
>> Are you sure that this is what is causing your DNS problems? It
>> seems pretty unlikely to me. Does your VPN client have the internal
>> IP address of your corporate DNS server and the correct domain
>> suffix for the internal corporate DNS name space?
>>
>> Daniel Bartlett wrote:
>>> There is not necessarily a "reason" for tunneling all packets
>>> including local but this is how Cisco's implements their VPN client
>>> as I understand it.
>>>
>>> Let me give you a very specific reason why you would disable this
>>> capability: a. Home user with home network with multiple computers
>>> (not uncommon nowdays with a lot of teenagers having their own
>>> systems)
>>> b. Teen computer is compromise (too much IM and other related
>>> activities)
>>> c. Dad connects to office through Microsoft L2TP or PPTP client. He
>>> is unable to communicate to the Internet because "split tunneling"
>>> has been "disabled" but still is able to print to his home network
>>> base printer.
>>> d. Dad leaves for a couple hours but forgets to disconnect his VPN
>>> connection e. Teens laptop is hijacked and hacker finds dads laptop
>>> f. Hacker compromises dads laptop and finds he has complete access
>>> to business network
>>>
>>> Yes, I completely understand there are SEVERAL security issues with
>>> this scenario but this is why you do not implement Split Tunneling
>>> EVER! No matter how much your user base screams. Unfortunately, we
>>> live in an age where I see the above scenario playing out very
>>> easily regardless how hard IT engineers work.
>>>
>>> When a user is connected to the corporate network, that is ALL they
>>> should be connected to. Microsoft has NOT disabled Split
>>> Tunneling...they still allow split tunneling to the local network.
>>> Although you would not necessarily want to send the packets through
>>> the tunnel (waste of bandwidth), by doing this, Cisco has
>>> effectively eliminated split tunneling to the local network. I
>>> dont know how this could be implemented without sending all packets
>>> through the tunnel (we still have to get the packets to the local
>>> router and eventually to the VPN endpoint)
>>>
>>> I absolutely LOVE Microsoft products, but they are wrong here. This
>>> is a security issue. It is just a matter of time before this type
>>> of exploit would be "used" and some hotfix developed. I was just
>>> hoping there might be a registry fix of some sort right now as this
>>> behavior causes me other issues (DNS specific issues where I am
>>> getting External DNS resolution when I am connected to the VPN
>>> because my home router is considered my External DNS server and
>>> unfortunately this is a "local" address)
>>>
>>>
>>>
>>> "Bill Grant" wrote:
>>>
>>>> Why (and how) would you send local traffic through the tunnel?
>>>> Local traffic is sent "on the wire" using hardware addressing.
>>>>
>>>> Whether local traffic should be blocked when the VPN is up is
>>>> another question altogether. I can't see any point in doing so
>>>> myself.
>>>>
>>>> Daniel Bartlett wrote:
>>>>> Is there any way to tunnel ALL network packets through an
>>>>> established VPN connection??? Checking the "Use default gateway
>>>>> on the remote network" option tunnels all remote traffic through
>>>>> the tunnel but as stated in the description of this check box, it
>>>>> states "data that cannot be sent on the local network is forwarded
>>>>> to the dial-up network". This implies that "local network"
>>>>> traffic does not get pushed through the tunnel (causing a DNS
>>>>> resolution issue in my case but irrelevant to this question!)
>>>>>
>>>>> I think this is a security flaw that should be addressed by
>>>>> Microsoft as it is still a form of split tunneling. This setting
>>>>> implies that I can still communicate with devices on my home
>>>>> network (local) while having a VPN connection established. This
>>>>> potentially allows someone on the internal network hijack my
>>>>> workstation while I am connected to the VPN. This is in my mind
>>>>> NOT disabling split tunneling.
>>>>>
>>>>> Cisco's VPN client implementation does enforce no split tunneling
>>>>> by forwarding ALL packets through the tunnel including any packet
>>>>> that would normally be destined for a local network. This can
>>>>> confuse end users because when connected to the VPN, they cannot
>>>>> even see anything on their home network. However, this is truely
>>>>> disabling split tunneling and should be the way it works.
>>>>>
>>>>> I am supprised the Microsoft client would allow this and I suspect
>>>>> that there may be a registry setting to forward ALL packets
>>>>> through an established tunnel and truely disable split tunneling
>>>>> but I have been unsuccessful at finding it. Any help or valid
>>>>> workaround would be greatly appreciated.