VPN, RDP, MTU and StoneGate debugging
(4 votes, average: 4.75 out of 5)
Loading ...One of the features I use often, and especially in cases when there is some sort of trouble, is the ability to actually see what traffic passes the firewall.
Most admins don’t feel comfortable using the console (over ssh), and ofcourse it is not as trivial as it seems – especially remembering the exact commands. So, for the community, and for my own personal use, I’ll document a small issue I just had, and how I “solved” it.
A customer called, saying: “I use the StoneGate VPN to connect to my server with RDP, and all I get is a black screen”. Now, that’s something that’s (unfortunately) not too uncommon. Google for “MTU”, “Path MTU Discovery” and “Black Hole Detection”, and you’ll get tons of info, which all come down to:
Single packets in ethernet networks have a maximum size of 1500 bytes (RFC 879). 1460 bytes of data + 40 bytes header (ip-addresses, ports, settings etc.). All tunneling protocols (VPN, PPTP,PPPoE, etc.) add some bytes to the header part. This means less room for the data part.
Both “client” and “server” agree to send packets with max. 1460 bytes of data. The first few packets of the connection aren’t large, perhaps 1000 bytes max, and fit through perfectly. Client and server agree to communicate, draw a frame of the correct size, etc. Then however, comes the Windows Logo, a picture that is over 3000 bytes of size. That means, 2 large packets are sent. Somewhere on the connection from server to client, these packets do not fit. So, the picture the server sent, does not reach the client. A black screen of the wanted size just sits there, and waits… and waits…. and waits…..
Since I do not want to discuss what causes this, but just want to know if it IS an MTU issue, I do following:
- check if both sides agree to use 1460 bytes of data
- reduce the packet size on either client or server side to 1310 bytes of data
- test whether RDP works again
Recent Comments