Tag Archives: Virtualization

The Path to x64

Posted on by
Reply

RAM prices are dirt cheap, and with the amount of work I’m doing on virtual machines lately, it would be silly to not get another stick of 2 GB to my existing 2 GB.

2 + 2 might make 5 if you were in the world of Big Brother, but in the 32-bit world, 2 + 2 is somewhere in the range of 3 ~ 3.5 GB. 32-bit systems are not always able to address up to the full 4 GB of available physical memory, the reason is a bit complicated and has to do with virtual addressing limits. I’ll save myself from rehashing what others have written on the topic and refer you to the excellent article here.

The transition from 32-bits to 64-bits was smoother than I expected. First of all, I’m running on an OEM version of Windows Vista Business 32-bit, and I needed a 64-bit copy of Windows. Luckily obtaining the installation media wasn’t an issue for me as I had a copy of Windows Ultimate lying around, which I won from a Microsoft talk last year. I admit I was a reluctant to open the shrink wrap at first, but I desperately needed the media.

It is worthwhile to note that serial keys for Windows Vista are tied to the edition (Home Premium, Business, Ultimate etc) but not to the bitness (32-bit or 64-bit). Therefore, using my old Business edition serial was perfectly fine and I can save my Ultimate edition license for another day.

There is no difference in the installation process between the two bitness. The only difference, and deal breaker for many is that 64-bit Vista requires 64-bit drivers, and the drivers have to be digitally signed. The only two drivers that I have trouble with were Sony Ericsson’s PC Suit, which was required to sync my phone and Adobe’s PDF printer. It seems that I’m out of luck for the former, but the latter got addressed with a patch.

The only issue I had was with poorly written applications which hardcode their installation paths. In Windows x64, program space is separated depending on if they’re 32 or 64 bit (with a few naming oddities I must say, but they’re all preserved for compatibility reasons). However, SOE’s launchpad absolutely insists on writing to C:Program FilesSonyStationLaunchPad despite the fact that 32-bit applications are suppposed to be redirected to C:Program Files (x86). The problem exists with only the launchpad itself though, it is able to patch EQ2 in its correct C:Program Files (x86) path.

The other problem I have was with 64-bit Java; it didn’t provide a plugin for 32-bit Firefox. There exists a way to work around this on Linux, but as far as my Google skills go, I couldn’t find a solution on Windows. Therefore, I went back to 32-bit Java.

With a full 4 GB of addressable memory, there certainly has been some changes to my workflow. I’m gradually becoming a huge fan of keeping my system clean and moving my work onto virtual machines. I might be a terribly messy person in real life, but I almost have a certain OCD when it comes to organizing my system. I’d almost do all my work exclusively inside virtual machines if not for the fact that I’m a gamer, and that virtualized 3D hardware acceleration isn’t quite here yet, but it will be one day. Guaranteed its not much and it’ll take another year or two, or even longer, before the technology matures, but VMWare Fusion already has experimental Direct X 9 support, and its the road that we’re going to take.

There’s still a vacuum as far as 64-bit software is concerned. Let’s face it, there’s not that many applications that would benefit from a 32-bit to 64-bit transition. WoW64 does its job of running 32-bit applications on Windows x64 just fine without any performance degradation, despite all the rumors that fly around.

Lost in transition: ICMP Redirects

Posted on by
1

I configured and installed Ubuntu Server 8.04 with the typical LAMP setup with the intend of mirroring this blog locally so I could test out a few changes without affecting the live copy and placed the server virtualized, behind the Vyatta router.

icmp_network_diag

Back on my desktop, I was greeted with a previously unseen error as I navigated to the site.

interrupted

I verified that Apache was running with a ps aux | grep apache, and indeed it was. I checked that I was able to access the page from machine on the same subnet. At this point, I suspected it was an issue with the Vyatta router, although its rather puzzling since all traffic initiated from the 192.168.5.0 network, internet bound or otherwise seemed to be working fine.

ubuntu_tcpdump

Carrying out tcpdump on the Ubuntu server, it seems that the first SYN packet from 192.168.1.50 was received, and judging from the subsequent similar (they all have same sequence numbers) SYN-ACK packets that were sent out from the server, it was clear that server never heard from 192.168.1.50 any further. One of the following could’ve happened:

  1. The SYN-ACK bound for 192.168.1.50 never arrived at its destination.
  2. The SYN-ACK packets arrived at 192.168.1.50, but the ACK respond required to complete the handshake never made it back to the server.

Carrying out a tcpdump dump similarly on eth0 of Vyatta, I was able to verify that the packets were following both ways, which took the fault of the router of the question. All was well with it.

I don’t know why I didn’t look at this earlier, but when you install a sparkling new piece of equipment and it something doesn’t work, you would automatically lay blame to that equipment instead of examining the complete picture closely, exactly like the old rhetoric “it used to work until I <insert something that you recently just did here>”. I ran Wireshark, which is a GUI version of a packet capturing tool much like tcpdump on my desktop itself. What showed next was the reason behind all my problems.

Wireshark showed that my IPCop router was sending me an ICMP redirect for every packet I sent out destined for 192.168.5.3. It was then that it occurred to me that since the Vyatta router had an interface in the same network as my computer, IPCop was telling me that that shorter route to the 192.168.5.0 network was to send it directly to the gateway at 192.168.1.150 instead of sending it to the default gateway specified on the desktop of 192.168.1.1 aka IPCop and then have it rerouted.

It turns out that on Windows if the Windows Firewall is turned on, ICMP redirects are dropped by default. As a routing mechanism, ICMP redirects have no security built in and hence, are vulnerable to IP spoofing attacks. So although an ICMP redirect was sent to my computer, it was silently dropped and the message never got through.

To get around this problem, the firewall could simply be enabled to accept ICMP redirects. Despite the security issues with it, it is rather safe on a small LAN where every computer comes under my control and ICMP requests are not forwarded by the exterior facing router into the network. Alternatively, an entry could be added in the Windows routing table.

route -p add 192.168.5.0 mask 255.255.255.0 192.168.1.150

It turns out to be a simple and small issue, but it took the better part of an afternoon to solve. Its all about the learning experience I guess, that’s what the network was setup for in the first place.

Setting up the virtual network

Posted on by
Reply

Virtualization is a cool new buzzword, but it goes beyond that, it is actually going to help me solve a few problems. Before I go any further, here’s the network topology of my setup.

Network diagram

I’ve a few objectives I wish to attain with this setup. Mainly,

  • Learning Windows administration in depth.
  • Testing Vyatta and hope to eventually use it as my primary router.
  • Learning to implement more complex network setups with various routing protocols. I’ll eventually add more routers to my existing virtualized topology. Now I’m just getting the basics off the ground.
  • Learning some basic Linux administration. I’m adding Ubuntu 8.04 to the pile of virtualized OS soon, I currently have it installed on my desktop via Wubi.
  • Learning and deploying IPv6 as a minor objective after all the above has been satisfied.

My main home router is an old P3 450 MHz machine that’s finding new purpose in life and now runs IPCop. The router for my virtualized network runs Vyatta.

Taking advantage of Microsoft’s trial program for their server and developer products, I downloaded a copy of Windows Server 2008. The 60 day evaluation period can be extended to 240 days, and doing so is even blessed by Microsoft. One reinstallation every 240 days sound fair enough for me. This time I really really am going sit down and teach myself Active Directory. Yes, really.

In order for the newly added network to be recognized, an entry in IPCop’s routing table needed to be added. Being a SOHO router distribution, it doesn’t support any routing protocols so a static route had to be manually added. As a Linux newbie, the whole process took way longer because of a silly mistake that I made, missing out the gateway portion of the route add command. From my past experiences working on Cisco routers, adding a static path required you only to specify the destination network address, mask and either the next hop router address or outgoing interface. I hastily entered the same, specifying the outgoing interface without realizing that if a gateway is between the two networks, I’ve to use the next hop address syntax instead of just specifying the outgoing interface.

Correct:

route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.1.150

Wrong:

route add -net 192.168.5.0 netmask 255.255.255.0 eth0

This resulted in a scenario of traffic being able to reach from 192.168.1.1 to 192.168.5.1, but not to the rest of the 192.168.5.0 network, which puzzled me greatly until I realized my folly.

Another silly was the result of cloning VMWare machines. The fact that cloned machines would have similar MAC addresses never crossed my mind, and that caused all kinds of havoc on its own. It was fixed by changing the MAC address in the machine configuration file (.vmx).

Aside from those issues, setting up the network was relatively easy. Vyatta took minimal configuration out of the box.

Setting up the interfaces:

set interfaces ethernet eth0 address 192.168.1.150/24
set interfaces ethernet eth1 address 192.168.5.1/24

Default routing to allow internet access:

set protocols static route 0.0.0.0/0 next-hop 192.168.1.1

Enable the ssh service:

set service ssh

In Vyatta, changes are not committed immediately after typing in every command until you explicitly tell it to, so:

commit

Done for now, more updates on this small project of mine as they come along. Oh, and I’m proud of the network diagram I drew, it’s the cleanest and neatest one I’ve ever done. Previously they were hand drawn or MS Paint jobs, this one’s done in Powerpoint.