Proxmox: Shrinking disk of an LVM backed container

First, shut down the container and ensure it’s not running.

List out the LVM logical volumes:

  1. lvdisplay | grep "LV Path\|LV Size"

Choose the disk you want to resize – you’ll see they’re named by container ID and disk number. For example, /dev/vg0/vm-205-disk-1.

Check and fix the filesystem, just incase:

  1. e2fsck -fy /dev/vg0/vm-205-disk-1

Resize the file system. It is advisable, at this point, to set this to 1GB smaller than you actually want it (e.g. 7G when you want 8G):

  1. resize2fs /dev/vg0/vm-205-disk-1 7G

Resize the LVM LV to the actual size you want it to be:

  1. lvreduce -L 8G /dev/vg0/vm-205-disk-1

Resize the file system to fill the LVM LV:

  1. resize2fs /dev/vg0/vm-205-disk-1

Finally, edit the configuration for the container such that Proxmox reports the correct size for the disk. You will find this at /etc/pve/lxc/205.conf where 205 is your container ID.

You can now start your container and check the disks’ sizes:

  1. df -h

Proxmox Containers: Manage network interfaces file yourself

Proxmox will manage the network interfaces file (/etc/network/interfaces on Debian) for you, on containers. This is sometimes annoying – for example when you want to add static routes with a post-up.

If you simply touch /etc/network/.pve-ignore.interfaces inside the container then it will let you manage it yourself and will thus obey any post-up lines that you add.

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:


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 to your bad_clients file will also match 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.

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 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;