2008 VPN connectivity and MTU

Microsoft Windows server 2008 standard -...
January 28, 2010 at 05:35:33
Specs: Windows 2008, XEON 4Gb
Hi all,

I have a problem with a windows 2008 server that is running VPN. Configuration is as follows ..

2k8 server has 2 NICs

Internal NIC = 10.0.0.3/8
Internet NIC = 192.168.5.2/24

A Netgear DG834 on 192.168.5.1 with port 1723 forwarded to the internet NIC.

The VPN functionality was working perfectly at 22:30 last night when I restarted the server from a remote desktop session. However once the server had come back up, I re-established the VPN which all went through fine. However now when we come to send or retireve any data over the VPN or establish a rdp session. We get no reply from the server.....

Interestingly I can ping the server 10.0.0.3 and our appserver 10.0.0.9 or any other IP on the internal subnet, I can nbtstat -a the IP's and get the netbios ports, I can telnet to ports 25 etc on the main server.

However I cannot establish a remote desktop connection to EITHER server or map network drives .... after a bit of googling I came across people who had issues with MTU sizes over VPN. Testing this with a

ping -l 1342 10.0.0.3 -f

(ping 10.0.0.3 with 1342 bytes and dont fragment the packet) works fine ... however if I try with 1343 bytes of data the request times out. This was working fine yesterday, all that has happened is a reboot over night, after which im guessing some update or something has broken it. Has anyone else come across this or anything similar?


See More: 2008 VPN connectivity and MTU

Report •


#1
January 28, 2010 at 14:10:46
Update - have restarted the server - still the same. I have tried it with my laptop on a static address of 192.168.5.77 connected into the back of the dg834 to try vpn'ing in directly ... still no joy. The vpn connects instantly, and I can ping IP's on the internal side, view the netbios tables. Im back home now VPN'd in, all is calm VPN is stable, up for over 2 hrs .... I have found a handy utility called mturoute (www.elifulkerson.com/projects/mturoute.php) ... here is the output to 10.0.0.9 ....

* ICMP Fragmentation is not permitted. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 5046 bytes failed..
- ICMP payload of 2569 bytes failed..
...- ICMP payload of 1330 bytes failed..
...- ICMP payload of 711 bytes failed..
...- ICMP payload of 401 bytes failed..
...- ICMP payload of 246 bytes failed..
+ ICMP payload of 169 bytes succeeded.
...- ICMP payload of 207 bytes failed..
+ ICMP payload of 188 bytes succeeded.
...- ICMP payload of 197 bytes failed..
...- ICMP payload of 192 bytes failed..
+ ICMP payload of 190 bytes succeeded.
+ ICMP payload of 191 bytes succeeded.
+ ICMP payload of 191 bytes succeeded.
Path MTU: 219 bytes.

219!!?!?! .. and here to google ...

* ICMP Fragmentation is not permitted.
* Maximum payload is 10000 bytes. *
- ICMP payload of 5046 bytes failed..
- ICMP payload of 2569 bytes failed..
+ ICMP payload of 1330 bytes succeeded.
- ICMP payload of 1949 bytes failed..
- ICMP payload of 1639 bytes failed..
- ICMP payload of 1484 bytes failed..
+ ICMP payload of 1407 bytes succeeded.
- ICMP payload of 1445 bytes failed..
+ ICMP payload of 1426 bytes succeeded.
- ICMP payload of 1435 bytes failed..
+ ICMP payload of 1430 bytes succeeded.
- ICMP payload of 1432 bytes failed..
- ICMP payload of 1431 bytes failed..
+ ICMP payload of 1430 bytes succeeded.
+ ICMP payload of 1430 bytes succeeded.
Path MTU: 1458 bytes.

Much better ... so can anyone point me in the right direction as to my the MTU would be so ridiculously low .. ???



Report •

#2
January 28, 2010 at 15:28:48
Normally you don't vpn from the inside. I suspect you have this backwards. In other words 192.168.5.x should have the vpn not the 10.x.x.x subnet.

"A Netgear DG834 on 192.168.5.1 with port 1723 forwarded to the internet NIC."

That is not right. You forward from the WAN interface to the LAN interface [server ip 192.168.5.x] not the other way around.


Report •

#3
January 29, 2010 at 12:15:49
Its not backwards ... the 192 interface is effectivley the WAN connection as it is behind a NAT firewall ... 192.168.5.1 (the dg834). The 10.0.0.x subnet is the internal LAN.


{internet} --- (DG834)----(192 on 2k8)----(10 on 2k8)---(internal clients)

1723 is forwarded through the dg834, the vpn connects perfectly every time, and will remain stable for hours at a time, no disconnects.

Using mturoute (see earlier post) over the vpn to 10.0.0.9 it detects the maximum MTU as 219 when using windows 7 and 1400 when using Windows XP ... neither can reliably get rdp to work to anywhere - however pinging IP's, name resolution, viewing netbios tables all works fine... I can even collect mail via POP over the VPN.

I cant rdp, map drives, list the shares (even though I can nbtstat -a them) ... puzzled ..


Report •

Related Solutions

#4
January 29, 2010 at 12:30:09
Ok maybe this is a silly question by why the extra step?

It makes more sense to have all your clients, and the server, on the same subnet, plugged into the LAN side of the router (or into a switch plugged into the LAN side of the router) than it does to go through your server and change subnets while you're doing it.

Simply put, it's an extra layer of complexity and when it comes to most anything to do with computers (up to and including networking) one should always apply the KISS principle.

If you were setup my way:

Internet >> Router >> Clients/Servers

you wouldn't be having this problem.


Report •

#5
January 29, 2010 at 13:39:31
"the 192 interface is effectivley the WAN connection "
I understand that perfectly.

"The vpn connects instantly, and I can ping IP's on the INTERNAL side,"

Remember writing this in post #2 unreb?

Which is why I wrote: Normally you don't vpn from the inside. I suspect you have this backwards.

In other words you don't vpn to Internal NIC = 10.0.0.3/8
but to Internet NIC = 192.168.5.2/24

Now you are really side tracked over the MTU but if all you did was restart the server via rdp the MTU has nothing to do with the issue.

Your test shows you don't have the vpn on the right interface.

"I have tried it with my laptop on a static address of 192.168.5.77 connected into the back of the dg834 to try vpn'ing in directly"

So take the vpn OFF the internAL interface and put it ON the EXternal interface.


Report •

Ask Question