questions/comments send us feedback
Welcome !
Linux Resources  OpenBSD Resources  Security Resources  General Information 
Oct. 22, 2017

main | openbsd :: how-to :: invisible_firewall

Invisible Firewalling How-To

Memoirs of an Invisible Firewall

Main Page

Memoirs of an Invisible Firewall

In the stone age of firewalling, a firewall was a fairly complicated device that was less-than-trivial to factor into your network. It needed an IP address on it's outside, and another on the inside. This immediately created subnetting problems, forcing wasted IP allocation and overall disquietude amongst the cognoscenti. It also meant that your firewall was very visible to the world, and its function was rather obvious and easy to deduce. There had to be a better way. And now there is...

Dream with me for a moment: A black box, shimmering in the soft LED-green glow of the network cabinet. You take the network cable from your router, which previously went into a switch, and stick it in one of the snappy plugs in the back of the box. There's one more plug on the black box, so you grab another cable and hook the box up to the switch. You step back, and suddenly: everything looks the same. You go to all your computers. As far as you can tell from inside and outside the network, the box doesn't exist. It does nothing. A few minutes later, you have a monitor and keyboard hooked up to the back of the box. You quickly and easily begin to tweak a file that gives you fine grained control over access to your network. You shut off all access to your mailserver from the outside world except on port 25.

Back to the testing bench -- once again, you can't find any indication that this box exists. From inside the network, everything works fine. But inexplicably, your mailserver simply is unreachable on any port other that 25. There's simply no response... in fact, your packets seem to vanish into the ether.

You're experiencing the power and ease of a transparent bridging firewall. It doesn't require any reconfiguration of your network (other than pluging it between your router and your network) yet allows you to completely control network access with the full power of the IPFilter firewalling system. And the best part? The firewall is invisible and inaccessible from anywhere other than the console. This means a hacker can't possibly break into your firewall. It just doesn't exist.

How does this box get built? Well here's a hint: under OpenBSD it is relatively easy to bridge two network interface cards together. What does this mean? It means that every packet that appears on one card will be sent to the other. It essentially turns your computer into a $.50 piece of connecting cable ... with one key difference: as the packets move from one card to another, the computer can inspect and filter them.

So how does this give us the black box? To start, you can now use the firewalling abilities of OpenBSD (the excellent IPFilter package) to control the dataflow between the interfaces. But the great part about a bridge is that it doesn't need IP addresses. The interfaces are "promiscuous", so to speak. They just grab every packet they see on the wire, regardless of where it's going, and send it across to the other side. Combine these two great tastes that go great together and you've got a kickass network prophylactic.

Setting up the system

You'll want to do a bare-bones install of OpenBSD, as discussed on this site in the OpenBSD installation guide. Don't worry about configuring the network, unless you plan on upgrading/patching various stuff from the Net. If you do config the network, just config one interface temporarily so that you can get to the external files. Eventually you'll be wiping this config, so don't sweat it.

Setting the config files

There's a few changes you need to make to the two main system config files: /etc/sysctl.conf and /etc/rc.conf.


uncomment the line beginning with:

#net.inet.ip.forwarding=1 --> net.inet.ip.forwarding=1

if you're using IPv6 already, you might want to uncomment the following line, which enables IPv6 forwarding.

#net.inet6.ip6.forwarding=1 --> net.inet6.ip6.forwarding=1


change the following lines from NO to YES:

ipfilter=NO  -->  ipfilter=YES
ipnat=NO     -->  ipnat=YES
Reboot to activate the changes.

Activating the bridge

First let's make sure your network is in a state that we can work with. Execute the following commands. Damn the torpedoes and ignore any error messages.

ifconfig dc0 delete
ifconfig dc1 delete
ifconfig dc0 up
ifconfig dc1 up
This gets rid of any prior configuration of your interfaces and just sets them both to UP, with nothing else configured. This way an old IP address setting doesn't cause a mysterious conflict later.

Now let's add the interfaces to the bridge:

brconfig bridge0 add dc0 add dc1 up
Guess what? You're bridging... that's all there is to it! Of course, now the fun part: testing to make sure this actually works.

To test your config, you'll need two machines and two crossover cables. Using the crossover cables, hook the machines up to dc0 and dc1. Give each machine a different IP address in the same subnet, for example dc0 gets a machine with, and dc1 gets Can you ping from one to the other? Theoretically, you should be able to do this, if all went well. If not, check your cables -- the indicator lights on all the network cards should be lit. Other sources of errors: the configuration on the test machines... make sure they can talk to one another without the bridge (just connect the two of them together with a crossover cable -- one should be able to ping the other... if they can do this, the problem is with your bridge). If that fails, run a TCP dump:

tcpdump -i dc0 -l
and then:
tcpdump -i dc1 -l
This will show you want packets are arriving on the dc0 and dc1 interfaces, respectively. You can use this to help figure out where the problem is. If you've played with the ipf.rules file at all, you should do an ipf -Fa to flush the rules to the pass-all state. Any rules at this point could cause problems.

Now let's test the firewalling abilities. Create a quick ipf.rules file that says:


block in on dc0 all
block in on dc1 all
now do:

ipf -Fa -vf /etc/ipf.rules
and try pinging again. Should be dead. If so, good. Otherwise, refer to the online firewall installation and configuration guides found on this site to help troubleshoot the problem.

Making your bridge permanent

In order to keep your bridge through reboots, you'll need to change a few more files. Each of these three files should have just one line:






add dc0 add dc1 up

/etc/mygate should be empty. /etc/myname should be a name for the bridge that you find particularly apropos... some popular suggestions: london, brooklyn, rubber, notrump, nosebump, etc.


This is the easy part -- just add rules to the ipf.rules file. You can follow any of the sample rule set instructions found on this site -- although the set for "Highest Security" will be particularly applicable.

Some key gotchas:

  • Bridging under OpenBSD has a constraint: filter rules only work for the "in" direction. A "block out" statement will have no effect. Of course, you can accomplish almost anything you'd want to do with an outbound rule with an equivalent inbound rule on the opposite interface. For example:

          pass out on dc0 proto tcp/udp all keep state
    is one way to ensure that connections initiated from the inside are allowed back in through a firewall that blocks all connections from the outside. This particular rule won't work in your bridge -- it can't handle the "out". But this rule could equally be written as:

          pass in on dc1 proto tcp/udp all keep state
    Now we're catching the same packet, moving from internal to external network... except instead of catching it as it leaves for the big, dangerous unknown on the external interface (after passing through the filters), we bag it/tag it as it first goes into the bridge on the internal interface. Easy, eh?

  • Remember -- this machine has NO IP address, so it can't be reached from anywhere other than the console. Test ALL of your rules thoroughly before officially activating this thing and leaving for the week. This also means you can't reach any other machines from the bridge -- so don't freak when "ping" or "telnet" fails to connect with a machine that's directly connected to the bridge. Regardless of the direct connection, nothing will be able to talk with the bridge other than at the ARP level.

  • Likewise, IPNat ain't gonna work neither. So don't even bother.
<!-- hhmts start --> Last modified: Thu Aug 24 04:59:52 EDT 2000 <!-- hhmts end -->

Notify me whenever the openbsd section of this site is updated

Email this page to a friend or colleague

Show a printer-friendly version of this page