VPN + US based MS Exchange server
Discussion
BT just upgraded my line to 8Mbps and I'm using a VPN to enable access to a remote MS Exchange Server in US using a NetGear DG834G router. Works fine but if I open a browser it dives through the VPN and surfaces in US so my IP address looks like I'm in US! Can't view e.g. BBC streaming video and if I try I get a message that the content is not available outside of UK, even though I'm sitting in bl**dy Surrey. Also my browser speed when the VPN is open is lousy. I can of course get these streams and a proper stellar speed browsing by disconnecting the VPN but that's very inconvenient since I'm using MS Outlook real time connected to the remote server.
I've taken a search through past posts on the VPN topic and tried the fix of changing the VPN properties for TCP/IP by unchecking the Default Gateway option in Advanced settings. This enables me to browse nicely alongside the VPN but unchecking this box screws the communication with the Exchange Server so my Outlook locks up.
Anyone got any creative ideas?
I've taken a search through past posts on the VPN topic and tried the fix of changing the VPN properties for TCP/IP by unchecking the Default Gateway option in Advanced settings. This enables me to browse nicely alongside the VPN but unchecking this box screws the communication with the Exchange Server so my Outlook locks up.
Anyone got any creative ideas?
Sounds like you may have your routing set up to show the default gateway as the one through the VPN tunnel. Try setting up your routing so that it only routes requests to the protected network (the Exchnage Server) through the VPN and runs all other IP requests through the local gateway...
ErnestM
ErnestM
If I were to guess, you're using a later version of Outlook, and it's communicating with a GC itself. The GC which the client chooses is based on the site to which your machine belongs (which is established by your IP). If the VPN addresses aren't in the correct pool, you'll get a remote GC, so Outlook will freeze when it can't get further than 1 subnet (i.e. when you check that box).
To test this theory, hold down control and right click the outlook item in the system tray, then select 'connection status'. It'll tell you which servers you're using for directory access (and the connection status to those servers).
Me, I just use RPC/TCP and nolonger worry about VPN for mail access.
Darren.
edited to add: the other way of doing this is to enable split tunneling, and tell it which subnets it should consider internal to your LAN (as your current setup just assumes it's everything, or just on the single subnet).
D
To test this theory, hold down control and right click the outlook item in the system tray, then select 'connection status'. It'll tell you which servers you're using for directory access (and the connection status to those servers).
Me, I just use RPC/TCP and nolonger worry about VPN for mail access.
Darren.
edited to add: the other way of doing this is to enable split tunneling, and tell it which subnets it should consider internal to your LAN (as your current setup just assumes it's everything, or just on the single subnet).
D
Edited by _deejay_ on Saturday 1st July 07:49
Thanks for your comments - as the only 'remote' worker for this US company I sure wish I had the knowledge you guys have. I'm not an IT specialist but from time to time I've had to learn enough to understand and resolve issues that enable me to be fully integrated with mothership communications.
I'm using a VPN set up using the XP facility, not the router; and I'm using Outlook 2003.
If I continue to use this VPN set up how do I define the default gateway for the protected network is through the VPN, so other requests go through a local gateway? I presume that's 'split-tunneling'? Is the definition of local subnets that are internal to the LAN a simple process? Is there a webpage that explains how to do this?
I'm using a VPN set up using the XP facility, not the router; and I'm using Outlook 2003.
If I continue to use this VPN set up how do I define the default gateway for the protected network is through the VPN, so other requests go through a local gateway? I presume that's 'split-tunneling'? Is the definition of local subnets that are internal to the LAN a simple process? Is there a webpage that explains how to do this?
It's cunning, but it should work....
Find out the IP address or subnet of your exchange server and the VPN endpoint. Then at a command prompt type
route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 substituting your own numbers. If you are unsure of the correcf GW to use bring up the VPN and type route print. That will show you what the GW IP address should be. You'll see how it alters when you drop the VPN and repeat it.
That will add a static route to the destination network from your PC as the US network is obviously routed. Then uncheck the "use default gateway" option on the VPN connector. If it all works as expected you can make the route permanent by typing route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 -p . The -p adds a permanent route to the registry. It can be deleted at a later time if you no longer need it.
Apologies for any minor technical errors, I'm still a bit tipsy. The theory is good though.
Find out the IP address or subnet of your exchange server and the VPN endpoint. Then at a command prompt type
route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 substituting your own numbers. If you are unsure of the correcf GW to use bring up the VPN and type route print. That will show you what the GW IP address should be. You'll see how it alters when you drop the VPN and repeat it.
That will add a static route to the destination network from your PC as the US network is obviously routed. Then uncheck the "use default gateway" option on the VPN connector. If it all works as expected you can make the route permanent by typing route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 -p . The -p adds a permanent route to the registry. It can be deleted at a later time if you no longer need it.
Apologies for any minor technical errors, I'm still a bit tipsy. The theory is good though.
BliarOut said:
It's cunning, but it should work....
Find out the IP address or subnet of your exchange server and the VPN endpoint. Then at a command prompt type
route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 substituting your own numbers. If you are unsure of the correcf GW to use bring up the VPN and type route print. That will show you what the GW IP address should be. You'll see how it alters when you drop the VPN and repeat it.
That will add a static route to the destination network from your PC as the US network is obviously routed. Then uncheck the "use default gateway" option on the VPN connector. If it all works as expected you can make the route permanent by typing route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 -p . The -p adds a permanent route to the registry. It can be deleted at a later time if you no longer need it.
Apologies for any minor technical errors, I'm still a bit tipsy. The theory is good though.
Find out the IP address or subnet of your exchange server and the VPN endpoint. Then at a command prompt type
route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 substituting your own numbers. If you are unsure of the correcf GW to use bring up the VPN and type route print. That will show you what the GW IP address should be. You'll see how it alters when you drop the VPN and repeat it.
That will add a static route to the destination network from your PC as the US network is obviously routed. Then uncheck the "use default gateway" option on the VPN connector. If it all works as expected you can make the route permanent by typing route ADD 192.168.10.0 MASK 255.255.255.0 157.55.80.1 -p . The -p adds a permanent route to the registry. It can be deleted at a later time if you no longer need it.
Apologies for any minor technical errors, I'm still a bit tipsy. The theory is good though.
It's good.... but it's not right.
Well, not entirely.
As BlairOut says, it's all to do with the machine's routing table.
The routing table tells the machine where to send packets. In your case, either down the VPN or directly to the Internet.
However, simply telling it where your Exchange server is probably won't be enough.
This article: www.microsoft.com/technet/community/columns/cableguy/cg1003.mspx explains your options. Most are server side options, BlairOuts suggestion is the only client side one - the 'cmd file'.
What it suggests is rather than creating a single route to the exchange server, you need to create a route which tells it where to find you company's networks.
This is important because in addition to accessing the services on the exchange server, you also need to:
1) Lookup addresses in the GAL (this is done using an AD Domain Controller running the Global Catalog role)
2) Resolve the name of your exchange server (using DNS).
So, what I'd do is:
1) Ask your admins to set it up correctly by entering the details of the internal networks into DHCP (as the article suggests)
2) If that fails, shout at them a bit, then ask them for your internal network subnets, then create the cmd file as suggested in the article.
Darren.
Edited by _deejay_ on Saturday 1st July 12:19
I'm sober now 
Chances are the exchange servers are on the same subnet.
If they're using split unassigned class B addresses on the internal network it's a doddle. route ADD 172.16.0.0 MASK 255.255.0.0 157.55.80.1 will do. You can do the same for class C but your local LAN is often 192.168.1.0
As a network admin type I'm working on the principle that the network admins won't want to reconfigure server options for a single user
Chances are the exchange servers are on the same subnet.
If they're using split unassigned class B addresses on the internal network it's a doddle. route ADD 172.16.0.0 MASK 255.255.0.0 157.55.80.1 will do. You can do the same for class C but your local LAN is often 192.168.1.0
As a network admin type I'm working on the principle that the network admins won't want to reconfigure server options for a single user
BliarOut said:
I'm sober now
Chances are the exchange servers are on the same subnet.
If they're using split unassigned class B addresses on the internal network it's a doddle. route ADD 172.16.0.0 MASK 255.255.0.0 157.55.80.1 will do. You can do the same for class C but your local LAN is often 192.168.1.0
As a network admin type I'm working on the principle that the network admins won't want to reconfigure server options for a single user
Chances are the exchange servers are on the same subnet.
If they're using split unassigned class B addresses on the internal network it's a doddle. route ADD 172.16.0.0 MASK 255.255.0.0 157.55.80.1 will do. You can do the same for class C but your local LAN is often 192.168.1.0
As a network admin type I'm working on the principle that the network admins won't want to reconfigure server options for a single user
Bad, bad network admin
. If they're providing a remote access service then they should configure it properly, regardless of the number of users. It's only a DHCP scope option after all.... I find that remote access seems to get used by sales people or senior management. The former complain at every opportunity and it's best avoiding upsetting the latter.
Surely they actually provide remote access to others, even if he is the only remote worker.
D
To save getting involved in an internet pissing contest on a beautiful day we're both right
Theoretically they *should* be setting it up, but they haven't.... And I can just see a world of pain and change control forms etc dealing with US corporate IT people
They'll only forget about it if they ever reconfigure the network anyway. A cheap and dirty locally administered static route does the job with or without their help.
Theoretically they *should* be setting it up, but they haven't.... And I can just see a world of pain and change control forms etc dealing with US corporate IT people
They'll only forget about it if they ever reconfigure the network anyway. A cheap and dirty locally administered static route does the job with or without their help.
Is it a routing problem, or just a DNS issue? You may be able to sort it by adding your corporate DNS server to your local TCP/IP configuration. This means that any hostnames that your ISP's DNS server can't resolve, will be handled by asking the corporate server to look them up. If the server address is outside your VPN subnet then you might end up having to set up an explicit route to it, but I'd try without first.
BliarOut said:
It's not DNS as his packets are hitting the BBC site from a US subnet. It's a routing issue.
Anyway, the world cup is over soon and then streaming media won't matter
Anyway, the world cup is over soon and then streaming media won't matter
Yes, but I thought he fixed *that* issue by turning off the default gateway option on the VPN, what's left is unable to reach the exchange server. Which requires DNS and routing - and I'm not sure which is failing.
GreenV8S said:
BliarOut said:
It's not DNS as his packets are hitting the BBC site from a US subnet. It's a routing issue.
Anyway, the world cup is over soon and then streaming media won't matter
Anyway, the world cup is over soon and then streaming media won't matter
Yes, but I thought he fixed *that* issue by turning off the default gateway option on the VPN, what's left is unable to reach the exchange server. Which requires DNS and routing - and I'm not sure which is failing.
It needs more than that, it needs DNS, Exchange and access to a local GC.
That's why I suggested looking at the Outlook connection status....
hut49 said:
Guess I opened a can of worms - shame none of them speak my language!!
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
OK. What we therefore need to know is the IP address of your exchange server.
From that we should be able to make an educated guess at how to fix it.
If you know what the server is called then you can 'ping' it from your machine once VPN'd in, and it'll tell you.
Darren.
_deejay_ said:
hut49 said:
Guess I opened a can of worms - shame none of them speak my language!!
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
OK. What we therefore need to know is the IP address of your exchange server.
From that we should be able to make an educated guess at how to fix it.
If you know what the server is called then you can 'ping' it from your machine once VPN'd in, and it'll tell you.
Darren.
BliarOut said:
_deejay_ said:
hut49 said:
Guess I opened a can of worms - shame none of them speak my language!!
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
OK. What we therefore need to know is the IP address of your exchange server.
From that we should be able to make an educated guess at how to fix it.
If you know what the server is called then you can 'ping' it from your machine once VPN'd in, and it'll tell you.
Darren.
IT Consultant huh? In which case we'll do the usual routine. I'll give the answer and you can agree, then bill him for it
_deejay_ said:
hut49 said:
Guess I opened a can of worms - shame none of them speak my language!!
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
OK. What we therefore need to know is the IP address of your exchange server.
From that we should be able to make an educated guess at how to fix it.
If you know what the server is called then you can 'ping' it from your machine once VPN'd in, and it'll tell you.
Darren.
OK, so I pinged the server and now I know the IP address. What's next?
hut49 said:
_deejay_ said:
hut49 said:
Guess I opened a can of worms - shame none of them speak my language!!
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
So if I look at Outlook connection status I see the it's connecting to the correct Server at HQ; Type = directory; interface = WAN (PPP/SLIP); connection = TCP/IP
OK. What we therefore need to know is the IP address of your exchange server.
From that we should be able to make an educated guess at how to fix it.
If you know what the server is called then you can 'ping' it from your machine once VPN'd in, and it'll tell you.
Darren.
OK, so I pinged the server and now I know the IP address. What's next?
OK, so we need to work out what network that machine is on. If you could post or mail me the first two octet's (i.e. the numbers before the first dot and the second dot) of that IP address, and also do the same for your IP address when you're at home then we should be able to work out some routes.
oh, and to get your own IP address, run ipconfig /all from a command line.
Darren.
Edited by _deejay_ on Sunday 2nd July 10:51
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff