Ah yes indeed, I just tested, keeps working fine! Ignore my remarks, sorry for the noise.

If you want to NAT them, route them, i.e. do not include the LAN NIC in the bridge and set net.inet.ip.forwarding=1.

Outgoing traffic from a private address from the bridge to the internet needs to pass the firewall so that I can be NAT-ed.
EG: 10.0.0.1 on the bridge for the host, 10.0.0.2 in the VM/VNET jail with 10.0.0.1 as gateway, trying to reach the public address space.
Is this so ew? As this is what I use right now :-D, I really thought it was common?

This is fine but needs a serious UPDATING entry and RELNOTES. People running vm's of a bridge that uses private addresses and use any firewall for NAT-ing trafic will need to enable it themselves, or no NAT will happen.

I'm from the opinion to keep this instruction as simple as possible.
The handbook has some extra steps for switching from mergemaster to etcupdate where an "etcupdate extract" is required.
As @jhb pointed out, bootstrapping should not be required for any recent release.

Thanks for the good work Ben.

That was indeed the outcome as you see this discussion: https://github.com/NetworkConfiguration/dhcpcd/issues/59

Landed in https://cgit.freebsd.org/ports/commit/?id=8435c15b9b9edb0a5037e2bcc3c6ac2ffb214015

Thanks for the review, will wait a few days for others to possibly shime in.

Actually fix it (@FreeBSD)

@FreeBSD not @Freeebsd

• Use decent versioning based on git describe --tags
• Drop upgrade note as its a new port

fix plist

@melifaro do you plan to pick this up again?