Hetzner: Routing IPv6 through a firewall such as pfSense

Hetzner offer very well specified physical servers at extremely low prices. I’ve used them for many years and they’ve proved to be extremely reliable. With each server, Hetzner will give you a single IPv4 IP and a /64 IPv6 subnet. You can also run virtualization software such as Proxmox and it’s often desirable to run a firewall such as pfSense on a virtual machine to protect the other virtual machines.

All good in principal, but the /64 IPv6 subnet has caused some confusion. Surely you need some more address space to be able to route the /64 subnet? It turns out, no. Hetzner don’t use NDP or proper IPv6 routing… they seem to just deliver the address space to the server (probably via static NDP entries mapping your /64 to your server’s MAC address). This actually works to our advantage because you do not need to assign the physical server any IPv6 addresses in the issued /64.

Broadly, the setup looks like this:

  • Physical server does not have an IPv6 address assigned to its physical interface
  • Physical server has IPv6 forwarding turned on
  • Proxmox (thus the physical server) has a private IPv6 address assigned to the bridge (vmbr) interface that it shares with pfSense
  • pfSense WAN interface has another private IPv6 address in the same subnet as the vmbr assigned to it
  • pfSense “LAN” interface has an address from your public /64 assigned to it
  • pfSense uses SLACC to assign IPs in your /64 to the VMs behind it
  • Physical server has a route to your assigned /64, via the private IP you assigned to your pfSense WAN interface
  • Physical server has a default IPv6 route to fe80::1

Here’s a picture where the assigned /64 is 2a01:4f8:66b:12d9::/64 and the private IPv6 /64 used between Proxmox and pfSense has been chosen fairly randomly using this:

Hetzner IPv6 Routing

Here’s the relevant parts of the network config on the physical Proxmox server:

  1. auto vmbr0
  2. iface vmbr0 inet static
  3. address
  4. netmask
  5. ovs_type OVSBridge
  6. post-up route -A inet6 add default gw fe80::1 dev enp0s31f6
  7. post-up route -A inet6 add 2a01:4f8:66b:12d9::/64 gw fda2:5d88:d5a3:1d4d::2
  8. post-up echo 1 > /proc/sys/net/ipv4/ip_forward
  9. post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
  11. iface vmbr0 inet6 static
  12. address fda2:5d88:d5a3:1d4d::1
  13. netmask 64

If you have any questions, leave a comment.



Postfix: Blocking senders by reverse DNS hostname

Postfix has an option for smtpd_recipient_restrictions called check_client_access. According to the Postfix manual, this:

  1. Search the specified access database for the client hostname, parent domains, client IP address, or networks obtained by stripping least significant octets.

You can use it to block specific domains, as resolved by the RDNS of the sending IP.

First, create a map of the domains you wish to block at /etc/postfix/bad_clients. It should look something like this:

  1. xserver.jp REJECT
  2. somedomain.com REJECT

It’s important to note that the parent_domain_matches_subdomains setting changes how Postfix matches subdomains. Check the existing value with:

  1. postconf -p | grep parent_domain_matches_subdomains

If the setting contains smtpd_access_maps then adding somedomain.com to your bad_clients file will also match something.somedomain.com. If the setting does not contain smtpd_access_maps then you will need to prefix the domains in your bad_client file with a dot in order to match subdomains (e.g. .somedomain.com).

You must now create a hash file from your bad_clients. To do this:

  1. postmap /etc/postfix/bad_clients

Now you can add check_client_access hash:/etc/postfix/bad_clients to your Postfix main.cf smtpd_recipient_restrictions. It’s more than likely you already have smtpd_recipient_restrictions so just add to the list in the appropriate place. E.g:

  1. smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/bad_clients, reject_unauth_destination, reject_maps_rbl

You’ll see it working as your mail logs will feature things like:

  1. Client host rejected: Access denied;

Fixed: Outlook 2016 not synchronizing Inbox from IMAP after upgrade from 2013

After upgrading from Outlook 2013 to 2016, I found that new e-mails were not being downloaded from IMAP into the inbox. Rather, they were only downloaded into sub folders.

To fix this, click File in the top left, click Account Settings and then click Account Settings again.

Now double click the e-mail account that is affected.

Click More Settings… in the bottom right.

Click the Advanced tab.

In the Root folder path box, type Inbox

Click OK to close the dialog

Click Next

Wait for it to test your settings and then click Close

Click Finish

Click Close

It’ll now refresh all your folders and your inbox e-mails will start to download

Fixed: Plex with Sonos – Unable to play – Unable to connect to Plex

This problem bugged me for a long time. I could list the contents of the Plex library in the Sonos app but whenever I tried to play a file, it errored with Unable to play – Unable to connect to Plex. It just doesn’t work.

The solution is NAT – specifically NAT reflection. You must enable Remote Access on your Plex and you must forward the port (usually TCP 32400) on your router. It is, however, a bit more complex than that. You also must be able to access Plex, on the public IP and port, from inside your network. This is called NAT reflection. For example, if your public IP were, you need to be able to access from a computer inside your network.

I will not attempt to try to describe how to enable NAT reflection on every router. I would imagine that some routers simply don’t support it at all.

In my case, I use pfSense. In pfSense, edit the port forward NAT rule and “Enable (Pure NAT)” for the NAT reflection setting. If this doesn’t work, as it doesn’t in my case, select Enable (NAT + Proxy) instead.

Make sure you can access in your web browser, where is your public IP. If you can, Sonos should work fine with Plex.

Tags: , ,

Juniper SRX – Upgrading JunOS from USB

There’s a few ways to do this. Here’s the easiest:

First, format your USB drive as fat32. Download the compressed image from Juniper (e.g. junos-srxsme-15.1X49-D80.4-domestic.tgz) and load it onto the USB drive.

Whilst logged into the SRX’s console, plug in the USB drive. You’ll see something like the below:

  1. umass1: TOSHIBA TransMemory, rev 2.00/1.00, addr 2
  2. da1 at umass-sim1 bus 1 target 0 lun 0
  3. da1: <TOSHIBA TransMemory 1.00> Removable Direct Access SCSI-4 device
  4. da1: 40.000MB/s transfers
  5. da1: 7400MB (15155200 512 byte sectors: 255H 63S/T 943C)

This tells you that the USB drive is available at /dev/da1. Assuming your drive has a single partition, that means the filesystem will be at /dev/da1.

Jump into the FreeBSD shell:

  1. start shell

Create a directory and mount the USB drive to it:

  1. mkdir /var/tmp/usb/
  2. mount_msdosfs /dev/da1 /var/tmp/usb/

Check that your JunOS image is present on the mount:

  1. root@% ls -1 /var/tmp/usb/
  2. junos-srxsme-15.1X49-D80.4-domestic.tgz

Jump back to the main JunOS console:

  1. exit

Install the image:

  1. request system software add no-copy no-validate /var/tmp/usb/junos-srxsme-15.1X49-D80.4-domestic.tgz

Reboot your device:

  1. request system reboot in 0

Once rebooted, sanity check your new install. If all is ok, you need to copy the JunOS image to the backup partition else if your SRX ever fails to boot then it will boot into your old JunOS:

  1. request system snapshot slice alternate

Once done, you can check it:

  1. root> show system software
  2. Information for junos:
  4. Comment:
  5. JUNOS Software Release [15.1X49-D80.4]
  7. root> show system software backup
  8. Backup JUNOS package information:
  9. File name: /altroot/cf/packages/junos-15.1X49-D80.4-domestic
  10. File size: 249978054

And that’s it.