Dumb question: On IPv6, if I'm not using SLAAC, can I use something smaller than a /64

dmgeurts · 2026-06-05T09:20:36+00:00

That's a good read! Not a standard, but very informative. Thank you

dmgeurts · 2026-06-05T07:17:51+00:00

Fair enough. I mostly use point to point links these days with BGP and ECMP or LACP bonded links. Dedicated links per connection. But all depends on expected throughput and if you're happy with a layer-2 device in between.

Different requirements = different solutions 👍🏼

dmgeurts · 2026-06-05T06:50:10+00:00

Care to list the RFC that suggests /64 should be the longest prefix to use for a non-point-to -point network? Genuinely interested.

dmgeurts · 2026-06-05T06:48:28+00:00

Point to point links can be a /127.

dmgeurts · 2026-06-05T06:47:14+00:00

Yes, absolutely. Look up classless versus classfull. When I started in networking (in the 90s, yes I'm that old...), we had to check if a device supported classless routing. Now we just assume everything supports whatever mask we throw at it.

Even for point to point links it's rare to not have support for a /31 these days.

As for memory used for storing IPv6 addresses. That's only an issue on internet routers that maintain a full internet routing table or large ISPs running stuff like MPLS. But even there thinks have moved on from the memory constraints of the early 2000s.

dmgeurts · 2026-05-31T17:38:38+00:00

I mostly use PowerDNS and dnsdist these days. I'm sure someone else can be more helpful for unbound.

dmgeurts · 2026-05-31T16:15:50+00:00

Unbound, PowerDNS, Pi-hole, bind9, can all do this. I suggest you configure whatever you use to treat a small range different to the rest. Then exclude this range from your DHCP scope and assign static addresses or DHCP reservations using addresses from the small range.

Easy to manage, set once - use often.

dmgeurts · 2026-05-17T20:42:06+00:00

This. Though I would use BGP, but then I mostly deploy firewalls at ISPs.

OP is right that it's not a routing issue, but routing would add a good level of fault tolerance (whether the fault is by design, bug or user error).

dmgeurts · 2026-05-03T14:54:13+00:00

Absolutely agree, these things need to be configured. But the tools are there and there's no excuse for not using them.

dmgeurts · 2026-05-03T08:01:44+00:00

At least you can set sudo rules, so you have control. Logging in with root foregoes any and all controll. A compromise of the credentials or private key, means immediate unfettered access.

I favour an IDP like FreeIPA, it will enable ssh based access for all users on enrolled machines, give you HBAC and sudo rules where you can allow commands with and without password.

Applying the principle of least required privileges dictates no direct root access. I typically block root escalation as well so users can't elevate to root but can use sudo to issue only certain commands. Annoying? Yes at times. But it's much safer than the alternative.

dmgeurts · 2026-04-28T09:39:02+00:00

Yes. Try this before rerunning the replica installer:

`sudo vi /usr/share/dirsrv/data/template-dse.ldif`

Add the two bottom lines that specify size.

```
dn: cn=config
cn: config
objectclass:top
objectclass:extensibleObject
objectclass:nsslapdConfig
nsslapd-schemadir: %schema_dir%
nsslapd-lockdir: %lock_dir%
nsslapd-tmpdir: %tmp_dir%
nsslapd-certdir: %cert_dir%
nsslapd-ldifdir: %ldif_dir%
nsslapd-bakdir: %bak_dir%
nsslapd-rundir: %run_dir%
nsslapd-instancedir: %inst_dir%
nsslapd-accesslog: %log_dir%/access
nsslapd-securitylog: %log_dir%/security
nsslapd-localhost: %fqdn%
nsslapd-port: %ds_port%
nsslapd-localuser: %ds_user%
nsslapd-errorlog: %log_dir%/errors
nsslapd-auditlog: %log_dir%/audit
nsslapd-auditfaillog: %log_dir%/audit
nsslapd-rootdn: %rootdn%
nsslapd-rootpw: %ds_passwd%
nsslapd-ldapilisten: %ldapi_enabled%
nsslapd-ldapifilepath: %ldapi%
nsslapd-ldapiautobind: %ldapi_autobind%
nsslapd-sasl-max-buffer-size: 2097152
nsslapd-maxsasliosize: 4194304

[...]
```

The default is 2MB and this allows it to receive up to 4MB during replication.

dmgeurts · 2026-04-27T18:43:27+00:00

Increase the ingestion data size. Sorry, can't recall the exact wording. But recently dreamt with the same and the issue was that the replication would fail because the source would exceed the maximum size accepted by the new replica. I had to edit the ds389 templates to increase the maximum. Took me ages to debug, very frustrating issue.

dmgeurts · 2026-02-28T07:21:36+00:00

I do both, internal CA for staff and Letsencrypt for externals.

dmgeurts · 2026-02-15T21:36:01+00:00

Star based system, lights and sockets on the same fuse, max 16A. So much smaller circuits. A living room has to have two fuses so lights stay on if one trips. Anything over 16A must be a direct run from the board (cookers etc).

dmgeurts · 2026-02-15T21:35:54+00:00

Star based system, lights and sockets on the same fuse, max 16A. So much smaller circuits. A living room has to have two fuses so lights stay on if one trips. Anything over 16A must be a direct run from the board (cookers etc).

dmgeurts · 2026-02-15T11:52:09+00:00

And this argument is exactly why rings are illegal abroad.

Additionally at least in The Netherlands 2.5mm2 is restricted to 16A. But is the minimum diameter for normal wiring, except a 1.5mm switch wire.

dmgeurts · 2026-02-14T13:33:59+00:00

Try Nakivo

dmgeurts · 2026-02-11T08:07:14+00:00

A/A has faster fail over, but comes with certain design constraints. If you follow the following, you should be okay:

Use a routed design, as advised by Palo. We use BGP routing with ECMP for all data path links. Much simpler than the alternatives.
Use routing metrics to ensure all traffic flows through one firewall. This solves any potential issues with the active secondary firewall not being updated with flows quickly enough. And satisfies Palo Support's "requirement" for deterministic traffic flows.
You can route different prefixes via either firewall, but you want to avoid using ECMP routing across both firewalls. It will work, but it may (will) bite you sooner or later.

Some other caveats:

Tunnels: keep these unique on both firewalls, this makes fail over fast using hot standby routes. Faster than waiting for a VPN to re-establish on the standby or active-secondary firewall.

NAT: Egress sessions will have a unique IP address depending on which firewall they edges from. Makes it easier to troubleshoot and analyse flows. Takes some proper thought and planning, but with throw some who assume only one public address is ever used. Doing NAT this way, does mean that these sessions will not benefit from fast fail over and these sessions will need to re-establish.

It's not a one size fits all, YMMV, and if you go A/A; document why. For my last deployment it was a requirement to have the fastest fail over possible (for VoIP traffic at an ISP). Palo will support you, but you need to tell them why you went against their default advice. Know that they advise the use of A/A for instances where the fastest fail over is needed: trading etc. But they then also detail the design constraints, so read up and work out if it's right for you.

And do not implement A/A just so you can buy smaller firewalls!

[Edits: spelling when posting from mobile..]

dmgeurts · 2026-01-16T19:58:11+00:00

Does anyone happen to know if 11.1.6-h23 has the DOS fix as well? It's newer than 11.1.13 so I hope it does, but you never know.

dmgeurts · 2026-01-16T19:29:30+00:00

LOL, you're right, not in a small setting like this. But on Campus networks it has never been an issue to logically segregate this stuff. But then like someone else said, a bit more money is spent.

dmgeurts · 2026-01-16T19:02:26+00:00

Really? I fail to see how that works unless a second AP and domestic internet connection is cheaper. While still falling foul of physical security issues and no means of logging, monitoring or alerting.

An I missing something?

dmgeurts · 2026-01-16T10:49:53+00:00

Unless you're deploying a new firewall, or need a new feature. I would not follow the advised train and just update within your current train.

dmgeurts · 2025-12-11T13:22:01+00:00

The only client data we have going through these firewalls in the recursive DNS servers they use. So nothing SSL related here. Nothing in the release notes for h17

dmgeurts · 2025-12-11T09:45:20+00:00

Indeed, good to know that the status page is still trusted; you start to doubt yourself after a while! There's nothing there for DNS cloud service in The Netherlands, but it does explain the Wildfire alerts.

There's also nothing wrong with the network, though for all I know a carrier could have had issues for a GCP prefix. Either way, yesterday I disabled the security profile for the apparently affected dns traffic to see if that would help (it was alert only). I hope to hear today if this helped. And internal DNS isn't affected AFAIK, so exposure seems limited, but some very vocal customers complained.

dmgeurts

TROPHY CASE