ICMP echo working but still getting a block message in log
by Koen Drai
Hi,
I am running into a firewalld behavior again that I cannot understand.
Running firewalld on a Debian 11 box.
The zone file contains the following:
<icmp-block-inversion/>
<icmp-block name="echo-reply"/>
<icmp-block name="echo-request"/>
A ping from a client results in a reply, but I am still getting the following error message in syslog:
"filter_zone_knet_HOST_ICMP_BLOCK: "IN=enp2s0 OUT= MAC=<ANOM> SRC=192.168.1.9 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=56385 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=509
What's happening?
Thanks for your help and best regards,
Koen
2 years, 1 month
LXD container Unable to reach internet
by Sergio Belkin
Hi,
I'm running on firewalld on Fedora 35 and I've installed lxd.
The problem is that lxd containers can reach the host, but not the internet.
This the firewalld configuration:
FedoraServer
target: default
icmp-block-inversion: no
interfaces:
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
FedoraWorkstation (active)
target: default
icmp-block-inversion: no
interfaces: wlp108s0
sources:
services: dhcpv6-client mdns samba-client ssh
ports: 1025-65535/udp 1025-65535/tcp
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
block
target: %%REJECT%%
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
dmz
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
docker (active)
target: ACCEPT
icmp-block-inversion: no
interfaces: docker0
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
drop (active)
target: DROP
icmp-block-inversion: no
interfaces:
sources: ipset:crowdsec-blacklists
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
external
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
home
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
internal
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
libvirt
target: ACCEPT
icmp-block-inversion: no
interfaces:
sources:
services: dhcp dhcpv6 dns ssh tftp
ports:
protocols: icmp ipv6-icmp
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule priority="32767" reject
nm-shared
target: ACCEPT
icmp-block-inversion: no
interfaces:
sources:
services: dhcp dns ssh
ports:
protocols: icmp ipv6-icmp
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule priority="32767" reject
public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
trusted (active)
target: ACCEPT
icmp-block-inversion: no
interfaces: lxdbr0
sources:
services:
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
work
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
I've trying also what is documented at
https://linuxcontainers.org/lxd/docs/master/networks/#
Just in case the routes on container are:
default via 10.230.54.1 dev eth0 proto dhcp metric 100
10.230.54.0/24 dev eth0 proto kernel scope link src 10.230.54.220 metric
100
Please could you help and tell me if I am doing something wrong?
Thanks in advance!
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
2 years, 1 month
Rejections of related/established connections?
by Koen Drai
Hi,
Not sure if I am missing something, but I keep running into connections being rejected that should be accepted from how I (think I :)) have defined the rules.
I somehow get the feeling that the behavior below is related to nft rules only containing "new, untracked" but not related and established.
Googled if there is a way to add these two states to rules, but did not find anything.
A direct rule might help, but since these are discouraged for futureproofness, trying to figure out the "right" way.
Working on a Debian 11 system, nftables backend.
Example 1, syncthing:
zone file knet.xml, amongst others:
<service name="syncthing"/>
<source-port port="22000" protocol="tcp"/>
<source-port port="22000" protocol="udp"/>
<rule family="ipv4">
<source address="192.168.1.1/24"/>
<port port="22000" protocol="tcp"/>
<accept/>
</rule>
<rule family="ipv4">
<source address="192.168.1.1/24"/>
<port port="22000" protocol="udp"/>
<accept/>
</rule>
Nicely translated into the nft ruleset (amongst others):
ip saddr 192.168.1.0/24 tcp dport 22000 ct state { new, untracked } accept
ip saddr 192.168.1.0/24 udp dport 22000 ct state { new, untracked } accept
However, I still get these errors in syslog:
filter_IN_knet_REJECT: "IN=enp2s0 OUT= MAC=<ANOM> SRC=192.168.1.54 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=33526 DF PROTO=TCP SPT=22000 DPT=22000 WINDOW=65535 RES=0x00 SYN
Example 2, Apache as an https proxy:
<rule family="ipv4">
<source address="192.168.1.13"/>
<source-port port="443" protocol="tcp"/>
<accept/>
</rule>
ip saddr 192.168.1.13 tcp sport 443 ct state { new, untracked } accept
"filter_IN_knet_REJECT: "IN=enp2s0 OUT= MAC=<ANOM> SRC=192.168.1.13 DST=192.168.1.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=34860 WINDOW=0 RES=0x00 RST URGP=0
What's going on here?
Thanks a lot for your help and best regards
2 years, 1 month