Port Forwarding Fun

Now that I'm spending a fair amount of time writing and testing our new Client Simulator Super Flows, I often find myself with a need for rapid deployment of services to test against. Normally, this is no problem; we have a VMWare server dedicated to Client Simulator development testing hooked up to our BreakingPoint Elite, and the image runs a friendly stock Ubuntu Server.

This week, I started in on ironing out our new Microsoft SQL Cient Simulator, and as great a product as Microsoft SQL Server is, it sadly doesn't install on Linux very well, and since I'm uncannily lazy, I didn't want to go through the hour or two of building out another VMWare image.

Lucky for me, Kirby Kuehl had already installed MSSQL on his own test server (running QEMU) in case we needed any Network Processor magic to make the MSSQL Client Simulator work correctly.

So, I have this VMWare server sitting over here, and a QEMU guest OS sitting over there, in a different network. "No problem," says I, "I'll just set up some port forwarding love!"

Up until now, whenever I have a need to forward network ports around, I default to using ssh tunnels. But in this case, I really wanted the traffic to be cleartext all along the way since I hadn't decided yet where exactly I'd be sniffing the traffic to verify my implementation. Netcat is a fine cleartext alternative for ad-hoc forwarding, but I got it in my head that I wanted a more "real" service running on my VMWare instance.

Since I had already tested out the diagnostic services using this same host -- Chargen, Echo, Daytime, etc -- I had the venerable xinetd installed to run these basic protocols. Somehow, in my many networking adventures, I had forgotten how powerful xinetd can be. Turns out, with an edit to /etc/services (adding 'externsql' as the name for 1433/tcp), adding "kirbys-target" to /etc/hosts, and an entry under /etc/xinetd.d like so...

# default:on
# description: forward various sql services. In this case, 
various is only one.

service externsql
{
	disable = no
	flags = REUSE
	socket_type = stream
	wait = no
	user = root
	redirect = kirbys-target 1433
}

...I'm able to forward my VMWare guest's 1433/tcp traffic across to Kirby's QEMU machine. Xinet.d also features some pretty easy access control configuration and logging (see Jose Nazario's ancient LinuxJournal article on the subject), so if you're in a more hostile network, that might work out for you.

Once that step was out of the way, I noticed that the bridged interface of Kirby's machine was out of whack (it wasn't set to come up on boot), so I couldn't talk to it directly from my VMWare image. Again, I'd like to reference my supreme sloth: instead of proper troubleshooting with brctl, another xinetd redirect (from the QEMU host to the QEMU guest) had me up and running, shuttling MSSQL packets between the BreakingPoint Elite and the far-off SQL Server.

Now that I'm wrapping up my Client Simulator development (look for it in a StrikePack in the near future), it struck me funny that I had so many layers of redirection in order to test traffic. So funny, in fact, I put together this network cartoon so I could share the hilarity with you.

If you're going to be performing any serious level of performance testing, I probably wouldn't recommend such a labyrinthine setup; QEMU and VMWare both can get a little pokey under load, and while xinetd is pretty lightweight, all those stops along the way are adding friction to your ridiculously fast testing gear. But, in the case of functional R&D, this set up is ideal, if a little silly; I'm never going to recable our test Elite again.