So, it’s time for my annual blog post.
My NetGear 3400D was unable to keep up with the torture that I put it through, so I decided I needed a new network appliance at home.
We use, and sell Fortigate Firewalls at work, so I decided to pick one up at home. This would a) be more robust than a consumer “router” and b) would allow me to work on developing some badly needed network/firewall/vpn knowledge. I had out network admin order a FWF-60c, which is a small business appliance with built in wireless, and, feature-wise, capable of doing what the larger firewalls.
Installing the Fortigate was dead simple, I used the FortiClient software and the wizard to get me off the ground. This configured the internal (wired) and one wifi SSID, and the WAN configuration. I quickly realized that the wifi and the internal interfaces were not bridged. This would present a problem that I would have to solve a little later.
I then decided to test upgrading the firmware from the 4.0 tree to the 5.0 tree. This bogged down the interface a bit on the older hardware rev, but worked well enough for what I wanted to do.
I then refined my policies to match what I had on the NetGear and brought it home.
Performance was astounding.
The first problem I ran into was that I have a first generation Playstation 3, the 20GB edition without wireless. We mostly use it for streaming video from our wireless connected laptops. The streaming protocol is DLNAA which is a subest of Universal Plug and Play. The Fortigate doesn’t support UPnP. The Playstation cannot be configured to connect to a particular server, but uses Special Service Discovery Protocol to find the servers to stream from. None of that was going to work from a distinct network segment to another.
So, out of the box, the streaming wasn’t going to work. I started to look for a solution, but there wasn’t anything online to help me with this, as this was a fairly corner case; people don’t use these for home networking much. I had to do some snooping. Running a few packet captures revealed that SSDP used multicast. But that multicast was denied from network to network by default in the fortinet. Some google-fu taught me how to enable multicast on a fortigate. It has to be done from the CLI, but is like any firewall policy. You’ll need two, one from “internal” to “wifi” and one from “wifi” to “internal”
config firewall multicast-policy
set action accept
set srcintf wifi
set dstintf internal
set srcaddr all
set dstaddr all
set action accept
set srcintf internal
set dstintf wifi
set srcaddr all
set dstaddr all
Then, elsewhere in the firewall, put in standard policies to allow the network to pass other traffic to each other, since they are internal, I let the open any ports. I’m sure you can find a list of the myriad streaming ports required if you want something more restrictive. I enabled NAT between the two, I don’t know if that’s necessary, but it worked. And Voila, I can stream! (and do other UPnP things, without the “helpful” daemon.)
Part 2, VPNs
I’ve been waiting, and working.
I’ve been waiting for my work to release a its new product. I’ve been waiting, politely, for my boss to blog about it. I’ve been waiting to show off this new product.
I’ve been working on provisioning, and working with customers on beta testing the new product. I’ve been working on templates, and auto install media, to make everyone’s life easier. I’ve been working on documentation for customers.
I’ve been waiting for, and working on, a VMware vCloud Director based product known as vmForge VDC.
This is cool stuff!
It’s been awhile.
Recently, I’ve decided to make sure that all of my servers were IPv6 addressable. This was made infinitely easier by working at a forward thinking ISP. So a quick email to our network admin and bam! IPv6 routed to my vlan!
Now, what to do with it?
So I put a hypervisor in your hypervisor, so you can virtualize while you virtualize.
VMware vSphere, lots of RAM, a decent amount of disk space, a fairly recent copy of 64bit Windows (I used Server 2008 R2) ESX and vSphere Server iso and exe files. Iron will. Patience. Some sort of NAS distribution (I used FreeNAS.)
Hey, it works! I’m moving a file (on a GIG-E switch between VLANs) at around 3MBps.
Thanks to http://linux-bsd-sharing.blogspot.com/2008/09/howto-setup-nfs-server-on-freebsd.html
I bought a gaming laptop. I bought it thinking that I could do a lot with the nice, powerful chip that came with it. My first disappointment was the horribly outdated NVIDIA drivers that came with the laptop. I could not play WoW, at all. I found this odd for a gaming laptop. I could forgive them for giving me 4gigs of Ram, but a 32-bit operating system. My second is this, I cannot enable VT extensions on my CPU, even though it clearly supports it. I need to be able to run VMWare and/or VirtualPC for various work projects. This is highly disappointing. Ultimately, my prime gaming laptop may end up collecting dust in the closet, a constant reminder of why no one should buy Gateway.
One of Chronophage.net’s servers is virtualized inside of a Dell 1500. It runs like a champ. I think this is the future of hosting, especially with power and cooling costs going up. I should work on my VTSP now.
Ares.chronophage.net used to be my experimental FreeBSD box. It ran on a T2100 dual-core consumer system with 1.5 gigs of ram and an 80GB harddrive (a freebie that Dell sent to one of my company’s customers, ESATA) The system was slow, unreliable, and prone to crashing. With VMWare, things are scaling really well. The tools were in the ports tree, and it was painless to install. The system converter worked better than expected (since FreeBSD is not officially supported) All in all, this is a successful experiment.