@juliank - note I wasn't so much talking about 'blame' as much as understanding, so I apologize if it came across that way. Since I wasn't able to reproduce, I was trying to reason through my thoughts to help the discussion go further since I'm not able to diagnose it myself.

In a nutshell, I have concerns that the ufw service has a side effect that somewhere else in the system is dependent on. That other part of the system should be setup to work without ufw in the mix. I'm also concerned that users might face issues if ufw is purged or if other similarly configured software is installed (eg, firewalld).

With that in mind, it seems odd that a service that does nearly nothing by default would affect the system by having a Before/Wants on network-pre.target.

It also seems odd that going from very little dependencies (DefaultDependencies=no) to have only those for 'basic system initialization' would be a problem since those are not related to networking, etc. Eg, in today's autopkgtest jammy instance that I created with `autopkgtest-buildvm-ubuntu-cloud -r jammy` and rebooting with the proposed -3 of ufw installed:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu Jammy Jellyfish (development branch)
Release:	22.04
Codename:	jammy

$ cat /proc/version_signature 
Ubuntu 5.13.0-19.19-generic 5.13.14

$ systemctl list-dependencies ufw.service
ufw.service
● ├─system.slice
● ├─network-pre.target
● └─sysinit.target
●   ├─apparmor.service
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─keyboard-setup.service
●   ├─kmod-static-nodes.service
●   ├─multipathd.service
●   ├─plymouth-read-write.service
○   ├─plymouth-start.service
●   ├─proc-sys-fs-binfmt_misc.automount
●   ├─setvtrgb.service
●   ├─sys-fs-fuse-connections.mount
●   ├─sys-kernel-config.mount
●   ├─sys-kernel-debug.mount
●   ├─sys-kernel-tracing.mount
●   ├─systemd-ask-password-console.path
○   ├─systemd-binfmt.service
○   ├─systemd-boot-system-token.service
●   ├─systemd-journal-flush.service
●   ├─systemd-journald.service
○   ├─systemd-machine-id-commit.service
●   ├─systemd-modules-load.service
○   ├─systemd-pstore.service
●   ├─systemd-random-seed.service
●   ├─systemd-sysctl.service
●   ├─systemd-sysusers.service
●   ├─systemd-timesyncd.service
●   ├─systemd-tmpfiles-setup-dev.service
●   ├─systemd-tmpfiles-setup.service
●   ├─systemd-udev-trigger.service
●   ├─systemd-udevd.service
●   ├─systemd-update-utmp.service
●   ├─cryptsetup.target
●   ├─local-fs.target
●   │ ├─-.mount
●   │ ├─boot-efi.mount
○   │ ├─systemd-fsck-root.service
●   │ └─systemd-remount-fs.service
●   ├─swap.target
●   └─veritysetup.target

Seeing what depends on ufw, there is very little:
$ systemctl list-dependencies ufw.service --reverse
ufw.service
● └─multi-user.target
●   └─graphical.target

I can also say that nothing in this VM depends on network-pre other than ufw:
$ systemctl list-dependencies --reverse network-pre.target
network-pre.target
● └─ufw.service

and that there is not much depending on network.target:
$ systemctl list-dependencies --reverse network.target
network.target
○ ├─netplan-ovs-cleanup.service
● └─systemd-networkd.service

Rebooting with ufw -2 installed, all of the above is the same except ufw's dependencies are nearly nothing:
$ systemctl list-dependencies ufw.service
ufw.service
● └─system.slice

This autopkgtest VM doesn't have cloud-init installed (which is consistent with why I'm not seeing it in here like I am not in Debian) and I don't know what cloud-init config to provide to provide any additional diagnosis. I can say that if I install cloud-init, it add a dependency on on network-pre.target (still with -2 of ufw):

$ systemctl list-dependencies network-pre.target --reverse
network-pre.target
○ └─cloud-init-local.service

It has:
$ cat /usr/lib/systemd/system/cloud-init-local.service 
[Unit]
Description=Initial cloud-init job (pre-networking)
DefaultDependencies=no
Wants=network-pre.target
After=hv_kvp_daemon.service
After=systemd-remount-fs.service
Before=NetworkManager.service
Before=network-pre.target
Before=shutdown.target
Before=sysinit.target
Conflicts=shutdown.target
RequiresMountsFor=/var/lib/cloud

[Service]
Type=oneshot
ExecStart=/usr/bin/cloud-init init --local
ExecStart=/bin/touch /run/cloud-init/network-config-ready
RemainAfterExit=yes
TimeoutSec=0

# Output needs to appear in instance console output
StandardOutput=journal+console

[Install]
WantedBy=cloud-init.target

I notice that it has a `Before=sysinit.target` and DefaultDependencies=no.

Is cloud-init in our infrastructure configured to run ufw?