Logical Domains on SunFire T2000 with OpenBSD/sparc64

I've been on a bit of a virtualization kick. This is about OpenBSD, but not vmm.

A couple of years ago, I picked up a Sun Fire T2000. This is a 2U rack mount server. Mine came with four 146GB SAS drives, a 32-core UltraSPARC T1 CPU and 32GB of RAM. Standard hardware includes redundant power supplies, network and serial Advanced Lights Out Management (ALOM), four gigabit ethernet interfaces and a number of USB ports. A number of PCIe and PCI-X slots are available for adding things like RAID controllers, additional network adapters or what-have-you. This system is a decade old, give or take a year or two.

Sun Microsystems incorporated Logical Domains (LDOMs) on this class of hardware. You don't often need 32 threads and 32GB of RAM in a single server. LDOMs are a kind of virtualization technology that's a bit closer to bare metal than vmm, Hyper-V, VirtualBox or even Xen. It works a bit like Xen, though. You can allocate processor, memory, storage and other resources to virtual servers on-board, with a blend of firmware that supports the hardware allocation, and some software in userland (on the so-called primary or control domain, similar to Xen DomU) to control it.

LDOMs are similar to what IBM calls Logical Partitions (LPARs) on its Mainframe and POWER series computers. My day job from 2006-2010 involved working with both of these virtualization technologies, and I've kind of missed it.

While upgrading OpenBSD to 6.1 on my T2000, I decided to delve into LDOM support under OpenBSD. This was pretty easy to do, but let's walk through it. Resources I used:
Once you get comfortable with the fact that there's a little-tiny computer (the ALOM) powered by VXWorks inside that's acting as the management system and console (there's no screen or keyboard/mouse input), Installing OpenBSD on the base server is pretty straightforward. The serial console is an RJ-45 jack, and, yes, the ubiquitous blue-colored serial console cables you find for certain kinds of popular routers will work fine. The networked part of ALOM, if enabled, will probably get a DHCP address and listen for an SSH connection. "admin/changeme" is the default. Resetting it isn't too hard, if you need to. The Internet can help you if you know how to search.

If you have seven minutes to spare to watch the ALOM and the T2000 itself boot up, watch the below video. Put on your earplugs (not your headphones), because this sucker is *loud*. Otherwise, just skip past it.

If there isn't an operating system on the box, the "ok" prompt should show up in the console eventually. If there is an operating system, you can use the "break" command to get to "ok". From there, cd booting is as easy as:
setenv boot-device cdrom
OpenBSD installs quite easily, with the same installer you find on amd64 and i386. I chose to install to /dev/sd0, the first SAS drive only, leaving the others unused. It's possible to set them up in a hardware RAID configuration using tools available only under Solaris, or use softraid(4) on OpenBSD, but I didn't do this.

Enable ldomd:
doas rcctl enable ldomd

I set up the primary LDOM to use the first ethernet port, em0. I decided I wanted to bridge the logical domains to the second ethernet port. You could also use a bridge and vether interface, with pf and dhcpd to create a NAT environment, similar to how I networked the vmm(4) systems.

Cable the second ethernet port to the desired network segment. I'm assuming you got the first ethernet port configured by now. This second port doesn't need its own IP address from the primary LDOM. Configure it by putting this in /etc/hostname.em1:
While you're at it, put those same two lines in /etc/hostname.vnet0. Create additional hostname.vnetN files for as many LDOMs as you plan to set up.

Create a bridge interface configuration with this chunk of text in /etc/hostname.bridge0. Add the rest of your vnet interfaces if you made more than one.
add em1
add vnet0
Fetch the sparc64 minirootXX.fs file from an OpenBSD mirror. Make a blank 4GB disk image for the VM, then write the miniroot to the beginning of it. This will be the easiest way to boot to the OpenBSD installer inside the VM console.

mkdir ~/vm
dd if=/dev/zero of=~/vm/ldom1 bs=1m count=4000 
dd if=miniroot61.fs of=~/vm/ldom1 bs=64k conv=notrunc
Create an LDOM configuration file. You can put this anywhere that's convenient. All of this stuff was in a "vm" subdirectory of my home. I called it ldom.conf:
domain primary {
    vcpu 8
    memory 8G
domain puffy {
    vcpu 8
    memory 4G
    vdisk "/home/axon/vm/ldom1"

Make as many disk images as you want, and make as many additional domain clauses as you wish. Be mindful of system resources. I couldn't actually allocate a full 32GB of RAM across all the LDOMs. I ended up allocating 31.

We're going to dump the factory default LDOM configuration (that is, everything assigned to the primary LDOM, with no actual VMs). We need to copy this as a template, so that we can modify it and send it back to the firmware, telling it to re-allocate hardware assets to an LDOM.

# dump the factory
mkdir ~/vm/default 
cd ~/vm/default 
doas ldomctl dump 

# copy the configuration to the "myldom" directory
cd .. 
cp -r default myldom
cd myldom

# Modify the configuration using the ldom.conf we created
doas ldomctl init-system ~/vm/ldom.conf

# Push ("download") the new "myldom" configuration to the system controller.
cd ..
doas ldomctl download myldom

At this point, you can list the configurations and see that your new one will boot next.

$ doas ldomctl list
factory-default [current]
myldom [next]

Halt the system.
doas halt

Exit the console with "#." and at the system controller prompt, run "reset -c"

Once the system boots up and you log in, check out the running LDOMS.

$ doas ldomctl status
primary           running           OpenBSD running                     0%
ldom1              running           OpenBSD running                     0%

Connect to the console of ldom1 (ttyV0). Additional LDOMs will have consoles at ttyV1, ttyV2, etc. Voila. OpenBSD installer! Assuming your network configuration and cabling is right, it will show up as a machine directly on the LAN.

$ doas cu -l ttyV0
Connected to /dev/ttyV0 (speed 9600)

(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? I
At any prompt except password prompts you can escape to a shell by
typing '!'. Default answers are shown in []'s and are selected by
pressing RETURN.  You can exit this program at any time by pressing
Control-C, but this can leave your system in an inconsistent state.

System hostname? (short form, e.g. 'foo')

I eventually provisioned seven LDOMs (in addition to the primary) on the T2000, each with 3GB of RAM and 4 vcpu cores. If you get creative with use of network interfaces, virtual ethernet, bridges and pf rules, you can run a pretty complex environment on a single chassis, with services that are only exposed to other VMs, a DMZ segment, and the internal LAN.

If, like me, you end up with an unbootable LDOM configuration, you can always revert back to the factory default, or switch between stored configurations from the system controller. At the sc> prompt, use:

bootmode config="factory-default"
reset -c

Any configuration that you've downloaded to the controller can be used. They will show up by name in the "ldomctl list" command.


OpenBSD vmm hypervisor: Part 2

This is going to be a (likely long-running, infrequently-appended) series of posts as I poke around in vmm.  A few months ago, I demonstrated some basic use of the vmm hypervisor as it existed in OpenBSD 6.0-CURRENT around late October, 2016. We'll call that video Part 1.

As good as the OpenBSD documentation is (and vmm/vmd/vmctl are no exception) I had to do a lot of fumbling around, and asking on the misc@ mailing list to really get to the point where I understand this stuff as well as I do. These are my notes so far.

Quite a bit of development was done on vmm before 6.1-RELEASE, and it's worth noting that some new features made their way in. Work continues, of course, and I can only imagine the hypervisor technology will mature plenty for the next release. As it stands, this is the first release of OpenBSD with a native hypervisor shipped in the base install, and that's exciting news in and of itself. In this article, we assume a few things:

  1. You are using OpenBSD 6.1-RELEASE or -STABLE (I'll likely start exploring -CURRENT again in a month or two)
  2. You're running the amd64 architecture version of OpenBSD
  3. The system has an Intel CPU with a microarchitecture from the Nehalem family, or newer. (e.g. Westmere, Sandy Bridge, Ivy Bridge). Basically, if you've got an i5 or i7, you should be good to go.
  4. Your user-level account can perform actions as root via doas. See the man page for doas.conf(5) for details.
 Notes on formatting:
  1. Lines in blue are text inside configuration files.
  2. Lines in green are shell commands to be executed on the command line.

Basic network setup

To get our virtual machines onto the network, we have to spend some time setting up a virtual ethernet interface. We'll run a DHCP server on that, and it'll be the default route for our virtual machines. We'll keep all the VMs on a private network segment, and use NAT to allow them to get to the network. There is a way to directly bridge VMs to the network in some situations, but I won't be covering that today. (Hint: If you bridge to an interface with dhclient running in the host OS, no DHCP packets will reach the VMs, so it's best to static-assign your VM host's LAN port. or use a different interface entirely.)

Enable IP forwarding in sysctl. Add the following to /etc/sysctl.conf:


You can reboot to enable these, or run these commands manually:

doas sysctl net.inet.ip.forwarding=1
doas sysctl net.inet6.ip6.forwarding=1

We're going to be using "vether0" as the VM interface, and in my current configuration, "athn0" as the external interface. The below block of pf configuration was taken partially from /etc/example/pf.conf and some of the PF NAT example from the OpenBSD FAQ. Change your ext_if as needed, and save this as /etc/pf.conf:


set skip on lo

block return

match out on $ext_if inet from $vmd_if:network to any nat-to ($ext_if)

Next, you'll need to specify an IP and subnet for vether0. I am going with (and a netmask for a /24 network) in my example. Place something like this in /etc/hostname.vether0:


Bring vether0 online by running the following command:

doas sh /etc/netstart vether0

Reload the pf configuration (h/t to voutilad for the heads up in the comments about moving this step down a few spots):

doas pfctl -f /etc/pf.conf

Create a basic DHCP server configuration file that matches the vether0 configuration. I've specified as the default DHCP pool range, and set as the default route. Save this in /etc/dhcpd.conf:

option  domain-name "vmm.openbsd.local";
option  domain-name-servers,;

subnet netmask {
        option routers;



Configure a switch for vmm, so the VMs have connectivity. Put the following in /etc/vm.conf:

switch "local" {
        add vether0

Enable and start the DHCP server. We also need to set the flags on dhcpd so that it only listens on vether0. Otherwise, you'll end up with a rogue DHCP server on your primary network. Your network administrators and other users on your network will not appreciate this because it could potentially keep others from getting on the network properly.

doas rcctl enable dhcpd
doas rcctl set dhcpd flags vether0
doas rcctl start dhcpd

Enable vmd, then start it as well. For good measure, re-run fw_update to make sure you have the proper vmm-bios package.

doas rcctl enable vmd
doas rcctl start vmd
doas fw_update

You should notice a new interface, likely named "bridge0" in ifconfig now.

VM Creation and installation

Create an empty disk image for your new VM. I'd recommend 1.5GB to play with at first. You can do this without doas or root if you want your user account to be able to start the VM later. I made a "vmm" directory inside my home directory to store VM disk images in. You might have a different partition you wish to store these large files in. Adjust as needed.

mkdir ~/vmm
vmctl create ~/vmm/test.img -s 1500M

Boot up a brand new vm instance. You'll have to do this as root or with doas. You can download a -CURRENT install kernel/ramdisk (bsd.rd) from an OpenBSD mirror, or you can simply use the one that's on your existing system (/bsd.rd) like I'll do here.

The below command will start a VM named "test.vm", display the console at startup, use /bsd.rd (from our host environment) as the boot image, allocate 256MB of memory, attach the first network interface to the switch called "local" we defined earlier in /etc/vm.conf, and use the test image we just created as the first disk drive. 

doas vmctl start "test.vm" -c -b /bsd.rd -m 256M -n "local" -d ~/vmm/test.img

You should see the boot message log followed by the OpenBSD installer. Enter "I" at the prompt to install OpenBSD. I won't walk through how to install OpenBSD. If you've gotten this far, you've done this at least once before. I can say that the vm console works by emulating a serial port, so you should leave these values at their defaults (just press enter):
Change the default console to com0? [yes]
Available speeds are: 9600 19200 38400 57600 115200.
Which speed should com0 use? (or 'done') [9600]
You will also likely need to install packages without a prefetch area. Answer yes to this.
Cannot determine prefetch area. Continue without verification? [no] yes
After installation and before rebooting, I'd recommend taking note of the vio0 interface's generated MAC address (lladdr) so you can specify a static lease in dhcpd later. If you don't specify one, it seems to randomize the last few bytes of the address.
CONGRATULATIONS! Your OpenBSD install has been successfully completed!
To boot the new system, enter 'reboot' at the command prompt.
When you login to your new system the first time, please read your mail
using the 'mail' command.

# ifconfig vio0                                                               
vio0: flags=8b43 mtu 1500
        lladdr fe:e1:bb:d1:23:c4
        llprio 3
        groups: dhcp egress
        media: Ethernet autoselect
        status: active
        inet netmask 0xffffff00 broadcast
Shut down the vm with "halt -p" and then press enter a few extra times. Enter the characters "~." (tilde period) to exit the VM console. Show the VM status, and stop the VM. I've been starting and stopping VMs all morning, so your VM ID will probably be 1 instead of 13.
# halt -p

(I hit ~. here...)
$ vmctl status
   13 96542     1    256M   52.6M   ttyp3         root test.vm
$ doas vmctl stop 13
vmctl: terminated vm 13 successfully

VM Configuration

Now that the VM disk image file has a full installation of OpenBSD on it, build a VM configuration around it by adding the below block of configuration (with modifications as needed for owner, path and lladdr) to /etc/vm.conf.

# H-i-R.net Test VM
vm "test.vm" {
        owner axon
        memory 256M
        disk "/home/axon/vmm/test.img"
        interface {
                switch "local"
                lladdr fe:e1:bb:d1:23:c4

I've noticed that VMs with much less than 256MB of RAM allocated tend to be a little unstable for me. You'll also note that in the "interface" clause, I hard-coded the lladdr that was generated for it earlier. By specifying "disable" in vm.conf, the VM will show up in a stopped state that the owner of the VM (that's you!) can manually start without root access.

Go ahead and reload the VM configuration with "doas vmctl reload", then look at the status again.
$ doas vmctl reload
$ vmctl status

    -     -     1    256M       -       -         axon test.vm

DHCP Reservation (Optional)

I opted to set up a DHCP reservation for my VM so that I had a single IP address I knew I could SSH to from my VM host. This, to me, seems easier than using the VM console for everything.

Add this clause (again, modified to match the MAC address you noted earlier) to /etc/dhcpd.conf. You have to place this above the last curly-brace.

        host static-client {
                hardware ethernet fe:e1:bb:d1:23:c4;

Restart dhcpd.

doas rcctl restart dhcpd

Go ahead and fire up the VM, and attach to the console.

vmctl start test.vm -c

You'll see the seabios messages, the boot> prompt, and eventually, all the kernel messages and the login console. Log in and have a look around. You're in a VM! Make sure the interface got the IP address you expected. Ping some stuff and make sure NAT works.
$ ifconfig vio0
vio0: flags=8b43 mtu 1500
        lladdr fe:e1:bb:d1:23:c4
        index 1 priority 0 llprio 3
        groups: egress
        media: Ethernet autoselect
        status: active
        inet netmask 0xffffff00 broadcast
$ ping -c4
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=54 time=9.166 ms
64 bytes from icmp_seq=1 ttl=54 time=7.295 ms
64 bytes from icmp_seq=2 ttl=54 time=9.178 ms
64 bytes from icmp_seq=3 ttl=54 time=25.935 ms

--- ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.295/12.893/25.935/7.568 ms

Again, you can use <enter>~. to exit the VM console. You probably want to log off before you do that.  Go ahead and SSH in as well.

$ ssh axon@
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:f39GrAZouHQ3L+3/Qy3FHBma5K+eOe84B9QoFwqNpXo.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
axon@'s password:
Last login: Sat Apr 29 14:21:54 2017
OpenBSD 6.1 (GENERIC) #19: Sat Apr  1 13:42:46 MDT 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.


Forward ports through the NAT (optional)

One last thing I did was to port-forward SSH and HTTP (on high ports) to my VM so that I could get to the VM from anywhere on my home network.

Add these lines to /etc/pf.conf directly under the vmd NAT rule we added earlier.

pass in on $ext_if proto tcp from any to any port 2200 rdr-to port 22
pass in on $ext_if proto tcp from any to any port 8000 rdr-to port 80

Reload the pf configuration

doas pfctl -f /etc/pf.conf

You should now be able to ssh to port 2200 on your host VM's IP. Obviously, browsing to port 8000 won't work until you've set up a web server on your VM, but this was how I started out when working on the PHP/MySQL guides.


PHP/MySQL Walk-Throughs updated for OpenBSD 6.1

I've stopped maintaining the page for nginx because it hasn't received many views since I updated it about six months ago. I suspect that nginx on OpenBSD is not all that popular because the httpd that ships with OpenBSD provides almost the same functionality as a basic installation of nginx. The pages for httpd in base and Apache2 now cover PHP7 and both configurations appear to work really well.  

PHP/MySQL on OpenBSD's relayd-based httpd 
HiR's Secure OpenBSD/Apache/MySQL/PHP Guide

Feel free to comment on this post if you find any discrepancies or have suggestions. Comments are disabled on the walk-through pages.

(2017-04-23) Edited to add: I went ahead and re-worked the nginx guide, based on the httpd guide with new formatting.
PHP/MySQL with nginx on OpenBSD


OpenBSD 6.1 Released

I just saw a subtle hint from beck@ that OpenBSD 6.1 is live on the mirrors. Judging from the timestamps on the files,  it looks like the OpenBSD developers stealthily dropped 6.1-Release onto their FTP servers on April Fool's day and didn't tell anyone...

Go get it.

Edited to add: The OpenBSD 6.1 release page has been changed. It's official.


Introducing wiconn: A text-based 802.11 wireless network manager for OpenBSD

When I switched back to OpenBSD as my primary daily-use operating system back in 2011, my biggest complaint was the lack of an easy-to-use tool for managing wireless networks. I only used maybe two or three different wireless networks daily. I just used a few shell scripts that statically configured the network card for each of these environments. Any time I'd go somewhere else, though, it would be a pain to manually configure it.

Almost exactly five years ago, I did something about it, and I called it wiconn.sh. Since I already had one-off scripts for my home and office networks, Wiconn started as a script to display open networks. It would display only the open ones, and prompt me for an SSID, and it could remember the BSSID (MAC Addresses) of open networks I used to protect me from things like my own Evil WiFi setup and other "evil twin" style wireless attacks.
That first version looked something like this:

Wiconn evolved over time. By late 2012, I'd given it a bunch of features and made the interface look nicer. All SSIDs were being listed with color-coded backgrounds for the network you're connected to, and open networks. Visually, it hasn't changed much since 2012. This is how Wiconn looks today:

Over this long holiday weekend, I finally got it to a place where I feel like sharing it. Since it's already in the garage for maintenance, I figured I might as well put wiconn on GitHub.

  • Written primarily in Bourne shell (/bin/sh)
  • No dependencies: Relies only on the OpenBSD base distribution
  • Built-in protection from common wireless attacks
  • Easily connect to saved networks with one command (no scanning or prompt)
  • 2-Clause Simplified BSD license
There's still some more work to do.  I'd like to have it detect that one of your saved networks is in the list and ask if you'd like to join it. I'm also using NetBSD a bit more, and feel like there might be a way to make it work well on both OpenBSD and NetBSD from the same codebase, despite small differences in command syntax and output format between them.

Anyhow, for the growing number of folks who are giving OpenBSD a shot lately, I thought I'd share. Feedback is welcome, and more information is available through the documentation via GitHub.

n0xa/wiconn on GitHub


OpenBSD vmm guided tour; PHP/MySQL walk-throughs updated

Thursday night, I recorded a video while tinkering with vmm. I covered some basics of using it, networking, and installing OpenBSD inside a freshly-created VM. Sorry for the stammering and poor audio quality. Of course, the real fun was figuring out how to get it transcoded into webm and uploaded to youtube from within OpenBSD. I learned a lot about ffmpeg this week. Enjoy.

FYI, I used these same VMs to help me update and test the nginx and httpd PHP/MySQL articles. They're (finally) up-to-date for OpenBSD 6.0. Better late than never, right?


Iodine DNS Tunneling

I first wrote about DNS Tunnelling back in 2010. Even back then, commodity tools to facilitate it were at least five years old. I covered OzymanDNS, DNS2TCP,Heyoka, and DNSCAT in 2010.

A few years ago, I was introduced to Iodine, and it's been my go-to tool for DNS tunnelling ever since, frequently with great success. Iodine has several different modes, and will try various query types, packet sizes and timing parameters, usually making the connection as reliable as it can be. Without any adjustments, it doesn't try to be stealthy, but if you dig into the manual client options and you know what your adversary is looking for (e.g. Snort/Suricata rules, Bro, FQDN length, volume of queries, etc.) you might be able to get Iodine to fly below the radar.

Just like the very first articles I wrote, the technique requires you to set up a sub-domain with a name server. Here, I set up a subdomain for *.t.h-i-r.net, and I've assigned it a name server of tn.h-i-r.net. I had to specify an A record for it: the IP address of a VPS I'm leasing (which also hosts much of HiR's presence aside from this blog). You could easily point it to your home IP address -- so long as you can NAT port 53 UDP to it.

I'm using Google Domains for this, but almost any DNS control panel should let you define NS records for subdomains and A records for hosts similar to how it shows up above. Previously, I'd demonstrated using GoDaddy and ZoneEdit DNS control panels.

Once you have established these DNS configuration entries, and made sure that UDP traffic can get to port 53 on the tunnel server, you should be ready to get Iodine installed. Most GNU/Linux and BSD flavors I've used lately have Iodine in the package repository. That includes OpenBSD, Arch Linux, Kali, and Ubuntu. If you're using Mac OS X, there's a Homebrew recipe that seemed to work last time I tried.  The Iodine page has Windows and Android binaries available for download. I have not yet tried them.

You probably want to leave the iodine server (iodined) running on your tunnel server at all times, so that it's ready when you need to use it. Since iodine uses a privileged port and creates TUN/TAP interfaces, you need to run it as root. At a minimum, to start the Iodine server, you need to specify a password, a network (in CIDR notation) to allocate for the tunnel, and the subdomain you configured above. I'm using a pretty small network mask (/29) which allocates only five client IP addresses. As I'm the only one using this tunnel server, this is fine. It might even be overkill.

# iodined -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Opened IPv4 UDP socket
Limiting to 5 simultaneous users because of netmask /29
Listening to dns for domain t.h-i-r.net
Detaching from terminal...

On the client machine, it's assumed that you can connect to a network, but unrestricted Internet access isn't working. In my example, I'm on a somewhat restricted hospital Wi-Fi network that isn't allowing SSH, and has restrictions on what one can browse on the web. Most of my favorites are being blocked because they're "hacking" related.

Ideally, a recursing DNS server is available. As long as you can see the NS record you set up, there's a pretty good chance Iodine will work. The client also needs to run as root (or via sudo) and the bare minimum configuration requires a password and the subdomain.

$ host -t ns t.h-i-r.net
t.h-i-r.net name server ns.t.h-i-r.net.

$ sudo iodine -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Opened IPv4 UDP socket
Sending DNS queries for t.h-i-r.net to
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Server tunnel IP is
Testing raw UDP data to the server (skip with -r)
Server is at, trying raw login: OK
Sending raw traffic directly to
Connection setup complete, transmitting data.
Detaching from terminal...

Once you have the connection established, the remote end should be reachable via the "Server tunnel IP" shown in the output. In this case, that's Typically, this is where I set up a Dynamic proxy with ssh.

$ ssh -D 1080
Last login: Thu Oct 20 17:44:19 2016 from
OpenBSD 6.0 (GENERIC.MP) #0: Fri Sep  2 16:10:46 CEST 2016


Back in the real world, I set Firefox proxy settings up to use localhost at port 1080, and enabled remote DNS. Configuring the proxy in other browsers may vary. You may even have a system-wide SOCKS proxy setting.

Firefox now can browse through this SSH session, which is tunnelling over DNS.

Back on the tunnelled SSH session, I used the ~# SSH escape command to list open tunnel connections. This will verify that you are browsing through the tunnel.

The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
  #3 direct-tcpip: listening port 1080 for www.h-i-r.net port 80, connect from port 16128 to port 1080 (t4 r1 i0/0 o0/0 fd 9/9 cc -1)
  #4 direct-tcpip: listening port 1080 for www.blogger.com port 443, connect from port 25392 to port 1080 (t4 r2 i0/0 o0/0 fd 10/10 cc -1)
  #5 direct-tcpip: listening port 1080 for apis.google.com port 443, connect from port 46746 to port 1080 (t4 r3 i0/0 o0/0 fd 11/11 cc -1)

It's hard to see here, but I grabbed a Wireshark screen shot of Iodine in action a few weeks ago. The heartbeat packets are all pretty short. They can get quite large when the time comes to send a lot of data. Here, Iodine has chosen to use NULL records.