Tag Archives: OpenBSD

Fun with TomatoUSB and OpenBSD

Posted by on 12/29/2011 2 comments

With family visiting and a steady stream of folks around the house needing Wifi access, I decided it was about time to finally set up a properly segregated guest SSID to both rate limit and protect my internal hosts from potentially insecure guest devices. As usually happens to me with such projects, I went a bit overboard and ended up with something much more complex but way more fun to manage.

TomatoUSB already has support for multiple SSID configurations, tho it’s considered experimental and doesn’t have full gui support. You’ll also need to either build yourself or use a community build to get the full goodness. I chose Toastman’s builds since it also includes full VLAN support and he’s very active in the community. Installing the latest on my RT-N16 was easy enough and a quick ‘nvram wipe’ gave me a nice clean base to work with. Getting the extra SSID was pretty painless, added the extra vlan and bridge then ssh’d into the router, ran the relevant nvram commands and voila! This is prolly where I should have left it, but in doing my digging I came across this post which details using OpenWRT to create a trunk port carrying all vlans to the OpenBSD router.

Why trunk you may ask? Short answer – because it’s fun. Long answer – single connection required to carry all routable traffic to my OpenBSD box where I can restrict, rate shape, etc. to my heart’s content. Setup here was dead easy, the NIC I was using for my internal network supports 802.1Q so all I had to do was some point and click goodness to tag all three vlans (internal, WAN, wireless guest) into port four on the RT-16N:

I also set the WAN port type to ‘Disabled’ in the basic network config page so the RT-16N wouldn’t try and get an external IP.

Once all that was done, I removed all ip configuration from my internal nic on the router and created the various vlan interfaces:

ifconfig vlan3 create
ifconfig vlan3 vlan 3 vlandev xl0
ifconfig vlan3 xxx.xxx.xx.x netmask 255.255.255.0 up

A quick tcpdump showed the right kinds of packets flowing across the new vlan interface, so I created the others (vlan1, vlan2) and then updated the various hostname.* files to reflect the new configs.
hostname.xl0 (interface just needs to be enabled):

up

hostname.vlan1 (static ip):

inet xxx.xxx.xx.x 255.255.255.0 NONE vlan 1 vlandev xl0 description "Interface in trusted VLAN (1)"
inet6 alias xxxx:xxx:x:xxx::1 64

hostname.vlan2 (dynamic, used for ISP):

dhcp NONE vlan 2 vlandev xl0 description "Interface in external VLAN (2)"

hostname.vlan3 (static ip, wireless guest subnet):

inet xxx.xxx.xx.x 255.255.255.0 NONE vlan 3 vlandev xl0 description "Interface in wireless guest VLAN (3)"

Yea, this is prolly way more complex than it should be for a home network, but the ability to do proper segregation of various traffic types is a big win in my opinion. The only downside I’ve encountered so far is with rate limiting as a whole. Since PF’s QOS is tied to individual interfaces, I can’t just pool all vlans together and have it shape that way. There’s prolly some way of doing it using static routes or even some virtual device, but I haven’t found it yet. For now I’m just aggressively limiting the bandwidth available to my guest network, but if anyone knows of a better way I’d be grateful for some pointers.

Transparent proxy

Posted by on 6/4/2006 No comments

I’ve been wanting to setup a transparent proxy on my home network, but haven’t been able to because Squid isn’t running on my router. All the hacks I’d been able to find rely on some really dark routing/firewall rules that caused all sorts of problems.

Came across tproxy the other day and it’s solved all my issues. I set it up on my OpenBSD router, used pf rules to route http traffic from clients to tproxy and it handles the rest. For the record, here’s the relevant lines from my pf.conf:

table <internal_clients> persist { INTERNAL_IP_BLOCK !SQUID_HOST }
rdr on {INTERNAL_INTERFACES} proto tcp from <internal_clients> to any port www -> 127.0.0.1 port 81

I have tproxy starting at boot using:

if [ -x /usr/local/sbin/tproxy ]; then
echo -n ‘ tproxy’; /usr/local/sbin/tproxy -s 81 -b 127.0.0.1 SQUID_HOST SQUID_PORT
fi

[tags]OpenBSD,tproxy,Squid,Transparent Proxy,pf[/tags]

Life, Gnome and OpenVPN

Posted by on 1/26/2006 No comments

It’s been quite a while since I posted last, and a lot has been going on. On the life front, I’ve been going through a month-long interview process for a really good job. My first phone interview was about a week or two before Christmas, had another phone interview a few weeks later (on my birthday no less). We scheduled an in-person interview for the following monday and they’ve been in decision mode since. I should find out for sure by the end of the month but, since the job would involve moving at short notice, it’s put a bit of stress on the family.

We’ve been shaking out the last few bugs with our new lab image at work. We are gonna be scrapping the old dual-boot setup in favor of Linux with VMPlayer for other OS’s. If only there was a way to grab the $HOME variable to setup shared folders, I’d be in heaven… ;)

One of the cooler things I’ve done lately was to setup OpenVPN to bridge my vpn’d clients with the wired network. I came across an excellent how-to and was able to follow that almost to the t, but I did have to add the tap devices to my list of trusted devices instead of the bridge. Funny how it’s the little differences in platforms can get ya…

A cool bonus to the bridging setup is multicasting. Setting up mt-daapd and watching all my music appear in Rhythmbox automagically was just damn nice (screenie). I’m using Avahi for my mDNS implementation and can also see my published ssh/sftp hosts in Nautilus…

Gnome released 2.13.5 last week, and I’ve been working on the release for BMG ever since it seems. Several packages have moved to the new GStreamer and still others need the new HAL. That plus new notify stack have kept a pretty steady stream of bugs and fixes (yay!) coming thru our bugtracker. I’ve been trying to keep up, but there’s been quite a bit of involvement from folks on the testing side so I’m still a bit behind. It’s been rather nice tho to have wider testing from folks willing to submit good reports and even quite a few patches. If you’re reading this on the BMG site, please keep those reports coming and I promise I’ll keep plugging along on em… ;)

Switch to our mobile site