Archive for the ‘linux’ Category

IPv6 solution for provider only providing a /64

Wednesday, May 20th, 2026

So, ChatGPT kept giving me *terrible* advice for what to do when a provider provides only a /64 and you have a firewall in front of your LAN.

The solution is actually fairly straightforward, providing you are using static or DHCP assigned addresses:

0) Turn on routing and proxy ndp:


net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.all.proxy_ndp=1

1) Install ndppd.conf with a config file similar to this:


route-ttl 30000

proxy ens192 {
router yes
timeout 500

rule 2605:9f80:2000:110::/64 {
static
}
}

2) Create a interface on the upstream side of the firewall that is 2605:9f80:2000:110::2/64
3) Create a interface on the downstream side of the firewall that is 2605:9f80:2000:110:8000::1/65
4) Assign addresses inside that /65 to other things on the LAN

Advantages over the ChatGPT suggested solution of manually entering a /128 route and creating a /128 entry and adding a fd00 interface to every host:

#1: It keeps the wire settigns “honest”. Setting a /128 for each host means you are lying to the host about the wire. This can cause local traffic problems even if the router does route single-homed traffic

#2: It’s *simple*. Set it up once, forget about it. Minimal configuration needed. No need to add additional configuration to the router as you add each host.

#3: It fits conventional subnetting rules. Even though normally one never assigns ipv6 smaller than a /64 so that self-addressing can work correctly, if one is using statics or a DHCP server this works just fine, while also fitting the way we usually subnet IP networks.

Setting a static IP on ubuntu 20.04 with cloud-init

Friday, February 11th, 2022

So, it took me numerous tries, digging, and beating of head against curtin and the like, but I have finally figured out how to set a static IP on a host using cloud-init.

Mind you, I am not talking about setting a static iP for while the installer is running. That’s easy, and well documented. I’m talking about the next time it boots.

The solution requires two bits. They’re pretty straightforward, and both go in the cloud-init file

Bit one goes at the end of the autoinstall section, and deletes the default configuration and writes a permanent one instead. Note that the filesystem is mounted as /target


late-commands:
– rm /target/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg
– mv /tmp/00-installer-config.yaml /target/etc/netplan

Bit two actually writes out the /tmp/00-installer-config.yaml that late-commands will be editing


write_files:
– path: /tmp/00-installer-config.yaml
owner: root:root
permissions: “0644”
content: |
network:
version: 2
ethernets:
ens160:
critical: true
dhcp-identifier: mac
dhcp4: true
ens192:
dhcp4: no
addresses:
– {ipaddr}/16
gateway4: 172.16.1.1
nameservers:
addresses:
– 172.16.5.6
search:
– search.domain

haproxy and unable to load SSL certificate (weird one)

Friday, June 1st, 2018

So, I was setting up a haproxy this morning and I was having a heck of a time getting it to load the SSL Certificate. I kept getting “Unable to load SSL certificate”, which was not a phrase google was helping me with.

It turned out that the BEGIN CERTIFICATE line, as issued from namecheap, only had four ‘-‘ characters where haproxy wanted to see five. I also couldn’t do a openssl x509 -text -in, I would get the error “140146308224672:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE”.

So, that’s a hour of my life I’ll not get back, but hopefully someone else will now find this problem on google.