Not everything works virtually the same way it does physically. In this post, I’m referring to the network drivers that come with VMware Fusion (latest release). This is an important issue because it brings to light that point that many people glaze over: the difference between the physical and virtual IT world.
Take, for example, the case of one nerd-without-a-life-but-mysteriously-with-a-wife who spent last weekend setting up a VPN using L2TP over IPSec and took forever getting it working. This nerd — we’ll call him Landrew Lutz — even went so far as reducing his configuration to PPTP just to lose some of the complexities. Still no joy!
Turning on debugging in PPTP reveals the following truth facts:
Dec 2 05:09:52 pan pptpd: CTRL: Starting call (launching pppd, opening GRE)
Dec 2 05:09:52 pan pptpd: GRE: Bad checksum from pppd.
Dec 2 05:10:22 pan pptpd: GRE: read(fd=6,buffer=610ba0,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Dec 2 05:10:22 pan pptpd: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
It seems that the generic routing encapsulation (GRE) packet is not being successfully read from the network interface and thus resulting in a bad checksum. Okay, not so odd, right? Except it was odd because that EXACT pptpp.options file that was working for PPP on Landrew’s router — the router has a PPTP daemon — did not work on the VM (virtual machine) he was using for testing. WTF mate?!? What was the difference? Landrew thought about it and came to the realization that the router was physical and the VM was, well, virtual.
Now, Landrew did so happen to have a physical Linux server running Ubuntu Feisty Fawn 7.04 64-bit. He installed PPTP on that and using the same configuration EVERYTHING WORKED THE FIRST TIME!!! Again, WTF mate?!?! Given that Landrew’s original VM was actually running Ubuntu’s latest release, Gusty Gibbon 7.10 64-bit, he decided to blame everything on the version of PPP that ships on Gutsy as opposed to what is running on his physical server and router. Except that PPP has not been updated in over a year (ftp://ftp.samba.org/pub/ppp/). Yeah well, Landrew decided to give virtualization the benefit of the doubt and installed a VM with Feisty Fawn and set PPTP up one more time. It did not work!!!
This means that the likely cause of the error is the network drivers that VMware is providing with Fusion. Something is cutting off packets before they can go home. The packets thing they are too good for their home? Why do the packets hate poor Landrew? This is a rather glaring example of when going virtual can hurt rather than help.
Although the last few paragraphs only took a few minutes to read, it took Landrew between 20-30 hours to figure all of this out; because, after all, virtualization is never to blame, right?
I’ve further tested this on ESX 3.0.1 and VMware Server 2.0 without error. Can anyone test this on VMware Workstation and VMware Server
1.0.4 for me? Thanks!