Category Archives: Networking

Vyos and the mystery conntrack counter

VyOS

Router Go Fast!

For those that know me, it’s no secret I’m a huge Vyos fan.  I moved away from pfSense after they released a version that had issues with more than 1 vCPU, instead trying Vyos.  Once I’d seen how much better it performed under Proxmox I stayed on it and have never looked back.
I really feel the pfSense project lost its way when they fucked up Wireguard and then lashed out at everyone who was just trying to help get it into FreeBSD.  But I digress.

Flow Offload (Flowtable) Bug?

I recently upgraded from Vyos 1.3 to Vyos 1.4. 1.4 is a huge step forward for the project as it moves from iptables to nftables.  It also brings some great new features, like Flowtable (software/hardware flow offload).  This means that once a flow has created a conntrack entry, all future packets that match this flow are fastpath’d through the conntrack service, assuming you have a rule to allow this like so:

firewall {
    flowtable FastVyos {
        description "Vyos Fast Software Offload Table"
        interface eth1
        interface eth0
        offload software
    }
    ipv4 {
        forward {
            filter {
                default-action accept
                description "Filter for packets being forwarded through the router"
                rule 10 {
                    action offload
                    description "Offload Established TCP and UDP Traffic"
                    offload-target FastVyos
                    protocol tcp_udp
                    state established
                    state related
                }

This results in better performance and on older/slower hardware will increase the number of packets-per-second that a device can handle.  This is a very good thing!  You can see its working if you see [OFFLOAD] in your conntrack table:

conntrack -L -u offload
<snip>
tcp      6 src=x.x.x.x dst=x.x.x.x sport=43392 dport=x packets=2317 bytes=192092 src=192.168.0.5 dst=x.x.x.x sport=x dport=43392 packets=2644 bytes=149748 [OFFLOAD] mark=0 use=2
tcp      6 src=x.x.x.x dst=x.x.x.x sport=55400 dport=x packets=1336 bytes=111233 src=192.168.0.5 dst=x.x.x.x sport=x dport=55400 packets=1535 bytes=88580 [OFFLOAD] mark=0 use=2
tcp      6 src=x.x.x.x dst=x.x.x.x sport=49836 dport=x packets=850 bytes=70559 src=192.168.0.5 dst=x.x.x.x sport=x dport=49836 packets=1060 bytes=58247 [OFFLOAD] mark=0 use=2
tcp      6 src=x.x.x.x dst=x.x.x.x sport=60797 dport=x packets=10014 bytes=827040 src=192.168.0.5 dst=x.x.x.x sport=x dport=60797 packets=10125 bytes=570347 [OFFLOAD] mark=0 use=2
conntrack v1.4.7 (conntrack-tools): 693 flow entries have been shown.

 

Once I’d turned on Flowtable though, I started to have issues with Firebase Cloud Messaging on my Android phones.  It’d keep timing out and I wouldn’t get push notifications until I woke up my phone.  I spent ages debugging, Wiresharking, testing with Flowtable on and off.  It always would work with Flowtable off, but would fail/disconnect with Flowtable enabled. In the end, convinced I had found a bunch in nftables (quite the accusation to make!) I logged a bug in the Netfilter BugTracker. Turns out I was actually correct, there was an issue with PPPoE encapsulation and Flowtable.  I’d actually switched ISPs to one that does DHCP (not because of the bug!) and I hadn’t noticed the problem with DHCP, it was good validation to see it was a PPPoE + Flowtable bug.
I should point out for any PPPoE users out there, the bug is fixed in Linux 6.6.30 onwards, which the latest Vyos 1.5 rolling images are using.

Conntrack Clashes?

So now my router was working perfectly, but for some reason at some stage I decided to look at the conntrack table statistics.  I just like to see how things work “under the hood” I guess.

Wait, what’s this? What the hell is clash_resolve in my conntrack statistics and why is it going up by ~300 a minute? That can’t be a good thing, can it?

tim@ferrari:~$ conntrack -S
cpu=0 found=13872 invalid=64978 insert=0 insert_failed=2130 drop=2130 early_drop=0 error=1966 search_restart=0 clash_resolve=1091611 chaintoolong=0 
cpu=1 found=13353 invalid=64876 insert=0 insert_failed=2164 drop=2164 early_drop=0 error=1760 search_restart=0 clash_resolve=1098408 chaintoolong=0

I spent a lot of time googling, but trying to find any real information about what it does was hard.  There were the main links I found that offered some insight.

It turns out what a clash_resolve is, at least to my understanding, is that when conntrack tries to create an entry, if there’s already an entry for that tuple [source IP, source port, dest port]:[destination ip, source port, dest port] that it will instead shift the source port of the incoming packet so that it’s unique, and create a conntrack entry based on that.  I haven’t explained that very well because I never could quite find exactly what was going on myself to a level I felt I understood.  Probably I’m too stupid really, so if you have a better plain english explanation I’d welcome it!

But I did find the cause of the problem.  My Vyos router runs a caching nameserver, it’s my home router so it makes sense for it to cache most DNS lookups.  I have a Zabbix Server at home too and it generates A LOT of DNS requests.  I found as soon as I turned off my Zabbix server that the clash_resolve stopped incrementing.  After looking at the conntrack table I realised there were hundreds of conntrack entries between the DNS Server on the router and my Zabbix server:

<snip snip>
udp      17 19 src=192.168.0.253 dst=192.168.0.1 sport=48288 dport=53 packets=2 bytes=124 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=48288 packets=2 bytes=189 mark=0 use=1
udp      17 12 src=192.168.0.253 dst=192.168.0.1 sport=56102 dport=53 packets=1 bytes=68 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=56102 packets=1 bytes=84 mark=0 use=1
udp      17 12 src=192.168.0.253 dst=192.168.0.1 sport=56240 dport=53 packets=2 bytes=136 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=56240 packets=2 bytes=201 mark=0 use=1
udp      17 28 src=192.168.0.253 dst=192.168.0.1 sport=38695 dport=53 packets=2 bytes=124 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=38695 packets=2 bytes=189 mark=0 use=1
udp      17 10 src=192.168.0.253 dst=192.168.0.1 sport=33689 dport=53 packets=2 bytes=128 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=33689 packets=2 bytes=193 mark=0 use=1
udp      17 13 src=192.168.0.253 dst=192.168.0.1 sport=36236 dport=53 packets=2 bytes=128 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=36236 packets=2 bytes=193 mark=0 use=1
udp      17 10 src=192.168.0.253 dst=192.168.0.1 sport=49932 dport=53 packets=2 bytes=116 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=49932 packets=2 bytes=181 mark=0 use=1
udp      17 3 src=192.168.0.253 dst=192.168.0.1 sport=54581 dport=53 packets=2 bytes=126 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=54581 packets=2 bytes=191 mark=0 use=1
udp      17 1 src=192.168.0.253 dst=192.168.0.1 sport=40209 dport=53 packets=2 bytes=126 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=40209 packets=2 bytes=191 mark=0 use=2
udp      17 12 src=192.168.0.253 dst=192.168.0.1 sport=48388 dport=53 packets=2 bytes=136 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=48388 packets=2 bytes=201 mark=0 use=1
udp      17 4 src=192.168.0.253 dst=192.168.0.1 sport=51367 dport=53 packets=2 bytes=128 src=192.168.0.1 dst=192.168.0.253 sport=53 dport=51367 packets=2 bytes=193 mark=0 use=1
conntrack v1.4.7 (conntrack-tools): 167 flow entries have been shown.

Fixing Conntrack

And here’s the fix: Those connections don’t need to be in conntrack! There’s no NAT going on and I’m not doing any firewalling.  It’s local LAN traffic.  So the fix is to put in an exception rule, so that all traffic from my LAN, talking to my DNS Server on the router, bypasses conntrack.  Meaning there’s no state at all, it’s just a normal routed packet.
Note that you have to create a rule in both directions, otherwise the router sending back replies generates a conntrack entry.

The configuration looks like this, placed under the “system conntrack” stanza:

show system conntrack
 ignore {
     ipv4 {
         rule 10 {
             description "Ignore Conntrack for LAN DNS Requests to Router"
             destination {
                 address 192.168.0.1
                 port 53
             }
             inbound-interface eth1
             protocol udp
             source {
                 address 192.168.0.0/24
             }
         }
         rule 200 {
             description "Ignore Conntrack for LAN DNS Replies from Router"
             destination {
                 address 192.168.0.0/24
             }
             protocol udp
             source {
                 address 192.168.0.1
                 port 53
             }
         }
     }

With this in place, the conntrack table statistics for clash_resolve have stopped going up rapidly.  I still see some increasing, but that’s expected.  In fact clash_resolve isn’t even a problem as such, it’s just saying a clash was noticed and resolved.

I’ve also saved myself 650+ entries in the conntrack table that I didn’t need:

[Before the change above was made]
tim@ferrari# conntrack -L -s 192.168.0.0/24 -d 192.168.0.0/24
<snip>
conntrack v1.4.7 (conntrack-tools): 665 flow entries have been shown.

And my Vyos router is as performant as ever!

Tim

Panasonic DMR-HWT260GN

Review: Panasonic DMR-HWT260

This is my review of the Panasonic DMR-HWT260.  When I went to buy one, there weren’t any reviews so I hope this might fill a gap if you’re looking to buy one. Keep in mind when reading this that I’ve already bought one, and people who own something are much less likely to point out flaws in something that they’ve made the decision to buy.

I must also point out that this is the New Zealand model, not the Australian one.  Features like FreeviewPlus and a number of other settings are New Zealand specific.  If you read the instructions you’ll get a feel for the differences, none of them are major.  Also I expect (but can’t confirm) that most of the features/comments here will apply to the Panasonic DMR-PWT560 as well, it’s the same looking device except with built-in Blu-Ray and a smaller (500Gb) recording capacity.

Summary

This is a great PVR.  I bought this to replace our MySky HDI box and the interface is very similar. It has a simple way to navigate around a grid of current and upcoming programs and it’s easy to select one and either record a single episode or “series-link” to record all the episodes.

It works well, is fast at all it’s primary functions (more on speed later) and the image quality is clear.

Overall Verdict: Excellent.

Unboxing

People who do “unboxings” are stupid and annoying.  If you really want to see someone taking an object out of a box you need to seriously examine your life choices. (Yes, I am nearly 40.)

Features

  • Record two shows at once using its built in Tuners
  • Can record to an external HDD as well as the internal 1TB one.
  • Play back media from a local DLNA server, or USB drives.
  • Built in Wifi, with a Wired option as well
  • Selection of Internet Apps, including Netflix, Quikflix, TuneIn Radio, Youtube
  • Undocumented “Chromecast” abilities.

Review Details

This review was done with v1.00 of the firmware.  There haven’t been an updates or patches since we’ve had the box, but we’ve only had it 3 weeks.  I’m approaching this review from the point of view of comparing it to MySky HDi which we’ve had for a number of years – I suspect that’s why a lot of people will be looking at a PVR like this.

Good Things

  1. Records TV just fine.
  2. Nice clear picture, HD quality is excellent.
  3. User interface is pretty good!  It’s easy to see what’s coming up, easy to schedule something to be recorded and the “keyword” feature looks quite good, with the below caveat about how annoying not having a proper keyboard is.
  4. Built in WiFi works well, though I’ve since connected it to the wired network.  I’m a firm believer if something can be plugged in vs WiFi it should be!
  5. Lots of options to compress recordings (as they’re being recorded, or after the fact) to save Disc space.  Though a 1TB will probably take a little while to fill up!
  6. DLNA playback is great, we have a big media library on a server and the ability to play pretty much anything from it is handy.  Want to watch a movie? A few clicks (in fact a couple too many for my liking) and it’s on.
  7. It has built in “Chromecast” support for some apps.  I can be watching something on Youtube on my Android phone then “Cast it” to the Panasonic.  The Youtube app loads up and the video in question plays.  Very handy. Note: This is not screen mirroring, this is the Android phone telling the Panasonic “Load your Youtube app up and start playing this clip” – This seems to be an undocumented feature (it’s not the same as Miracast)
  8. The Netflix app works well.  Again as above you can select the movie on your Android phone and then “cast it” onto the Panasonic.  If you have an Apple TV or some other “better” dedicated Netflix box then I think you’ll find you use that rather than the Panasonic, but if you haven’t got a Netflix device already then this works fantastically.
  9. The remote control has the ability to also function as your TV’s remote control, so you can turn on/off the TV and change its inputs & volume using a single remote.
  10. It’s quite small and lightweight.

Bad Things

The followings things are things about the device that have annoyed me to some degree:

  1. Pausing or Rewinding Live TV takes a few seconds, during which time you think nothing is happening.  It’s very slow and is a very confusing thing!  And then when you’ve paused it, you’re now in this new “mode” where certain limitations apply.  This means you often get the message “You must return to Live TV to do X/Y/Z”.  Which is easy enough, you just press stop.  But compared to the seamlessness of SkyTV’s MySky box, it’s quite clunky.
  2. Entering text into fields to login (Like TVNZ’s Freeview service or the “keyword” PVR feature) is a pain in the butt.  It’d be nice if there was a way to pair a Bluetooth Keyboard with the device, or plug one in.  But it doesn’t support that (Note: I have not tried plugging a USB Keyboard in)
  3. You can’t keep watching something using the DLNA service when a program is being recorded.  This means it’ll “kick you out” of a DLNA session to start a timed recording.  Annoying when the kids are watching Peppa Pig but something I want recorded comes on.  Seeing as the box states “Watch Netflix while recording Live TV!” I find this limitation bizarre and hope it can be removed in a Firmware Update.
  4. The Internet/Net applications are pretty slow to start. You’ll press the TVNZ On Demand button and wait ~5 seconds or something to happen.  This is to be expected really, the box doesn’t sell itself majorly on its Internet features, apart from Netflix.  But some indication it’s received your input and is doing something would be nice.
  5. Freeview Plus pops up a slide out menu every time you change channel to one supported by Freeview Plus.  This is useful maybe the first 3 times and from then on just pisses you off.  No way to turn it off without disabling Freeview Plus (entirely) in the settings, which thankfully is a setting.  The Freeview Plus menu/guide is also confusing for people: Is this the same guide? What does “starring” something do, does that mean it records it (Answer: No).  It’s basically a second, differently laid out, guide.  Very confusing.  Apparently all Freeview Plus enabled boxes are like this though.
  6. Sometimes the “Exit” button is confusing.  Do you press Exit? Or the Return arrow? Or do you press stop?  Depending on what function you’re in, it can have different consequences.  To stop watching something in DLNA and return to the Media Menu, you have to press stop.  Otherwise you exit out of the DLNA service back to Tuner.
  7. No volume control on the Panasonic remote.  Yes, I know having separate volume controls is silly (people end up turning the sound RIGHT UP on the amp and then using the input box’s volume control) but it’s a handy feature, saving you having to have multiple remotes to control things.  This is especially annoying for us as we don’t use the TV’s volume for the sound, we have a dedicated amplifier.
  8. Occasional 1 second picture flicker (goes black then comes back), like a HDMI negotiation issue.  Sometimes happens a few times in a 10 minute interval, sometimes we can go all night and not see one.  2 other people who own this have reported it as well.  Only seems to happen when viewing Live TV, haven’t seen it with DLNA or when using menus etc.  Someone has suggested turning off the FreeviewPlus feature also fixes the issue, but I haven’t confirmed this yet.

Some of the items in “Bad Things” (especially point 8) could easily be addressed in future firmware updates and I hope they are.  It’s a great box with a few minor niggles, none of which really get in the way.

Final Thoughts

It has a hilarious little “app store” built in where you can download a tiny smattering of extra media applications, most of which look terrible.  It has a clunky web browser built in, given the feedback above about no keyboard you can imagine how fun it is to use.  That said, it does render things very well.  But why would you?

It’d be nice to have a way to quickly jump to the DLNA server folder that you use all the time, at the moment it’s ~7 button presses to get there every time.  A favourites menu would be god here.  There’s a lot of places where a little bit more thought could have been put into how people are really going to use this device.  Some settings are tucked away in the main settings, while some are accessed by pressing the “Option” button while watching TV. The core functions are great and are well thought out, it’s all the add-on bits that are a little bit rougher around the edges.

Overall a really good box that works well.  There’s certainly some areas for improvement, but none of them I’d consider defects, just things that can annoy you a bit.  There are cheaper boxes on the market that have the same capabilities (Especially the DishTV aerialBox T2200) but it they seem to be plagued with major firmware issues.

Pushbullet Logo

Debugging Issues with Pushbullet and Google Play Services

Background

I’m posting this because every day there’s a new post on /r/pushbullet about people not getting their Pushbullet messages until they open the Pushbullet app.  There’s a number of reasons that this issue can arise, some of them are unrelated to Pushbullet itself, but will cause the symptoms, some are related to Pushbullet though no definitive answer has been found for this yet.  This article will help you to diagnose issues unrelated to Pushbullet – if following the steps and suggestions don’t help then escalating to Pushbullet’s support would be a good next step.

To kick off this article, I’ll explain briefly how push notifications work for most applications, but not all on Android.  Almost every Android phone out there has Google Play Services installed.  This “App” is pre-installed on your phone and is the support library that all Google Apps and many others rely on.  One of it’s many jobs is to provide the “Google Cloud Messaging” (GCM) service.

2019 update.  GCM is now FCM (Firebase Cloud Messaging) but I’m not going to update this blog post to change it all, it’s still the same basic thing.

This, very simply, allows a server/service hosted somewhere to send a message to Google, and Google will then, using GCM, push a message to the user’s phone.

The reason that GCM is so useful is that apps can register with it when they’re installed.  This means that each app doesn’t have to have it’s own network/infrastructure for pushing messages to your phone, but rather there is a single push service on your phone that all apps can use.  This helps with battery life and means that App developers can focus on writing apps, not having to also host and maintain a network dedicated to pushing messages to phones. It also means your phone only has to have one network connection open to get push messages, instead of each app having to keep a network connection open, which is a drain on resources and battery life.

The Problem

Now the problem comes about with Pushbullet when it doesn’t get messages from GCM.  These messages should “Wake it up” so that you instantly get the push on your phone.

But if Pushbullet doesn’t get the GCM notification, it has no idea that anything new has happened.  It only realises when you open the app and it Sets up it’s own connection to the Pushbullet Servers and gets the latest notifications.  In fact, that’s all a GCM message is, a message to say “Hey, wake up and check your server for the message waiting for you, Pushbullet”.

So if this isn’t working for you, there’s a few things you can do to debug (and hopefully resolve) the issues so that your Pushbullet app starts working as you expect.  Depending on the problem, you might find other apps you didn’t even realise were lagging seem to be a lot faster too!

Debugging Google Play Services

Thankfully, Google have included a way to find out the status of Google Play Services and whether or not it has an active connection to the GCM services.  Type the following code into your dialer and you’ll open up the Google Play Services status page:

Dialer Debug Code
*#*#426#*#*

You will open up a screen that looks like this:

GCM Connected

GCM Connected

Notice the following things about this image:

Device ID: The Device ID that Google has assigned your device.
Connected: This is the key we’re looking for! We want to see that it says connected and a lot of information about how it’s connected.

This is what a bad/broken/non-working GCM screen looks like:

GCM Disconnected

GCM Disconnected

What follows is a list of  reasons (and some workarounds/fixes) as to why Google Play Services might not have a connection…

Why doesn’t it work?

IPv6 is enabled. For me, IPv6 works fine. But for a lot if people, if their router/WiFi is giving them an IPv6 connection, but it’s not properly routed, then it won’t work. But for reasons unknown, Google will keep trying to use the IPv6 connection, even though it’s broken. Sadly on Android the only way to disable IPv6 is via root methods, there is no simple way for a non-rooted person to do it. The best option if you’re not rooted is to disable the router/WiFi you’re connected to from giving you an IPv6 address. Of course if you’re at work etc then getting the IT people to do this is probably an impossible task.

The GCM Ports are Firewalled. This is less likely, but certainly possible if your work environment only allows port 80/443 out.  GCM uses TCP Port 5228 (The standard Jabber Port!), but it can also sometimes use TCP Port 5229 and 5230.  If these ports are blocked, you won’t get a stable GCM connection.

Your Firewall has dumb sessions timeout. I’m not sure how valid this one is with later versions of GCM, but if you have a firewall that times out TCP sessions after 5 minutes, you could well have issues with GCM which only sends keepalives every ~29 minutes (This is not confirmed yet).

The Fixes

Use Mobile data (disable WiFi).

Annoying, but great as a quick workaround to see if it fixes the problem.

Run a VPN.

This is what I did at a place of employment where IPv6 was broken. The VPN gives your phone a IPv4 only address and Google Play Services will connect via it and work fine.

Is GCM not the issue?

If you’ve looked at the above but you’re finding that you’re still missing push messages, one “fix” is to uninstall and re-install Pushbullet.  Why this is required is still under investigated by the PB devs.  A way to test if only Pushbullet is affected is to get someone to send you a test Google Hangouts message, or to send yourself a Gmail (has to be Gmail, not an IMAP account).  These both notify your phone of a new message by using GCM.  If you’re getting Gmail/Hangouts notifications instantly with no delay, but getting delays with Pushbullet, then the issue isn’t GCM and something else is wrong.  Might be time to contact the PB Devs and see if there’s any information you can give them to help debug the issue.

Good luck!

Running Your Own Mailserver(s)

This post is now out of date! Running your own mailserver is even easier these days thanks to rspamd. You literally plug rspamd into your mailserver using a milter, it’s a single line in postfix, and rspamd rolls up everything below in the smtpd_recipient_restrictions section and then some more, plus it’s got a nice webGUI. 

Rspamd: Zero spam, Rapid delivery.

Running your own mailserver isn’t that hard.  I always have a chuckle when I read people say “Why would you do it yourself, there’s so much management?”  That’s crap, they just don’t know how to do it.

A mailserver basically runs itself, there’s plenty of online tools to verify that you’re not an open relay, that you’ve configured your TLS settings correctly etc.  Plenty of configuration guides (another is included below) to show you how to lock it down so that it’s not a spam wind-up-and-go machine.

I run 3 mailservers (1 primary, 2 backup).  They all talk a single Greylisting Daemon, set to allow mail through after 1 minute.  Should the greylisting daemon not be available, the servers are set to accept the mail.

Before greylisting takes place however, the mail gets a bunch of checks.  First of all, High Quality DNS Whitelists are checked, if a server is listed in here it can be Trusted to not be sending Spam.  Then Blacklists are checked.  Then remaining whitelists are checked, if a server is listed it is allowed to bypass Greylisting. NOTE: Don’t use SORBS! Their data is out of date and crap. Way too many false positives. Avoid at all costs. I made this mistake once.

Here’s the full logic that all my mail servers use.  You have to ensure you share the greylisting database correctly, otherwise you’ll end up delaying mail much longer than necessary.

  1. REJECT anyone who doesn’t say HELO
  2. REJECT invalid Hostnames in HELO
  3. REJECT senders not using <user@domain.domain> correctly as per RFC821.
  4. REJECT Unknown Recipients
  5. ALLOW from a list of Known IPs (Backup MX hosts, other trusted devices)
  6. ALLOW from Authenticated Senders (To send mail from anywhere, using username/password)
  7. ALLOW from a set of DNS Whitelists that state an entry in their list can be considered “Non-Spam”
  8. REJECT from a list of DNS Blacklists
  9. ALLOW from a second set of DNS Whitelists that are verified to be SMTP servers (skips the need to greylist)
  10. Send to Greylisting Daemon to ACCEPT/DELAY
  11. ACCEPT

Step 7 could be amalgamated with step 9, but I prefer to “trust” the lists of known, trusted  email senders before checking blacklists, as sometimes blacklists can be a bit “over zealous” in their flagging a server a spam, i.e. one that sends newsletters etc.  This way I get check of this logic:

  1. Verified quality sender – ACCEPT.
  2. Check for blacklists – DENY.
  3. Verified RFC compliant SMTP server, skip greylisting (because we know it’ll just retry anyway, no point delaying) – ACCEPT.
  4. Send to Greylisting for DELAY/ACCEPT decision.

With these rules in place, I get almost zero spam making it through, probably 2-3 spams per week.  However the amount of mail that is rejected via the Blacklists and the Greylisting is amazing, in the thousands per day.

Once I’ve finally accepted a mail, I send it to Spamassassin for checking, just to be sure.

The other thing that’s important that I’ve done fairly recently (in the last couple of years) is to ensure that Postfix is setup correctly to send and receive mail using encryption. SSLv2 and SSLv3 are disabled, weak ciphers are disabled, Perfect Forward Secrecy is enabled.

Here’s my main.cf for Postfix.

smtpd_banner = $myhostname ESMTP - SMTP BANNER GREETING
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Send a warning if mail is delayed after 1 hour
delay_warning_time = 1h
# If mail can't be delivered after 7 days, we give up
maximal_queue_lifetime = 7d

readme_directory = no
inet_protocols = ipv4

# Incoming Mail
smtpd_tls_cert_file=/etc/letsencrypt/live/<hostname>/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/<hostname>/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 604800
smtpd_tls_eecdh_grade = strong
smtpd_tls_security_level = may
smtpd_tls_ciphers = high
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_exclude_ciphers = aNULL, eNULL, RC4
#Don't offer Auth until STARTTLS has setup
smtpd_tls_auth_only = yes

#Ask for a Client Cert
smtpd_tls_ask_ccert = yes

# Outgoing Mail
smtp_tls_cert_file=/etc/letsencrypt/live/<hostname>/fullchain.pem
smtp_tls_key_file=/etc/letsencrypt/live/<hostname>/privkey.pem
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_use_tls=yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 604800
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_exclude_ciphers = aNULL, eNULL, RC4

#TLS Params
tls_preempt_cipherlist = yes

myhostname = <my hostname>
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = <hostnames I accept mail for>
virtual_alias_domains = <other domains I host>
virtual_alias_maps = hash:/etc/postfix/virtual
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 <backup MX1> <backup MX2>
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
html_directory = no

# Procmail to deliver
mailbox_command = /usr/bin/procmail

# sasl! You want to eat it!
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_authenticated_header = yes

# Mailing Signing with OpenDKIM
milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301 # Don't copy unless you have setup DKIM
non_smtpd_milters = inet:localhost:12301 # Don't copy unless you have setup DKIM

# Proper Mail Protocol Please
strict_rfc821_envelopes = yes

# Verify? No thanks!
disable_vrfy_command = yes

# Demand a polite conversation!
smtpd_helo_required = yes

# Delay before reject
smtpd_delay_reject = yes

smtpd_helo_restrictions = permit_mynetworks,
 reject_non_fqdn_hostname,
 reject_invalid_hostname,
 permit

smtpd_recipient_restrictions =
 reject_invalid_hostname,
 reject_unknown_recipient_domain,
 reject_unauth_pipelining,
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_client_access cidr:/etc/postfix/rbl_override,
 permit_dnswl_client iadb.isipp.com=127.0.1.255,
 permit_dnswl_client sa-trusted.bondedsender.org,
 permit_dnswl_client sa-accredit.habeas.com,
 permit_dnswl_client list.dnswl.org=127.0.[0..255].[2..3],
 permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;5],
 reject_rhsbl_reverse_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rbl_client zen.spamhaus.org,
 reject_rbl_client dnsbl-1.uceprotect.net,
 reject_rbl_client psbl.surriel.com,
 reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
 reject_rbl_client bl.mailspike.net,
 reject_rbl_client b.barracudacentral.org,
 reject_rbl_client truncate.gbudb.net,
 permit_dnswl_client iadb.isipp.com=127.0.2.[1;2],
 permit_dnswl_client iadb.isipp.com=127.3.100.[5..100],
 permit_dnswl_client wl.mailspike.net,
 permit_dnswl_client list.dnswl.org,
 permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.3,
 check_policy_service inet:127.0.0.1:10060,

message_size_limit = 81920000

Once configured like that, it’s set and forget pretty much.  I occasionally check the logs to ensure that nothing is being greylisted due to the dumb policy some senders have of retrying each time from a DIFFERENT IP Address.  When I do see such stupidity I usually just add the sending /24 network to the Greylist Whitelist.

The final thing to note is that you should run your own caching DNS server.  If you’re using your ISPs, or a big public provider like Google etc, then the black/whitelists often won’t work as they implement rate-limiting against abuse, and the big public name-servers are almost always blocked.  Running your own small caching DNS server is easy and will give you a working RBL setup.

 

Update: 11/4/2017 – Turns out Protected Sky are just a bunch of rip-off merchants. Removed them from my list of checked RBLs.

EFB Ey?

To be clear – I’m not trying to pick on anyone here. It’s just an amazing example of the confusion around UFB.

[24/10 10:44] <USER> @NZ_ISP can you please tell me the CIR on 100/50 business fibre?
[24/10 11:10] <@NZ_ISP> @USER My understanding is that it’s 10Mbps down, 2.5Mbps up (that’s for your plan). ^CP
[24/10 11:12] <@USER> @NZ_ISP OK. I think the support team are using that as an excuse. Hitting a wall at 35mbit, but they’re saying that’s OK.
[24/10 11:19] <@NZ_ISP> @USER That’s obviously well above CIR, but we want to make sure you’re getting as fast a speed as possible too. ^CP
[24/10 11:20] <@USER> @NZ_ISP I can’t break 35mbit with multiple streams from multiple fast NZ servers. There’s definitely an issue there.
[24/10 11:26] <@NZ_ISP> @USER I’m only passing on what our engineers have checked out – like I said, I’m having them check it again. ^CP
[24/10 11:28] <@USER> @NZ_ISP Thanks. I’ve emailed prem support again with more pretty pictures.

[24/10 15:24] <@kiwibrew> @USER if multiple streams saturate a connection, it’s a TCP tuning / receive window issue, not the circuit @stevebiddle @NZ_ISP
[24/10 15:29] <@USER> @kiwibrew Tell me more. Anything I can adjust at my end to enhance this?
[24/10 15:29] <@USER> @kiwibrew Err, it’s upload that’s not going as fast as it should too, btw.
[24/10 15:33] <@NZ_ISP> @USER The ticket is in a closed state so yes, you’ll continue to get those messages if you keep sending emails. I’m having them check…
[24/10 15:33] <@NZ_ISP> @USER …into it again though. ^CP
[24/10 15:34] <@USER> @NZ_ISP I think we’re at a stalemate anyway. I maintain 70% of advertised speed isn’t good enough. You maintain that you only promised me 2.5
[24/10 15:34] <@USER> @NZ_ISP As a side note the ONLY speed mentioned on the contract I signed was the 100/50. Hope you’ve got proper UFB contracts by now?
[24/10 15:36] <@NZ_ISP> @USER So would you like me to leave this ticket closed then? ^CP
[24/10 15:37] <@USER> @NZ_ISP You’re aware your customer is unhappy with the service you’re providing. Up to you if you re-open or leave it.
[24/10 15:38] <@kiwibrew> @USER Perry has some good resources here: http://wand.net.nz/~perry/max_download.php Also check http://nzbt.org.mz for limiting factors
[24/10 15:42] <@NZ_ISP> @USER Just had a chat with the team and they’ve let me know that the speeds are at an acceptable level for us and Chorus. You’re more…
[24/10 15:42] <@NZ_ISP> @USER …than welcome to have a chat with your account manager if you have any more concerns. ^CP

Best Juniper PR

From the 10.4R10 release notes:

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/release-notes/10.4/index.html

A service technician brushed against the front panel of a MX RE card, and the RE powered down. Resulted in outages of customer networks. [PR/703076: This issue has been resolved.]

Sadly they have updated the document.