FireBrick notes

I recently bought a FireBrick as I was getting annoyed with some issues with my openwrt setup (which is another story). Part of me feels bad for leaving my open source solution, part of me feels bad for spending so much money on the FireBrick, but another part of me feels good for supporting a British company and a product that was developed from scratch in the United Kingdom.

Ignoring all those feelings, configuring the FireBrick just makes sense to me. I was up and running in no time at all, it doesn't try and add layers of abstraction to things. Once it is configured, it just sits there, sipping 3 watts and should you want to reboot it...you will hardly notice (<5 seconds of total internet downtime)

SIDE NOTE: Maybe I'm in the minority, but I often find things more complicated and hard to understand when a product tries to add a layer of abstraction to something; networking in Docker, I find confusing compared to networking in LXC...where it doesn't do anything for you and you need to setup a bridge (or whatever you want), firewall, etc yourself. It measns you understand exactly what is going on, and no-one else has made any decisions for you that you don't know about. It also means (in this example) once you've learnt general Linux networking basics, you're good to go with LXC containers, but not with Docker

Other than the overall speed I can get through the FireBrick, I am very pleased with it. There are some things which don't appear to be documented in the manual or elsewhere that I have worked out - and I am noting them here for my future self and anyone else.

Port forwarding

NOTE: Fire Brick (and AAISP) call this "port mapping", but it is the same thing

A look at the port mapping page on the AAISP wiki will get you most of the way there, it suggests something like the following:

<rule-set
    name="Port Mappings"
    source-interface="pppoe"
    target-interface="self"
    no-match-action="continue"
>
    <rule
        name="Map RDP to server1"
        target-port="3389"
        set-target-ip="192.168.1.101"
        set-nat="true"
        action="accept"
    />
</rule-set>

For me, this appears to work for some services (HTTP), and not for others (IMAP). I spent a long time scratching my head as to why before I cracked out tcpdump when it became obvious.

SIDE NOTE: I should definitely reach for tcpdump earlier every time I'm working through a networking issue (but never actually do). Nearly every time, it instantly gives me more information about the problem which makes it much easier to solve!

tcpdump on the final destination of the connection (the HTTP or IMAP server in my examples) shows that the source IP of the connection is the router (FireBrick), not the IP of the actual source device itself. Looking at the XML above, I guess this makes sense too; we are asking the FireBrick to NAT the traffic matching this rule.

So, why does this work for my HTTP server, but not my IMAP one? It took a little more head scratching, and looking at the logs of my IMAP server but it's very simple: I have a fail2ban instance infront of my IMAP server. Fail2ban bans connections from a specific IP when it has unsucessfully tried to log in a predefined number of times in a predefined period of time. While my IMAP client does know the correct username and password for my email account, as far as fail2ban (and my IMAP server) is aware, my (legitamate) traffic is coming from the same source IP address as the numerous people that are trying to gain access to my IMAP server 24/7. Therefor, it banned this IP address...the gateway IP address, the FireBrick IP address.

The reason it was working for HTTP, is because I don't have any similar protection on my HTTP server. (I don't think I need to???)

Anyway, on to the actual fix, which is simple: Everything that the AAISP page says, except the NAT flag. We want the source IP of the connection, at the point of the destination (HTTP / IMAP / whatever server) to be the IP of the original connection:

<rule-set
    name="portForwards"
    source-interface="lanInfra lanServices lanTrusted lanGuest lanPp lanHidden l2tp"
    target-ip="staticPublicIpv4Addresses"
    no-match-action="continue"
>
    <rule
        name="IMAP implicit TLS port forwarding"
        target-port="993"
        protocol="6"
        set-target-ip="10.23.45.67"
        set-graph="externalToIMAP"
        action="accept"
    />
</rule-set>

SIDE NOTE: In the example above, my source-interface is set to a number of interfaces, not just the one with my public IP. This is so that these port forwards work from clients in my local networks too

L2TP MTU

NOTE: This also applies to my openwrt setup - it's not specific to the FireBrick

The FireBrick L2TP client page on AAISP support wiki suggests the following config:

<l2tp>
    <outgoing
        name="AAISP"
        hostname="AAISP"
        server="l2tp.aa.net.uk"
        graph="AAISP"
        table="1"
        payload-table="0"
        username="example@a.1"
        password="secret"
        tcp-mss-fix="true"
        comment="L2TP tunnel to AAISP"
    />
</l2tp>

Note that there is no MTU value set, so the FireBrick calculates one. In my case this is 1464.

A config based on this (I'm not using different routing tables for the payload) does indeed work, but, it is leaving SO much performance on the table.

After lots of faffing around, I came back to the AAISP wiki and found another page. In the L2TP client in this one there is an MTU of 1280 set. It doesn't say why, and to this day I'm not clued up enough to know why, but with this configured the upload speed of the connection nearly doubled....to exactly where I was expecting it to be!

NOTE: If anyone know why this is the case, please let me know!!

SIDE NOTE: This is also the case with openwrt: By default it will calculate an MTU to use, but if you set it to 1280, the upload speed doubles! I don't know why, or if this is specific to AAISP, but it is good news for me

So, it's just a tiny bit of config that makes such a difference. My L2TP client config now looks like this:

<l2tp>
    <outgoing
        name="l2tpAaisp"
        server="l2tp.aa.net.uk"
        graph="l2tpAaisp"
        username="user@a.1"
        password="secret"
        routes="0.0.0.2"
        mtu="1280"
        tcp-mss-fix="true"
    />
</l2tp>

VoIP call recording

The FireBrick has a cool option that allows you to record VoIP calls going through it. It doesn't actually do the recording itself, it just sends the audio from both sides of the conversation to another SIP endpoint. If you hunt around you will also find a handy application written by RevK/AAISP that will save the audio the FireBrick is sending out to disk, amoung other things.

The manual assumes that you want to record the calls, and then email them to the "owner" of the local phone that made or recieved the call. Maybe for most cases this is true, but I never follow the norm. I just want to record calls, but leave them sitting on the server. I don't want to email them, or do anything else with them. Because of this, when setting up call recording on the FireBrick, I didn't specify an email to send the final recording to.

<telephone
    name="user"
    display-name="User"
    username="user"
    password="secret"
    allow="10.1.2.0/24"
    extn="200"
    record="true"
/>

I spent a long time trying to work out why call recording wasn't working. (Imagine hours spent fiddling with firewall rules, and lots of tcpdump sessions)

Turns out, that email field is very important in the config, and needs to be populated for the FireBrick to actually do anything (with regards to recording calls)....despite record="true" being set.

Set the email attribute to anything...literally anything...and the FireBrick will talk to the voip-answer server, which will record your call.

<telephone
    name="user"
    display-name="User"
    username="user"
    password="secret"
    allow="10.1.2.0/24"
    extn="200"
    record="true"
    email="x"
/>

Whether the recording is actually emailed out isn't decided by the fact that I've supplied a bogus email address here, but by the arguments supplied to voip-answer when running it. This is pretty obvious when reading the usage of the application and giving it a test, so I won't go into it here.

Rule based overrides

NOTE: This isn't something where I found the documentation lacking in any way, but it is such an incredibly cool concept that I want to write about it here.

TODO

IP groups

NOTE: Again, not something lacking in documentation, but another cool feature of the FireBrick

TODO