I have completed moving the WonderBlog into a three tier architecture in a virtualized DMZ and will document the configuration in the next few weeks, but I wanted to look over virtualized home network DMZ designs I didn't choose and discuss why I didn't choose them.

I wrote about the home based DMZ architecture I used, but that entry focused more on how the network was laid out. This post will discuss the designs I played with but didn't use for my home network architecture. My blog shows a three tier architecture in use, which consists of a client facing tier, an application tier, and a database tier. These three tiers are separate virtual machines, totaling four virtual machines on one server. The computer running those only has three gigabytes of RAM and I actually wanted 9 virtual machines. So I solved this problem of stuffing all of these virtual machines into three gigabytes by using operating system-level virtualization. This type of virtualization tends to be extremely efficient since it uses one virtual machine and lets the operating system partition off the virtual servers.

I used OpenBSD and OpenBSD's packet filter (pf), to manage all of the Solaris Zones and FreeBSD jails.  I thought about some other offshoot designs. The first design was to simply do the whole thing on one virtualized server. I could have put the firewall rules into the Solaris or FreeBSD host machine and used only one VM, but I found I liked working with separate pieces that made changing one part without harming others something I couldn't resist working with.  You have many choices. 

Simiar articles

• Home Network Features (azcrumpty.wordpress.com)
• Home Network With DMZ (azcrumpty.wordpress.com)

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
     groups: lo
     inet 127.0.0.1 netmask 0xff000000
     inet6 ::1 prefixlen 128
     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     lladdr 08:00:27:57:24:6b
     groups: egress
     media: Ethernet autoselect (1000baseT full-duplex)
     status: active
     inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
     inet6 fe80::a00:27ff:fe57:246b%em0 prefixlen 64 scopeid 0x1
     inet6 2002:43a4:a7f0:0:a00:27ff:fe57:246b prefixlen 64 autoconf pltime 16 vltime 26
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     lladdr 08:00:27:fb:e9:df
     media: Ethernet autoselect (1000baseT full-duplex)
     status: active
     inet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255
     inet6 fe80::a00:27ff:fefb:e9df%em1 prefixlen 64 scopeid 0x2
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     lladdr 08:00:27:68:63:2a
     media: Ethernet autoselect (1000baseT full-duplex)
     status: activea
     inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
     inet6 fe80::a00:27ff:fe68:632a%em2 prefixlen 64 scopeid 0x3
em3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     lladdr 08:00:27:a3:ad:7c
     media: Ethernet autoselect (1000baseT full-duplex)
     status: active
     inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255
     inet6 fe80::a00:27ff:fea3:ad7c%em3 prefixlen 64 scopeid 0x4
     enc0: flags=0<> mtu 1536
     pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
     groups: pflog

The first interface is bridged to the Ubuntu host's ethernet adapter. The tier interfaces follow as int1, int2, int3. I have used this design with Linux's Kernel Based Virtual Machine (KVM), Virtualbox, and VirtualPC. The picture above shows Solaris is configured to use each interface. The Solaris Zones are assigned to each interface and they route to the OpenBSD server which performs firewall functions in packet filter.

I have been running Opera Unite as a Home Based Web Server for over a week now. I have learned that you can proxy and run software of your own choosing with much success and that it might just be a viable solution if you serve only a few users per day.  

Here are some observations:

• The logs always come from the same IP running the Opera Browser
• Images don't show up in the apache logs since the Opera Unite WebProxy chooses to serve those directly
• Opera Unite seems to startup automatically if the browser is allowed to save the password
• Opera Unite doesn't seem to work with The Onion Router
• There doesn't seem to be great community support on the Opera Unite forums
• You can't place robots.txt or sitemap.xml in the domain root since the Opera Unite Reverse proxy manages that path

Opera Unite still doesn't offer SSL.

I wrote about using a home based web server in a demilitarized zone within your home a few months ago.  This is a fun and useful task to do, but I left out a strong caution.  Your ISP may prohibit you from doing this as part of your contractual agreement.  Your ISP may even go so far as to filter out the HTTP and HTTPS, ports 80 and 443 respectively, to keep you from running your own home based web server.  So, what can you do?

You can use Opera's Unite system or a competitor home server system such as Tonido.  You should pick a system that agrees to provide the service you want so you don't have to wake up one morning finding your site isn't accessible to the world anymore.  

You can find plenty of help with configuring Opera Unite. You can use whatever server you wanted to host your home based web server as your Opera Unite server.

I have found some things with Opera Unite that might be of interest to you.  The URLs can get really long.  Take http://home.azcrumpty.operaunite.com/webserver/content/az/Blog/Blog.html as an example.  This monster URL is configured to use Opera's web server.  The word webserver seems to identify the service I am using.  The word content can be replaced by the word activity for stats.  So two words in the URI are reserved for determining where to retrieve content from.  Finally, your content lies beneath all that in the URL and the path can get really long depending on what you do with your conten.  Opera's built in web server doesn't offer the robust configuration options of Apache or IIS so CGI, plugins, and other functions are nonexistent.

Opera provides you with a reverse proxy to address your web site's complexity needs.  This gives you complete access to your web server software.  But you may find issues with URLs and need to do some URL rewriting. I found both Wordpress and MovableType hard code some paths into the HTML they generate, however, such things were fixable by Googling or hacking the code. Hard coded host names lead to content not showing up. Internal host names showing up is a general problem that has to be considered when using a reverse proxy.  It seems plenty of sites expect the document root to be available for content.  This is not the case when using Opera Unite's Reverse Proxy.  Opera adds the host name to the URL and shifts the document root over to the right by one path.  This becomes and issue with sites that have URIs that reference the document root.  For example, an image reference href="/images/foo.gif" would look like http://home.azcrumpty.operaunite.com/images/foo.gif.  This would fail since the reverse proxy needs the host name in the URL in order to get the image.  The HTML would have to have the reference as href="/wb/images/foo.gif" or be relative as href="images/foo.gif".  You must check and correct all such links for this problem if you didn't write all the HTML yourself.

Performance and security discussions on these services can be found online.  I didn't use performance measurement tools but I watched the images load in on the site and it felt like a dial up modem. This is probably due to the spotty performance I am getting with my ISP right now.  As far as security goes, I would NAT Opera Unite behind pfSense with rules denying access to the internal LAN or I would put the rules on the Opera Unite host itself to minimize the attack possibles should a back door be opened from the Opera browser.  You can also tell your desktop or laptop firewall software to deny all connections from your Opera Unite host. I would only push content to the Opera Unite host that I wanted shared with the world so any unauthorized access to the host would only reveal data I wanted on  the Internet.

I posted my Home Network with DMZ on my blog a few months ago where I listed how I setup a DMZ in my home network. There are so many different ways to do your home network that I could not describe them all; people like short blog posts. I choose this setup for a two main reasons:

1) My pfSense server is a laptop which is very old (purchased in 2000) and I wanted a design that was easy to swap out the laptop should it fail. I can swap the Linksys router into the edge of the network quickly if the pfSense server fails.

2) The laptop has two PCMCIA ports and a network adapter (NIC) fills each port. I could do more with multiple NICs and would have preferred 8 ports on the laptop.  I didn't want to use a USB network adapter because the laptop uses the slow  USB 1.1 interface.

I contemplated doing a double NAT type configuration, pictured left, with the pfSense router at the network edge in the red zone, a network hub in the middle to service the hosts in the DMZ, and the Linksys router connected via its WAN port. The DMZ servers would be in the green zone between the two routers. The inner router would provide firewall and NAT services to the blue zone. I declined this design because there are enough cables, wires, and lost outlets where the equipment goes. I wanted to keep the design simple and I wanted the design to consume less power. Also, some software works poorly when positioned behind two NAT routers.

Lastly, my preferred choice was to use a filtering bridge, pictured below, in place of the Linksys e3000. The filtering bridge would filter the upper portion of the network (.200) as DMZ servers while leaving the lower portion without filtering. The pfSense box only has two NICs so I would have needed an extra machine or a separate hub. Again, this design offers too much complexity for home use.

The first design above allows the user to use an older 802.11b or 802.11g router in the design bypassing using pfSense. It is cheap and easy to setup as many people have their old broadband routers laying around somewhere. The second design requires more effort and more parts when you have only two ports on the filtering bridge. It also requires writing filtering rules and possibly bridging two physical LANs together. The best feature of the bridge is that it eliminates the need for the clients in the green zone to pass through two NATs.