Ubuntu 20.04 server suddenly can nolonger connect to anything at all on IPv4

... but I can SSH and use webmin on it just fine over IPv4?? I cant ping anything at all and of course DNS just flat fails as a result. The only addresses I can ping are local 127.0.0.xx and the server's current address. I can however ping other devices via IPv6.

The server was working perfectly fine, the only change that had occurred recently was a heap of updated packages, however after updating it was still working then, but today after powering it back up it can nolonger connect to anything, but while still allowing other devices to connect to it.

ifconfig;

enp9s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.180  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2001:8003:c41d:c901:b62e:99ff:feeb:8130  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::b62e:99ff:feeb:8130  prefixlen 64  scopeid 0x20<link>
        ether b4:2e:99:eb:81:30  txqueuelen 1000  (Ethernet)
        RX packets 21628  bytes 2650641 (2.6 MB)
        RX errors 0  dropped 5  overruns 0  frame 0
        TX packets 12090  bytes 4100693 (4.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 13474  bytes 1095065 (1.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13474  bytes 1095065 (1.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

resolvectl;

Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 10.0.0.138
         DNS Servers: 10.0.0.138
          DNS Domain: Hancock
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (enp9s0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 127.0.0.53
         DNS Servers: 127.0.0.53
                      10.0.0.138
          DNS Domain: Hancock

Of course if it cant ping the gateway, 10.0.0.138, then it wont be able to retrieve DNS records from it either, and of course other IPv4 DNS servers cannot be reached, but I have no idea why IPv4 isn't working now...

Oh and don't worry about seeing my IP's as they change regularly.

uuuhm, so it turns out there's some kind of new bug somewhere in IPTABLES or even the kernel, no idea where specifically, but the work around is to manually add accept all, anywhere, ctstate ESTABLISHED, on the INPUT chain, because apparently this is needed now for v4 connections to work properly, even though you could connect into the server just fine already.

This doesn't seem to be needed for ip6tables, or otherwise my existing v6 settings were just overriding it somehow. It only affected v4 connections going out from the server, and not ones coming in via the usual ssh, web, webmin, etc. One other workaround I had was to change my router settings to add IPv6 DNS IP's to the clients, which in turn bypassed the DNS issue on the server and allowed it to make full v6 connections, so most of the package archives were accessible for example, so long as they were accessible via v6, even though the ESTABLISHED state rule wasn't present in ip6tables's INPUT.