VPN + US based MS Exchange server
Discussion
No, and here's the logic.
When connected to the VPN with no split-tunnelling, he can access the server (and therefore the DNS server which knows about the exchange servers name is accessible, and defined on the connection, probably through DHCP)
However, when he disables the 'use gateway on remote network setting' he cannot access Exchange. That's either because he can nolonger access DNS (and thus resolve the name), cannot access the Exchange server or cannot access a directory server.
So, whether it's DNS, Exchange or a GC he cannot see, adding a route to his client will allow him to see all of the servers (if we get the route right) whilst maintaining local Internet access.
In a nut shell - when he sends everything down the VPN it's OK, when he sends traffic just to the local VPN subnet, it's not OK. Therefore we need something in the middle - adding the static routes will give us that.
D
When connected to the VPN with no split-tunnelling, he can access the server (and therefore the DNS server which knows about the exchange servers name is accessible, and defined on the connection, probably through DHCP)
However, when he disables the 'use gateway on remote network setting' he cannot access Exchange. That's either because he can nolonger access DNS (and thus resolve the name), cannot access the Exchange server or cannot access a directory server.
So, whether it's DNS, Exchange or a GC he cannot see, adding a route to his client will allow him to see all of the servers (if we get the route right) whilst maintaining local Internet access.
In a nut shell - when he sends everything down the VPN it's OK, when he sends traffic just to the local VPN subnet, it's not OK. Therefore we need something in the middle - adding the static routes will give us that.
D
ErnestM said:
Spot on Deejay. I always use a hardware solution as it just seems easier to build the routing tables at the firewall/router. Configuring the tables on the client is frought with issues (but not impossible).
ErnestM
ErnestM
Ernest - thanks for the vote of confidence
. It's actually the client in this case. Most hardware VPN solutions (Cisco/VPN 1 etc) have a dedicated client, and as you said routing can be controlled at the server end. Alternatively, using the client's ADSL router would be equally suitable (assuming they don't use any 2 factor authentication).
It's the same for the MS client - you can define static routes on the server side (using a DHCP scope option) and the MS client will apply them for the duration of the VPN session.
If I were running their remote access system and had to support Microsoft VPN clients, then I'd just simply configure DHCP to include the networks I wanted to allow VPN access to. The last thing I'd want is users attempting to configure it themselves!
Darren.
aldi said:
Oh, that's what you and blairout were talking about earlier isn't it - the vpn subnet and the rest of the servies being on different subnets on the far end. Gotcha I think 
Yep, that's right.
I'm probably going well off topic here, but here's what happens on the client behind the scenes when you establish a VPN connection.
You start off with a routing table which basically says:
- If you want to get to any network other than your home network, send it to your ADSL router, using your ethernet/wireless card
- if you want to get to your home network, send the traffic using your ethernet/wireless card
So, you establish a VPN connection to get to your work network. Your works network consists of 3 subnets 10.1, 10.2 and 10.3
When you established your VPN connection you checked the 'use gateway on remote network'
When the VPN is established, you're machine is given another IP address (on the 10.1 network)
Your routing table now says:
- if you want to get to 10.1 send the traffic using your virtual VPN interface
- if you want to get to any network other than your home network, send it to the default gateway on the 10.1 network using the virtual VPN interface
- if you want to get to your home network, send the traffic using your ethernet/wireless card
So, whenever you access anything remote, the machine uses the virtual VPN interface. That's great, as your client sends everything to the router on the 10.1 network, and because that router knows about 10.2 and 10.3, you can access DNS servers, Exchange et al on those network too (which for arguments sake sit on the 10.2 and 10.3 networks).
However, the problem is that when you try to access www.google.com, it sends that traffic down the VPN too. That's OK, apart from the VPN endpoint is in the states and you're seen on the Internet using a US IP address, so cannot access UK only content such as the BBC world cup coverage.
So, you have a think about this, and uncheck the 'use default gateway on remote network' checkbox on the VPN.
When you establish the connection this time, your routing table says:
- if you want to get to 10.1 send the traffic using your virtual VPN interface
- if you want to get to your home network, send the traffic using your ethernet/wireless card
- If you want to get to any network other than your home network, send it to your ADSL router, using your ethernet/wireless card
At this point, your world cup streaming works fine (because your internet traffic goes straight out over the VPN). However, what about 10.2 and 10.3? Basically, that traffic doesn't get sent over the VPN anymore.
So, we ideally want another 2 routes - so 10.2 and 10.3 are accessed using the VPN, but everything else stays as it is....
However, to be able to do that we need to know his local area network and the the original posters equivalent of the 10.2 and 10.3 networks.
Hope that makes sense!!
Darren
_deejay_ said:
aldi said:
Oh, that's what you and blairout were talking about earlier isn't it - the vpn subnet and the rest of the servies being on different subnets on the far end. Gotcha I think
Yep, that's right.
I'm probably going well off topic here, but here's what happens on the client behind the scenes when you establish a VPN connection.
You start off with a routing table which basically says:
- If you want to get to any network other than your home network, send it to your ADSL router, using your ethernet/wireless card
- if you want to get to your home network, send the traffic using your ethernet/wireless card
So, you establish a VPN connection to get to your work network. Your works network consists of 3 subnets 10.1, 10.2 and 10.3
When you established your VPN connection you checked the 'use gateway on remote network'
When the VPN is established, you're machine is given another IP address (on the 10.1 network)
Your routing table now says:
- if you want to get to 10.1 send the traffic using your virtual VPN interface
- if you want to get to any network other than your home network, send it to the default gateway on the 10.1 network using the virtual VPN interface
- if you want to get to your home network, send the traffic using your ethernet/wireless card
So, whenever you access anything remote, the machine uses the virtual VPN interface. That's great, as your client sends everything to the router on the 10.1 network, and because that router knows about 10.2 and 10.3, you can access DNS servers, Exchange et al on those network too (which for arguments sake sit on the 10.2 and 10.3 networks).
However, the problem is that when you try to access www.google.com, it sends that traffic down the VPN too. That's OK, apart from the VPN endpoint is in the states and you're seen on the Internet using a US IP address, so cannot access UK only content such as the BBC world cup coverage.
So, you have a think about this, and uncheck the 'use default gateway on remote network' checkbox on the VPN.
When you establish the connection this time, your routing table says:
- if you want to get to 10.1 send the traffic using your virtual VPN interface
- if you want to get to your home network, send the traffic using your ethernet/wireless card
- If you want to get to any network other than your home network, send it to your ADSL router, using your ethernet/wireless card
At this point, your world cup streaming works fine (because your internet traffic goes straight out over the VPN). However, what about 10.2 and 10.3? Basically, that traffic doesn't get sent over the VPN anymore.
So, we ideally want another 2 routes - so 10.2 and 10.3 are accessed using the VPN, but everything else stays as it is....
However, to be able to do that we need to know his local area network and the the original posters equivalent of the 10.2 and 10.3 networks.
Hope that makes sense!!
Darren
You can stick my consultation fee on the tab Kerching 
aldi said:
So you're confident that the MS client still uses the vpn assigned DNS settings even though you've told it not to change the default gateway?
Absolutely certain.... Unticking the DefGW tick box leaves server assigned DNS settings in place. I just fired mine up first to double check You can always set them manually if you want to override any of the properties assigned through DHCP. Now if the corporate DNS is on a different subnet......
Best case scenario is if they're using a 172.16.X.X addressing scheme on the corporate network. A single static route covers every eventuality.
_deejay_ said:
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
So here's the IP info and some other pieces in case this is helpful:
IP address for my wireless network connection is 10.0.X.X
Subnet mask 255.255.X.X
DGW 10.0.X.X
IP address PPP Adapter VPN is 192.168.X.X
Subnet mask 255.255.X.X
DGW 192.168.X.X
I had no idea what I'd started when I posted the original question! Thanks for using this opportunity as a case study for your various consulting businesses. Hope y'all managed to get some sunshine over the weekend as well
route ADD 192.16.0.0 MASK 255.255.0.0 10.0.x.x (that will be the IP address of the DefGW that you get with your VPN established and the use DefGW tickbox ticked)
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
BliarOut said:
route ADD 192.16.0.0 MASK 255.255.0.0 10.0.x.x (that will be the IP address of the DefGW that you get with your VPN established and the use DefGW tickbox ticked)
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
Damned consultants. Try again
it's 192.168, and the default gateway needs to be the default gateway of the VPN NIC
D
edited to add: the command is actually 'route add 192.168.0.0 mask 255.255.0.0 <gateway on vpn adapter>'.
To obtain the gateway IP address, VPN into the system with the 'use remote gateway checked' then run 'route print' from a command line
It'll display a table. On the line which starts 0.0.0.0, you'll see the address under the gateway field. It should start 192.168.x.x not 10.x.x.x
Once you've done that and added the route command, you'll be able to uncheck the gateway setting and try again.
Darren.
Edited by _DeeJay_ on Monday 3rd July 09:40
_DeeJay_ said:
BliarOut said:
route ADD 192.16.0.0 MASK 255.255.0.0 10.0.x.x (that will be the IP address of the DefGW that you get with your VPN established and the use DefGW tickbox ticked)
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
When you're happy, run that command with a -p to make the route permanent.
Job done. Basically any of the internal US networks are within the 192.168 range, so just dump any 192.168 traffic over the VPN and let the rest head for the internet.
Damned consultants. Try again
it's 192.168, and the default gateway needs to be the default gateway of the VPN NIC
D
edited to add: the command is actually 'route add 192.168.0.0 mask 255.255.0.0 <gateway on vpn adapter>'.
To obtain the gateway IP address, VPN into the system with the 'use remote gateway checked' then run 'route print' from a command line
It'll display a table. On the line which starts 0.0.0.0, you'll see the address under the gateway field.
Once you've done that and added the route command, you'll be able to uncheck the gateway setting and try again.
Darren.
Edited by _DeeJay_ on Monday 3rd July 09:28
Right, I'm aiming to completely clear the porcelain this time
Yes, it was a lazy copy/paste on my part as we don't actually know the correct DefGW as yet, the clue was this bit ....(that will be the IP address of the DefGW that you get with your VPN established and the use DefGW tickbox ticked).
I think what we have here is two IT bods argueing to agree
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff