VPN + US based MS Exchange server

[BliarOut]

_DeeJay_ said:

And the error was this bit

BliarOut said:

route ADD 192.16.0.0 MASK 255.255.0.0 10.0.x.x

Sorry, just attempting to keep them amused whilst the OP returns... At least it's not got to argu(e)ing about spelling yet....

I know, I know, I know, I'm already rueing my lazy pasting skills

But it's still my client end soultion we're debating

[hut49]

_DeeJay_ said:

hut49 said:

The Exchange server IP is 192.168.X.X

OK, that should be enough information. Just out of interest, did the first x in yourIP address PPP Adapter VPN IP address match the first X of the Exchange server IP address?

thanks,
Darren.

Edited by _DeeJay_ on Monday 3rd July 09:09

No, they are different.

[_DeeJay_]

hut49 said:

_DeeJay_ said:

hut49 said:

The Exchange server IP is 192.168.X.X

OK, that should be enough information. Just out of interest, did the first x in yourIP address PPP Adapter VPN IP address match the first X of the Exchange server IP address?

thanks,
Darren.

Edited by _DeeJay_ on Monday 3rd July 09:09

No, they are different.

Brilliant, then that explains why it's not working with the box checked. If you can follow the instructions on my previous post about finding the gateway address we should be set.

Darren.

[hut49]

_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.

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

I ran the route print cmd and got the table. So, before venturing into the darkness and doing something my IT dept might regard as grounds for disconnection of all services, can I check that the following is the correct entry for the cmd line

route ADD 192.168.0.0 MASK 255.255.0.0 192.168.X.X

where the last IP address in that entry is that for the PPP Adapter VPN that I got from the table?

Having entered that cmd I can then go and uncheck the use default gateway box in the TCP/IP settings for the VPN

Do I need to add the -p at the end of this cmd? or should I try it first without the -p and if it works then repeat the cmd with the -p to make it permanent?

[_DeeJay_]

hut49 said:

_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.

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

I ran the route print cmd and got the table. So, before venturing into the darkness and doing something my IT dept might regard as grounds for disconnection of all services, can I check that the following is the correct entry for the cmd line

route ADD 192.168.0.0 MASK 255.255.0.0 192.168.X.X

where the last IP address in that entry is that for the PPP Adapter VPN that I got from the table?

Having entered that cmd I can then go and uncheck the use default gateway box in the TCP/IP settings for the VPN

Do I need to add the -p at the end of this cmd? or should I try it first without the -p and if it works then repeat the cmd with the -p to make it permanent?

They'll never know . the 192.168.x.x will be the address from the table, and will differ slightly to the IP address that your VPN adapter has been given.
If you do it without the -p to start with then test it. If it doesn't work, a reboot will get you back to where you started.

If it does work, then you can run it with -p so that you don't have to make the change each time you reboot your machine.

Darren.

[hut49]

The 192.168.X.X for the PPP adapter VPN and the IP address I looked up in the table are exactly the same - but are different to the IP address of the Exchange Server which also starts 192.168.X.X

Hope I'm not getting anyone confused....

[BliarOut]

hut49 said:

The 192.168.X.X for the PPP adapter VPN and the IP address I looked up in the table are exactly the same - but are different to the IP address of the Exchange Server which also starts 192.168.X.X

Hope I'm not getting anyone confused....

Not at all... And that's how it should be and why it doesn't work when you untick the Use Default Gateway checkbox. The Exchange server is on a different subnet to the VPN endpoint that you connect to.

Just type route ADD 192.168.0.0 MASK 255.255.0.0 192.168.X.X

Where X.X is the IP address of your default gateway with the VPN established and the Use Default Gateway tickbox checked.

[hut49]

I made that entry on the cmd line and then unchecked the default gateway box on the VPN - message that this would not become effective until the next dial in - so I closed the VPN connection and re-dialed it. VPN restablished, browser goes direct rather than through VPN but Outlook not able to handshake with the Exchange server. Back to square one....

[_DeeJay_]

hut49 said:

I made that entry on the cmd line and then unchecked the default gateway box on the VPN - message that this would not become effective until the next dial in - so I closed the VPN connection and re-dialed it. VPN restablished, browser goes direct rather than through VPN but Outlook not able to handshake with the Exchange server. Back to square one....

Ok, that's fine. Lets work out what's going wrong.

Once you've VPN'd can you still ping the exchange server?

Darren

[BliarOut]

Nah, it'll work, it's just a bit tricky with all the X.X's

It's not a security risk to publish the exact IP addresses as 192.168.x.x and 10.x.x.x are all in the unassigned IP ranges and if we have the numbers it will make helping you easier.

Can you post the IP address of the Exchange server and copy the full output of a route print command up here. (You can hide any 'real' IP addresses if you're concerned)

Also, if you type tracert 192.168.x.x where x.x is the IP address of your Exchange server you should see which way the packets are actually going.

[hut49]

_DeeJay_ said:

hut49 said:

I made that entry on the cmd line and then unchecked the default gateway box on the VPN - message that this would not become effective until the next dial in - so I closed the VPN connection and re-dialed it. VPN restablished, browser goes direct rather than through VPN but Outlook not able to handshake with the Exchange server. Back to square one....

Ok, that's fine. Lets work out what's going wrong.

Once you've VPN'd can you still ping the exchange server?

Darren

No - the request times out

[_DeeJay_]

hut49 said:

_DeeJay_ said:

hut49 said:

I made that entry on the cmd line and then unchecked the default gateway box on the VPN - message that this would not become effective until the next dial in - so I closed the VPN connection and re-dialed it. VPN restablished, browser goes direct rather than through VPN but Outlook not able to handshake with the Exchange server. Back to square one....

Ok, that's fine. Lets work out what's going wrong.

Once you've VPN'd can you still ping the exchange server?

Darren

No - the request times out

As has been said, the chances are you've got the route wrong and it's hard to work out where without the IP addresses.

Just for clarity your current routing table (route print) will have a line which says:

192.168.0.0 255.255.0.0 <IP address of the gateway> <IP address for VPN adapter>

Where the two addresses in <> are different.

Darren

[hut49]

BliarOut said:

Nah, it'll work, it's just a bit tricky with all the X.X's

It's not a security risk to publish the exact IP addresses as 192.168.x.x and 10.x.x.x are all in the unassigned IP ranges and if we have the numbers it will make helping you easier.

Can you post the IP address of the Exchange server and copy the full output of a route print command up here. (You can hide any 'real' IP addresses if you're concerned)

Also, if you type tracert 192.168.x.x where x.x is the IP address of your Exchange server you should see which way the packets are actually going.

I'm pretty much out of my depth here and have no way of knowing what security risk in posed by publicising this route print info. No offense BlairOut but can anyone corroborate? I appreciate that two great PHers are trying to help me out and I don't want to be a wuss but I also don't want to have the IT guy calling me saying his P&J is under attack!

I did try the tracert cmd but the destination host was unreachable after the 5th hop starting at 192.168.X.X where this X.X is different to the IP address of the Exchange Server

[BliarOut]

hut49 said:

BliarOut said:

Nah, it'll work, it's just a bit tricky with all the X.X's

It's not a security risk to publish the exact IP addresses as 192.168.x.x and 10.x.x.x are all in the unassigned IP ranges and if we have the numbers it will make helping you easier.

Can you post the IP address of the Exchange server and copy the full output of a route print command up here. (You can hide any 'real' IP addresses if you're concerned)

Also, if you type tracert 192.168.x.x where x.x is the IP address of your Exchange server you should see which way the packets are actually going.

I'm pretty much out of my depth here and have no way of knowing what security risk in posed by publicising this route print info. No offense BlairOut but can anyone corroborate? I appreciate that two great PHers are trying to help me out and I don't want to be a wuss but I also don't want to have the IT guy calling me saying his P&J is under attack!

I did try the tracert cmd but the destination host was unreachable after the 5th hop starting at 192.168.X.X where this X.X is different to the IP address of the Exchange Server

No worries... Once we've resolved the prob with posting the info (link to IANA doc here, the section titled Special-Use addresses covers it) what is of interest is that fifth hop IP address. It could be a class B or a class A address. If it starts 192.168, 172.16 or 10. then it's totally safe to post it up here. If not, obscure the last set of digits for now.

[_DeeJay_]

hut49 said:

BliarOut said:

Nah, it'll work, it's just a bit tricky with all the X.X's

It's not a security risk to publish the exact IP addresses as 192.168.x.x and 10.x.x.x are all in the unassigned IP ranges and if we have the numbers it will make helping you easier.

Can you post the IP address of the Exchange server and copy the full output of a route print command up here. (You can hide any 'real' IP addresses if you're concerned)

Also, if you type tracert 192.168.x.x where x.x is the IP address of your Exchange server you should see which way the packets are actually going.

I'm pretty much out of my depth here and have no way of knowing what security risk in posed by publicising this route print info. No offense BlairOut but can anyone corroborate? I appreciate that two great PHers are trying to help me out and I don't want to be a wuss but I also don't want to have the IT guy calling me saying his P&J is under attack!

I did try the tracert cmd but the destination host was unreachable after the 5th hop starting at 192.168.X.X where this X.X is different to the IP address of the Exchange Server

It is fairly safe, though I wouldn't do it from here (work). BlairOut - you want to post yours?
As Blairout said, it's just the one address that's useful (the one it fails on).

Another way of approaching this, I think if there's 5 hops, the route isn't working and the traffic is being sent to the Internet.
There's should only be a handful of hops, probably VPN default gateway then the server itself.

To test that theory, does the first hop return a 10 address or a 192 address?

192 and your route is OK, 10 and it's not.

Darren.

[BliarOut]

Our DefGW is 172.16.254.5, our main server is 172.16.254.1, our mail server is 172.16.254.15 all with a 255.255.255.0 mask. Feel free to hack away to your hearts content

Just making the point that it's safe... All ISP's should be dropping any private packets before they ever reach the internet in case a network admin cocks up a router and accidentally sends out routing info for a private network.

Between us if we can see where your tracert is failing we can advise on how to add the correct static routes and get it working for you.

[hut49]

I haven't re-booted since running the 'fix' that didn't produce what we wanted. Should I re-boot then run the tracert cmd with VPN connected and default gateway box checked or unchecked?

Or should I run tracert without re-booting?

And should I run the route print in those same conditions?

[BliarOut]

Don't reboot, that route isn't permanent yet.

Connect the VPN first with the UseDefGW ticked, then go into a command prompt and do route print and tracert ipaddressofyourexchangeserver. Then untick it, disconnect/reconnect and repeat.

You can blank out any numbers that don't start with 192.168.x.x 172.16.x.x or 10.x.x.x

That is enough info for us to advise you on the correct routing entries.

[hut49]

With VPN connected and DefGW box ticked:

1. Tracert exchange server cmd produces a one hop to the IP address and trace complete
2. Route print cmd gives the following:

*** info removed ***
With VPN connected but with DeGW box UN-checked:

1. Tracert gives the following:

***Info removed***

2. Route Print gives the following:

***Info removed***

Let me know if any of the above is too much info that I should edit, alternatively if you think I obscured important info, let me know that too!

Edited by hut49 on Monday 3rd July 13:40

Edited by hut49 on Monday 3rd July 20:50

[BliarOut]

That's odd, from the info I can see there the routing tables don't appear to alter between the two posts but IP packets destined for 192.168.160.200 are heading straight out to the net, which is what we suspected. I would have expected the DefGW on the first post to be 192.168.160.201.

Nothing you've posted there is a security risk, but the output of an ipconfig /all would help here (with the VPN connected). I won't quote you so you can delete the posts when we've done if you feel happier about that.