docs/howtos/HowToFilteringBridge.mdwn

   1 # Building a filtering bridge with DragonFlyBSD
   2 A filtering bridge transparently filters packets in a network. This has its advantages and disadvantages. Disadvantages include: getting the bridge up (the handbook is outdated on this), active FTP, directions.
   3
   4 I have spent many days getting my bridge up & running. Thought I would share the information with others in order to help avoiding the hassle I had to face
   5
   6 ## Materials and Methods
   7 I used a dual PII/400 system with 2 Planet-ENW-9607 /sk(4)/ NICs and the machine was running DragonflyBSD 1.6.1.
   8
   9 ## Setting up bridging
  10 To enable bridging and PF support on DragonFly you have two options: load the required kernel modules or compile them directly into the kernel. I chose the latter, because ALTQ support ha to be compiled into the kernel anyway in order to use traffic shaping (and I had to recompile for SMP as well :P). Here is my kernel config (only the parts that differ from GENERIC.):
  11
  12
  13     machine         i386
  14     cpu             I686_CPU
  15     ident           SMP
  16     # Bridging support
  17     pseudo-device  bridge
  18     # ALTQ
  19     options         ALTQ            #alternate queueing
  20     options         ALTQ_CBQ        #class based queueing
  21     options         ALTQ_RED        #random early detection
  22     options         ALTQ_RIO        #triple red for diffserv (needs RED)
  23     options         ALTQ_HFSC       #hierarchical fair service curve
  24     options         ALTQ_PRIQ       #priority queue
  25     options         ALTQ_NOPCC      #don't use processor cycle counter
  26     options         ALTQ_DEBUG      #for debugging
  27     # PF
  28     device          pf
  29     device          pfsync
  30     device          pflog
  31     # Symmetric Multiprocessing support
  32     options        SMP                     # Symmetric MultiProcessor Kernel
  33     options        APIC_IO                 # Symmetric (APIC) I/O
  34 After compiling, installing and rebooting I got bridging support. If you don't need/want to compile a kernel you can simply open (or create) ** /boot/loader.conf**  and add these lines:
  35
  36
  37     if_bridge_load="YES"
  38     pf_load="YES"
  39     pflog_load="YES"
  40 and if you don't want to reboot, you can load the modules realtime:
  41     # kldload pf.ko
  42     # kldload pflog.ko
  43     # kldload if_bridge.ko
  44 Well, we have bridging support now, we have to create an interface that represents the bridge and tell which NICs belong to it.
  45
  46 Edit /etc/rc.conf and include:
  47     # Replace x.x.x.x with the desired IP.
  48     ifconfig_sk0="inet x.x.x.x netmask 255.255.255.0"
  49     ifconfig_sk1="up"
  50     cloned_interfaces="bridge0"
  51     ifconfig_bridge0="addm sk0 addm sk1 up"
  52     pf_enable="YES"
  53     pflog_enable="YES"
  54 There is no need to have IPs in a bridge, but it is generally a good idea to have one interface with an IP address assigned, and if we would like to do filtering, it is necessary (well, for me at least. :P) It is also good because you can SSH into the machine or run it as a DHCP server, caching DNS server etc. as well (I run dhcpd on it, but won't cover that now, there are many great howto's out there). That's it, we have a running bridge with PF. Now let's go and configure filtering!
  55
  56 ## Configuring the firewall
  57 I will not cover every PF option under the sun, go figure yourself, the [PF FAQ](http://openbsd.org/faq/pf/) is great, although it lacks some details that I will partially cover. I insist on readingg how lists, macros and filtering rules work before reading on. Be aware of DragonFly's PF version being the same as OpenBSD 3.6's one! First off, one needs to understand that a bridge is symmetrical from the aspect of traffic, hence it's a good idea to filter on only one interface. In my practice, the interface having the IP usually resides LAN-side, while the IPless one does on the WAN-side:
  58
  59
  60     int_if=sk0
  61     ext_if=sk1
  62
  63
  64 On other interfaces we just pass everything:
  65
  66
  67     pass quick on { $int_if, lo0, bridge0} all
  68 OK, we do the usual filtering, all good, then we get the good ol' active FTP problem. Well, since we have no new-wave ftp-proxy in the base system, nor does ftpsesame work on DragonFly, we'll have to stick with the ftp-proxy that comes with inetd. We enable it in **/etc/inetd.conf** (uncommenting the last line in the default config):
  69
  70
  71     ftp-proxy       stream  tcp     nowait  root    /usr/libexec/ftp-proxy  ftp-proxy
  72 and (re)start inetd:
  73
  74
  75     # rcrestart inetd
  76 It will listen on any interfaces by default, so you may want to limit access to port 8021 in PF. Now we set up PF to forward FTP traffic from the LAN to the ftp-proxy. On a router, this can be done with a simple traffic redirection - we redirect traffic from the external interface to the internal interface (even ftp-proxy needs an IP to listen on :-P):
  77
  78
  79     # ftp-proxy S01E01
  80     # Do you remember? ($int_if) always gives you the IP of that inerface, you can use it like (rl0) as well.
  81 rdr on $ext_if inet proto tcp from <intnet> to any port ftp -> ($int_if) port 8021
  82 but given that the bridge operates in Layer 2, we just have rewritten this packet, nothing more, it will leave the bridge and disappear ( **rdr** *** directives never work on a bridge!***). However, we can actually route it to another interface, and since the packet has just been changed to be destined to hit the IP of that interface, we have successfully done a forwarding, on a bridge it requires these two steps, though. We use the route-to keyword for this (and if you can NOT find anything about it in the PF FAQ, then you are right, there are a few words on it in the [pf.conf(5) manpage](http://www.openbsd.org/cgi-bin/man.cgi?query#pf.conf&apropos0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html), though):
  83
  84
  85     # ftp-proxy S01E02
  86     pass in log quick on $ext_if route-to ( lo0 127.0.0.1 ) proto tcp from <intnet> to ($int_if) port 8021
  87 We actually route it to the loopback interface, I am unsure why it has to be done this way. (FIXME) Well, all we have to do now to allow FTPDATA connections from port 20 of the ftpserver to our machine's IP. This can easily be achieved as ftp-proxy has a dedicated user called proxy, and we have uid/gid filtering in pf (another poorly documented feature):
  88
  89
  90     # ftp-proxy S01E03 a. k. a. season finale
  91     pass in log quick on $ext_if inet proto tcp from port 20 to ($int_if) user proxy keep state
  92 and we will have working active FTP behind our bridge.
  93
  94 ## References & acknowledgements
  95
  96 [man pf.conf](http://www.openbsd.org/cgi-bin/man.cgi?query#pf.conf&apropos0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)
  97 [PF FAQ](http://openbsd.org/faq/pf/)
  98 [A mailing list entry that I found on Google :)](http://lists.puremagic.com/pipermail/greylist-users/2005-October/001004.html)
  99
 100 ### Thanks to:
 101
 102 * Matthew Dillon
 103
 104 * Sepherosa Ziehau
 105   (for fixing the bridge and sk(4) driver code)
 106
 107 * Chris Csanady
 108   (for [telling me how to set up a bridge](http://leaf.dragonflybsd.org/mailarchive/users/2006-05/msg00148.html))
 109
 110 * Justin C. Sherrill and his [Dragonfly Digest](http://www.shiningsilence.com/dbsdlog/) (many ideas were pulled from there)
 111
 112 * and of course the rest of the Dragonfly list members for bearing with me :-)
 113