Hey guys, so I’ve been trying the Oracle Free Tier servers but I’ve noticed that when I create an LXC container it has no ip address. I’ve tested this on about 3 different servers but all give the same result.
I’m running Ubuntu 22.04. I’m also trying to launch Ubuntu 22:04 containers.
Usual suspects for that would be Docker or UFW blocking the network traffic between the container and the host.
I’m also having the same issue on Oracle Cloud.
Oracle Cloud Ubuntu instances come with a lot of iptables rules, but it’s not easy to figure out why it’s not working.
For example, this is what I get from iptables:
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 10.0.0.0/16 anywhere tcp dpt:8443 state NEW /* Victor: allow lxd cluster */
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp spt:ntp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
InstanceServices all -- anywhere link-local/16
Chain InstanceServices (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 169.254.0.2 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.2.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.4.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.5.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.0.2 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT udp -- anywhere 169.254.169.254 udp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.169.254 tcp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.0.3 owner UID match root tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.0.4 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT tcp -- anywhere 169.254.169.254 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT udp -- anywhere 169.254.169.254 udp dpt:bootps /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT udp -- anywhere 169.254.169.254 udp dpt:tftp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT udp -- anywhere 169.254.169.254 udp dpt:ntp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
REJECT tcp -- anywhere link-local/16 tcp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with tcp-reset
REJECT udp -- anywhere link-local/16 udp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with icmp-port-unreachable
I added the first line since I’m using a cluster.
I’ll add below information which might be relevant. It should be noted that Oracle does not recommend ufw since it might break their iptables rules. I never touched ufw on my instances.
$ systemctl status ufw.service
● ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2022-07-10 11:53:03 UTC; 1 day 14h ago
Docs: man:ufw(8)
Main PID: 735 (code=exited, status=0/SUCCESS)
CPU: 2ms
Jul 10 11:53:03 arm1 systemd[1]: Starting Uncomplicated firewall...
Jul 10 11:53:03 arm1 systemd[1]: Finished Uncomplicated firewall.
$ snap list
Name Version Rev Tracking Publisher Notes
core18 20220428 2406 latest/stable canonical✓ base
core20 20220527 1522 latest/stable canonical✓ base
lxd 5.0.0-b0287c1 22927 5.0/stable/… canonical✓ -
oracle-cloud-agent 1.24.0-1 41 latest/stable/… oci.osi classic
snapd 2.56.2 16299 latest/stable canonical✓ snapd
$ lxc cluster list
+------+-------------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| NAME | URL | ROLES | ARCHITECTURE | FAILURE DOMAIN | DESCRIPTION | STATE | MESSAGE |
+------+-------------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| amd1 | https://10.0.1.135:8443 | database | x86_64 | default | | ONLINE | Fully operational |
+------+-------------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| amd2 | https://10.0.1.85:8443 | database | x86_64 | default | | ONLINE | Fully operational |
+------+-------------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| arm1 | https://10.0.1.233:8443 | database-leader | aarch64 | default | | ONLINE | Fully operational |
| | | database | | | | | |
+------+-------------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
$ lxc profile show default
config: {}
description: Default LXD profile
devices:
eth0:
name: eth0
network: lxdfan0
type: nic
root:
path: /
pool: local
type: disk
name: default
used_by:
- /1.0/instances/ceph-arm1
- /1.0/instances/ceph-amd1
- /1.0/instances/ceph-amd2
$ lxc list
+-----------+---------+------+------+-----------+-----------+----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
+-----------+---------+------+------+-----------+-----------+----------+
| ceph-amd1 | RUNNING | | | CONTAINER | 0 | amd1 |
+-----------+---------+------+------+-----------+-----------+----------+
| ceph-amd2 | RUNNING | | | CONTAINER | 0 | amd2 |
+-----------+---------+------+------+-----------+-----------+----------+
| ceph-arm1 | RUNNING | | | CONTAINER | 0 | arm1 |
+-----------+---------+------+------+-----------+-----------+----------+
$ lxc network info lxdfan0
Name: lxdfan0
MAC address: 00:16:3e:3d:c7:d9
MTU: 8950
State: up
Type: broadcast
IP addresses:
inet 240.233.0.1/8 (global)
inet6 fe80::216:3eff:fe63:e558/64 (link)
Network usage:
Bytes received: 435.46kB
Bytes sent: 4.18kB
Packets received: 1390
Packets sent: 56
Bridge:
ID: 8000.00163e3dc7d9
STP: false
Forward delay: 1500
Default VLAN ID: 1
VLAN filtering: true
Upper devices: lxdfan0-fan, lxdfan0-mtu, veth6bf4ca25
$ lxc exec ceph-arm1 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
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:fb:2e:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::216:3eff:fefb:2eb6/64 scope link
valid_lft forever preferred_lft forever
This comment has made me very intrigued, but at the same time quite confused.
On this link you provided, it states the following:
By default, managed LXD bridges add firewall rules to ensure full functionality. If you do not run another firewall on your system, you can let LXD manage its firewall rules.
Since I never touched this, I’m assuming lxd added firewall rules somewhere. But where are they?
They don’t seem to be on iptables.
$ sudo iptables -vL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
19671 1180K ACCEPT tcp -- any any 10.0.0.0/16 anywhere tcp dpt:8443 state NEW /* Victor: allow lxd cluster */
14M 3167M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
3 252 ACCEPT icmp -- any any anywhere anywhere
7456 696K ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:ntp
1599 88360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ssh
2327 745K REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 14M packets, 2945M bytes)
pkts bytes target prot opt in out source destination
28208 2161K InstanceServices all -- any any anywhere link-local/16
Chain InstanceServices (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- any any anywhere 169.254.0.2 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.2.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.4.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.5.0/24 owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.0.2 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
4731 505K ACCEPT udp -- any any anywhere 169.254.169.254 udp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.169.254 tcp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.0.3 owner UID match root tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- any any anywhere 169.254.0.4 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
23376 1648K ACCEPT tcp -- any any anywhere 169.254.169.254 tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
4 1216 ACCEPT udp -- any any anywhere 169.254.169.254 udp dpt:bootps /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 ACCEPT udp -- any any anywhere 169.254.169.254 udp dpt:tftp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
97 7372 ACCEPT udp -- any any anywhere 169.254.169.254 udp dpt:ntp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
0 0 REJECT tcp -- any any anywhere link-local/16 tcp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with tcp-reset
0 0 REJECT udp -- any any anywhere link-local/16 udp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with icmp-port-unreachable
And then I checked if ufw was running, as you mentioned. I get contradicting results when I run systemctl status and when I run ufw status.
$ systemctl status ufw.service
● ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2022-07-10 11:53:03 UTC; 2 days ago
Docs: man:ufw(8)
Main PID: 735 (code=exited, status=0/SUCCESS)
CPU: 2ms
Jul 10 11:53:03 arm1 systemd[1]: Starting Uncomplicated firewall...
Jul 10 11:53:03 arm1 systemd[1]: Finished Uncomplicated firewall.
$ sudo ufw status
Status: inactive
It seems to me like the service is running but it’s disabled. So I think it should be equivalent to it not running. At this point I thought lxd added those rules on ufw to allow traffic between the container and the host, but since ufw is disabled, they will not work.
Now since this is running on Oracle Cloud, it’s important to read their recommendation on best practices which is here.
- Running Uncomplicated Firewall (UFW) on Ubuntu images might cause issues with these rules. Because of this, we recommend that you do not enable UFW on your instances. See Ubuntu instance fails to reboot after enabling Uncomplicated Firewall (UFW) for more information.
But now there’s an issue. The provided link mentions on how to add the proper rules to fix this problem using firewalld or ufw, but Oracle recommends the usage of iptables. The same link also provides an iptables command, but only to fix an issue with docker which is also not installed.
Does anyone know the iptables rule to fix this problem?
Just a side note, I thought I could figure it out if I found the rules lxd added automatically to fix this problem and I thought they would be on ufw.
$ sudo ufw show added
Added user rules (see 'ufw status' for running firewall):
(None)
Since this returned nothing, I found this post which mentions an alternative way. It told me to check one of 3 files and they all have the exact same content as the following.
$ sudo cat /etc/ufw/user.rules
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
### RULES ###
-A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT
-A ufw-user-limit-accept -j ACCEPT
COMMIT
So did lxd add firewall rules to ensure full functionality?
It seems likely that LXD added rules and then they were replaced by the system firewall service at startup.
Your firewall rules show a non-standard chain ( InstanceServices) so what ever is adding that is likely where you need to configure to add rules to allow access to LXD’s DHCP server and forward traffic.
I don’t think that happened. The InstanceServices rules are there since the vm image creation and Oracle has a few warnings asking you not to remove those rules since they’ll not be added again by default. If lxd added rules which were erased on startup, then they were not saved.
I’m still searching for these rules lxd creates in the documentation:
By default, managed LXD bridges add firewall rules to ensure full functionality. If you do not run another firewall on your system, you can let LXD manage its firewall rules.
I just installed lxd fresh on my local machine, did lxd init, checked iptables and there was nothing there.
Is that statement about lxd adding firewall rules true?
If it is, is there a reproducible way to see them added?
LXD will create firewall rules in the selected firewall driver on start up yes.
lxc info | grep firewall: will show you the driver LXD is using.
Note, its possible to have LXD be using one firewall driver and another application on your system using a different firewall driver (so the rules don’t end up in the same place).
LXD tries hard to avoid that scenario by looking at what is in use when it starts.
The presence of InstanceServices chain is a strong indicator you have something else in your system modifying the firewall rules.
They are in /etc/iptables/rules.v4 which keeps them in place. But I can add and remove rules just fine. As long as I save them with sudo netfilter-persistent save so they’re written to /etc/iptables/rules.v4, they’ll stay there during restarts. But that’s about it.
This is the content of the file.
$ sudo cat /etc/iptables/rules.v4
# Generated by iptables-save v1.8.7 on Wed Jul 13 01:31:37 2022
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [94835:13050607]
:InstanceServices - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -s 10.0.0.0/16 -p tcp -m tcp --dport 8443 -m state --state NEW -m comment --comment "Victor: allow lxd cluster" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -d 169.254.0.0/16 -j InstanceServices
-A InstanceServices -d 169.254.0.2/32 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.2.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.4.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.5.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.0.2/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 53 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p tcp -m tcp --dport 53 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.0.3/32 -p tcp -m owner --uid-owner 0 -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.0.4/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 67 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 69 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 123 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j ACCEPT
-A InstanceServices -d 169.254.0.0/16 -p tcp -m tcp -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j REJECT --reject-with tcp-reset
-A InstanceServices -d 169.254.0.0/16 -p udp -m udp -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule" -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Wed Jul 13 01:31:37 2022
So lxd is using nftables.
$ lxc info | grep firewall:
firewall: nftables
Can this be the issue? How do I fix it?
What does iptables -v show?
$ sudo iptables -v
iptables v1.8.7 (nf_tables): no command specified
Try `iptables -h' or 'iptables --help' for more information.
OK can you install nftables package and then show sudo nft list ruleset.
It’s important to note I ran a sudo snap remove lxd --purge and reinstalled on --channel latest/stable. Cluster was recreated. Wanted to check if it was not a bug which was fixed afterwards.
$ sudo nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
ct state related,established counter packets 3312107 bytes 2436472627 accept
meta l4proto icmp counter packets 0 bytes 0 accept
iifname "lo" counter packets 5204 bytes 361483 accept
meta l4proto udp udp sport 123 counter packets 0 bytes 0 accept
meta l4proto tcp ip saddr 10.0.0.0/16 tcp dport 8443 ct state new counter packets 202 bytes 12120 accept
meta l4proto tcp ct state new tcp dport 22 counter packets 1250 bytes 73616 accept
counter packets 578 bytes 183208 reject with icmp type host-prohibited
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
counter packets 0 bytes 0 reject with icmp type host-prohibited
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
ip daddr 169.254.0.0/16 counter packets 5543 bytes 426430 jump InstanceServices
}
chain InstanceServices {
meta l4proto tcp ip daddr 169.254.0.2 skuid 0 tcp dport 3260 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.2.0/24 skuid 0 tcp dport 3260 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.4.0/24 skuid 0 tcp dport 3260 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.5.0/24 skuid 0 tcp dport 3260 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.0.2 tcp dport 80 counter packets 0 bytes 0 accept
meta l4proto udp ip daddr 169.254.169.254 udp dport 53 counter packets 968 bytes 102862 accept
meta l4proto tcp ip daddr 169.254.169.254 tcp dport 53 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.0.3 skuid 0 tcp dport 80 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.0.4 tcp dport 80 counter packets 0 bytes 0 accept
meta l4proto tcp ip daddr 169.254.169.254 tcp dport 80 counter packets 4551 bytes 321744 accept
meta l4proto udp ip daddr 169.254.169.254 udp dport 67 counter packets 0 bytes 0 accept
meta l4proto udp ip daddr 169.254.169.254 udp dport 69 counter packets 0 bytes 0 accept
meta l4proto udp ip daddr 169.254.169.254 udp dport 123 counter packets 24 bytes 1824 accept
meta l4proto tcp ip daddr 169.254.0.0/16 counter packets 0 bytes 0 reject with tcp reset
meta l4proto udp ip daddr 169.254.0.0/16 counter packets 0 bytes 0 reject
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table inet lxd {
chain pstrt.lxdfan0 {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 240.0.0.0/8 ip daddr != 240.0.0.0/8 masquerade
}
chain fwd.lxdfan0 {
type filter hook forward priority filter; policy accept;
ip version 4 oifname "lxdfan0" accept
ip version 4 iifname "lxdfan0" accept
}
chain in.lxdfan0 {
type filter hook input priority filter; policy accept;
iifname "lxdfan0" tcp dport 53 accept
iifname "lxdfan0" udp dport 53 accept
iifname "lxdfan0" icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
iifname "lxdfan0" udp dport 67 accept
}
chain out.lxdfan0 {
type filter hook output priority filter; policy accept;
oifname "lxdfan0" tcp sport 53 accept
oifname "lxdfan0" udp sport 53 accept
oifname "lxdfan0" icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
oifname "lxdfan0" udp sport 67 accept
}
}
Rules are definitely there. But everything I’m doing is quite new to me. So I really don’t understand everything that’s going on.
Yep, so this comes up quite a bit, and is likely to get more common as more people (without knowing) move to nftables as they move to newer OSes.
See
and
But basically if there is cause to drop/reject a packet in any of the nftables tables then it will be dropped/rejected even if its allowed in another table.
So LXD adds its allow rules to nftables in its own lxd table, but then your default reject rules in INPUT and FORWARD chains of the main filter table take over and block the traffic.
So going back to what we said at the start, you need to configure your existing firewall traffic to allow the same rules (or more) of what LXD adds.
I would prefer to let lxd manage its own rules.
I’ll try to remove the rules for REJECT from both INPUT and FORWARD.
I could try to put them back as nft rules in the end. Do you have any tips on how to do this?
EDIT: Removing the REJECT rules from both INPUT and FORWARD solved the problem. Thank you so much!!
Still trying to figure out nftables.
So I have:
$ sudo iptables -v
iptables v1.8.7 (nf_tables): no command specified
Try `iptables -h' or 'iptables --help' for more information.
$ sudo systemctl status nftables.service
○ nftables.service - nftables
Loaded: loaded (/lib/systemd/system/nftables.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:nft(8)
http://wiki.nftables.org
Is nftables actually running? Is Oracle’s Ubuntu image broken? Anyone has any idea what’s going on? If nftables.service is not running, are lxd firewall rules being considered at all?
If it possible to change lxd to configure iptables rules instead of nftables?
Btw, just to clear up why I still have firewall problems. Although I can connect to the internet from my containers, containers can’t see each other. There’s still something wrong.