Lxd "routed" interface config - problem w Ubuntu 20.04 Host and WiFi

I am using Ubuntu 20.04 on Host & Container and SNAP LXD v4.4

I followed Simos’ great writeup:
How to get LXD containers get IP from the LAN with routed network – Mi blog lah!

Note: I and several others posted “comments” on the above article:
have WiFi and not Ethernet on our Hosts! There are also several comments including one from myself that there seems to be a problem with Ubuntu 20.04? I do understand Host/WiFi Mac restriction,

When I used the above Guide to configure LXD routed in 20.04 changing the Device section to specify parent: wlp3s0 instead of parent: ensp6s0

config:
  user.network-config: |
    version: 2
    ethernets:
        eth0:
            addresses:
            - 192.168.1.200/32
            nameservers:
                addresses:
                - 8.8.8.8]
            routes:
            -   to: 0.0.0.0/0
                via: 169.254.0.1
description: Default LXD profile
devices:
  eth0:
    ipv4.address: 192.168.1.200
    nictype: routed
    ***parent: wlp3s0***
    type: nic
name: routed_192.168.1.200
used_by:

Everything seemed to work.

  • My container “test” did get 192.168.1.200 as its IP Address that was configured into the profile.

  • I was able to Ping the Test container from the Host.

  • From the Container Test I was able to Ping both my Host and my WiFi Router.

  • But I am not able to Ping anything on the Internet (example: google.com)

Anybody have any ideas why or what to check?

Brian

Are you able to ping IPs, e.g. 8.8.8.8 and just not DNS names? If so have you checked your container’s DNS config as routed NICs can’t set that.

@tomp
jeez you beat me to it :slight_smile:
I’d just tried that and yes I can ping 8.8.8.8
but I can’t ping DNS names

Tom - however, there still is some problem with using @simos guide when using Ubuntu 20.04 and as I mentioned in the original post if you go to Simo’s blog you will see 3 or 4 of us all having “a problem” with 20.04 containers getting routed to work whereas it does work with 18.04 containers

It looks there is a typo here? The ]. That typo can explain that routed works, but the profile fails to set the DNS server in the container, hence you cannot ping hostnames.

1 Like

Creating a routed container with Ubuntu 18.04 and Ubuntu 20.04:

Container with Ubuntu 18.04

ubuntu@myrouted:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5a:e4:ab:b5:cc:e9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.2.200/32 brd 255.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::58e4:abff:feb5:cce9/64 scope link 
       valid_lft forever preferred_lft forever
ubuntu@myrouted:~$ ip route
default via 169.254.0.1 dev eth0 
ubuntu@myrouted:~$ systemd-resolve --status
Global
          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 (eth0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
ubuntu@myrouted:~$ 

Container with Ubuntu 20.04

ubuntu@myrouted:/home/ubuntu$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2e:9d:f9:03:14:62 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.2.200/32 brd 255.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2c9d:f9ff:fe03:1462/64 scope link 
       valid_lft forever preferred_lft forever
ubuntu@myrouted:/home/ubuntu$ ip route
ubuntu@myrouted:/home/ubuntu$ systemd-resolve --status
Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          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 (eth0)
      Current Scopes: DNS    
DefaultRoute setting: yes    
       LLMNR setting: yes    
MulticastDNS setting: no     
  DNSOverTLS setting: no     
      DNSSEC setting: no     
    DNSSEC supported: no     
  Current DNS Server: 8.8.8.8
         DNS Servers: 8.8.8.8
ubuntu@myrouted:/home/ubuntu$ 

The issue looks like iproute2 in Ubuntu 20.04 (version 5.5.0) is more restrictive in setting the gateway than iproute2 4.15.0 in Ubuntu 18.04.
The error is Error: Nexthop has invalid gateway..
There should be some reading or googling on the new iproute2 to find how to resolve this issue.

@bmullan

The fix for this is to add on-link: true to the netplan config via cloud-init, e.g.

config:
  user.network-config: |
    version: 2
    ethernets:
        eth0:
            addresses:
            - 192.168.1.201/32
            nameservers:
                addresses:
                - 8.8.8.8
            routes:
            -   to: 0.0.0.0/0
                via: 169.254.0.1
                on-link: true
devices:
  eth0:
    ipv4.address: 192.168.1.201
    nictype: routed
    parent: enp3s0
    type: nic

Tested working in focal and bionic.

I updated the post with the on-link: true line, https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/

1 Like

Thanks Simos & Tom
Sorry for the late reply but I’d lost power for a couple days.

@simos
@tomp

This is still not working for me using 20.04 host, a new profile including the “on-link: true” 20.04 container

I hope the following is enough information to perhaps let me know what might be the problem.

Sorry this linux forum editor deletes the preceeding “spaces” in the config lines.

I have recreated everything using Simo’s updated Blog post which now includes
the “on-link: true”.

Created a container name test, using the default and routed-profile

In the container I named test:

I can Ping my Host…

root@test:~# ping 192.168.1.81
PING 192.168.1.81 (192.168.1.81) 56(84) bytes of data.
64 bytes from 192.168.1.81: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from 192.168.1.81: icmp_seq=2 ttl=64 time=0.057 ms
^C
— 192.168.1.81 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.053/0.055/0.057/0.002 ms

I can Ping google Name Server by IP…

root@test:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=26.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=28.5 ms
^C
— 8.8.8.8 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 26.555/27.522/28.489/0.967 ms

I still cannot Ping google by Name

root@test:~# ping www.google.com
ping: www.google.com: Temporary failure in name resolution

All of the previously recommended Profile config info is below.

I am using my WiFi

==============================================================================

My newly created profile which includes (on-link: true)

## This is a YAML representation of the profile.
### Any line starting with a '# will be ignored.
###
### A profile consists of a set of configuration items followed by a set of
### devices.
###
### An example would look like:
### name: onenic
### config:
### raw.lxc: lxc.aa_profile=unconfined
### devices:
### eth0:
### nictype: bridged
### parent: lxdbr0
### type: nic
###
### Note that the name is shown but cannot be changed

config:
user.network-config: |
version: 2
ethernets:
eth0:
addresses:
- 192.168.1.200/32
nameservers:
addresses:
- 8.8.8.8
search: []
routes:
- to: 0.0.0.0/0
via: 169.254.0.1
on-link: true
description: Default LXD profile
devices:
eth0:
ipv4.address: 192.168.1.200
nictype: routed
parent: wlp3s0
type: nic
name: routed
used_by:

  • /1.0/instances/test

==============================================================================

in container:

/etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run “resolvectl status” to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0

# systemd-resolve --status
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
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 (eth0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 8.8.8.8
DNS Servers: 8.8.8.8

==============================================================================

in container:

/etc/netplan/50-cloud-init.yaml

# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init’s
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
addresses:
- 192.168.1.200/32
nameservers:
addresses:
- 8.8.8.8
search: []
routes:
- on-link: true
to: 0.0.0.0/0
via: 169.254.0.1
version: 2

==============================================================================

In the contain named “test”

root@test:~# ip route
default via 169.254.0.1 dev eth0 proto static onlink

Have you checked its not the firewall on the LXD host blocking DNS requests being forwarded?

@tomp
@simos

$ sudo ufw status numbered
Status: active

 To                         Action      From
 --                         ------      ----

[ 1] 80/tcp ALLOW IN Anywhere
[ 2] 443/tcp ALLOW IN Anywhere
[ 3] 4443/tcp ALLOW IN Anywhere
[ 4] 10000/udp ALLOW IN Anywhere
[ 5] 22/tcp ALLOW IN Anywhere
[ 6] 80 DENY IN Anywhere
[ 7] 443 DENY IN Anywhere
[ 8] 4443 DENY IN Anywhere
[ 9] 10000 DENY IN Anywhere
[10] 80/tcp (v6) ALLOW IN Anywhere (v6)
[11] 443/tcp (v6) ALLOW IN Anywhere (v6)
[12] 4443/tcp (v6) ALLOW IN Anywhere (v6)
[13] 10000/udp (v6) ALLOW IN Anywhere (v6)
[14] 22/tcp (v6) ALLOW IN Anywhere (v6)
[15] 80 (v6) DENY IN Anywhere (v6)
[16] 443 (v6) DENY IN Anywhere (v6)
[17] 4443 (v6) DENY IN Anywhere (v6)
[18] 10000 (v6) DENY IN Anywhere (v6)

Sorry but what command is used to do that?

Are you talking about installing Bind9 and then:

$ sudo vi /etc/bind/named.conf.options

options{
directory “/var/cache/bind”;
recursion yes;
allow-query { 192.168.0.0/32; 127.0.0.1; };
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only;

}

No I mean, your container config looks fine:

  • IPs set correctly
  • Default route set correctly
  • External ping confirmed working to DNS server
  • DNS settings applied correctly

So the question is “why do DNS packets to 8.8.8.8 get dropped, but not ICMP packets?”.

And the next thing to check to answer that, imho, is do you have a firewall running on the LXD host that could be blocking your LXD host from forwarding (routing) DNS packets.

@tomp
@simos

I thought I’d read that one of the benefits of the routed interface was that the Container using “routed” would have the same MAC as the Host’s Internet interface whether that was ETH or WiFi?

Which made it particularly useful for WiFi vs macvlan or bridged.

I’m not sure where or if I really read that somewhere.

However, which of the “routed” container’s Interfaces gets the “same” MAC as the Host WiFi interface?
The “routed” container’s assigned IP ETH0 interface or the “routed” container’s VETH interface?

Yes that is correct, because the LXD host acts as a router and uses proxy ARP to advertise the container’s IP on the parents network using the LXD host’s interface on that parent network, all containers appear to have the same MAC address as the LXD host on the parent network.

But both the actual eth0 interface inside the container and the other end of the veth pair on the host will have a different (random) MAC than the host and other containers, but that is just used for point-to-point connection back to the host, so the wider network will never see those.

@tomp

You were right it has to be something in LXD Host’s Firewall.
I disabled the Host Firewall, rebooted, then both:

# ping 8.8.8.8
and
# ping google.com

both worked in the Container when the Host’s firewall was disabled.

thanks so much Tom !

@tomp
@simos

I tried to just parse “$ sudo iptables -L” output from the host but that is ridiculously long.

So I install GUFW instead as it summarizes the Host Firewall tremendously:

My Host’s Firewall Rules:
gufw rules

My Host’s Firewall Report

Only in the Report do you see multiple entries for:

  • TCP port 53 and UDP port 5353
  • UDP port 53 and UDP port 5353

But those entries are used by DNSMASQ, AVAHI and KVM/Virt (182.168.122.1)

Can you show the output of iptables-save please?

@tomp

**From Host ($ iptables-save)**

\# **Generated by iptables-save v1.8.4 on Wed Aug 19 05:25:36 2020**
*mangle
:PREROUTING ACCEPT [8380:6023445]
:INPUT ACCEPT [8378:6023074]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8403:1194600]
:POSTROUTING ACCEPT [8542:1210586]
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
\# Completed on Wed Aug 19 05:25:36 2020
\# Generated by iptables-save v1.8.4 on Wed Aug 19 05:25:36 2020
*nat
:PREROUTING ACCEPT [86:24413]
:INPUT ACCEPT [23:4322]
:OUTPUT ACCEPT [1244:91623]
:POSTROUTING ACCEPT [1237:90307]
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
\# Completed on Wed Aug 19 05:25:36 2020
\# Generated by iptables-save v1.8.4 on Wed Aug 19 05:25:36 2020
*filter
:INPUT DROP [64:20542]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [25:1032]
:LIBVIRT_FWI - [0:0]
:LIBVIRT_FWO - [0:0]
:LIBVIRT_FWX - [0:0]
:LIBVIRT_INP - [0:0]
:LIBVIRT_OUT - [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j LIBVIRT_INP
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j LIBVIRT_OUT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 4443 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 10000 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -j DROP
-A ufw-user-input -p udp -m udp --dport 80 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 443 -j DROP
-A ufw-user-input -p udp -m udp --dport 443 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 4443 -j DROP
-A ufw-user-input -p udp -m udp --dport 4443 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 10000 -j DROP
-A ufw-user-input -p udp -m udp --dport 10000 -j DROP
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
\# Completed on Wed Aug 19 05:25:36 2020

I would say the issue is that your default FORWARD chain policy is DROP.

1 Like

@tomp

I would say the issue is that your default FORWARD chain policy is DROP .

Is that a normal “default” with ubuntu firewalls?

I certainly don’t think I’ve ever touched that.

I’ll change it and hopefully that fixes my problem. I’ll let you know Tom. Thanks