staging.inyokaproject.org

Habe hier ein Problem mit firewalld und NAT. Beiträge zu Firewalls sollen zwar eigentlich im Forum Sicherheit einsortiert werden, aber ich orientiere mich mal an den existierenden Beiträgen.

Der Host soll als NAT-Router (mit DHCP-Service) zwischen zwei internen Netzen eingerichtet werden. Basis ist eine Default-Installation mit Ubuntu-22-LTS (Desktop) auf einem Desktop-PC mit insgesamt 7 Interfaces, davon 3 Paare als bond. Konfiguriert wurde per netplan und firewalld. Paketfilter ist nftables (= default). ufw ist deinstalliert, SELinux ist nicht installiert, der Service AppArmor ist disabled.

Problem: Ein "interner" Client-PC bekommt per DHCP eine Adresse, kann aber weder per DNS noch per ping auf Hosts am "external" Interface zugreifen. ping vom Client auf den NAT-Router ist erfolgreich. tcpdump zeigt am internen Interface:

1
2
3
4

12:44:39.883855 IP 192.168.201.10 > 10.1.239.239: ICMP echo request, id 1, seq 37950, length 40
12:44:39.883953 IP 192.168.201.254 > 192.168.201.10: ICMP host 10.1.239.239 unreachable - admin prohibited filter, length 68
12:44:40.694644 IP 192.168.201.254 > 192.168.201.10: ICMP host 10.1.239.14 unreachable - admin prohibited filter, length 73
12:44:40.694649 IP 192.168.201.254 > 192.168.201.10: ICMP host 10.1.239.13 unreachable - admin prohibited filter, length 73

(.13 und .14 sind DNS-Server, .239 ein externer Router, alle direct connected an bondup)

Schalte ich den Service firewalld ab, verschwinden diese Meldungen, aber natürlich funktioniert dann auch das NAT nicht und dementsprechend kommt kein reply.

Auf dem externen Interface zeigt tcpdump keinen Traffic zwischen NAT-Router und .239, außer, wenn man vom NAT-Router selbst aus pingt.

Es sieht also so aus, als würde der NAT-Router selber den Traffic des Clients ablehnen.

Routingtabelle:

1
2
3
4
5
6
7
8

# ip r
default via 10.1.239.239 dev bondup proto static 
10.1.239.0/24 dev bondup proto kernel scope link src 10.1.239.248 
10.3.193.0/24 via 172.29.171.254 dev eno1 proto static 
10.3.199.0/24 dev vlan170 proto kernel scope link src 10.3.199.248 
172.29.171.0/24 dev eno1 proto kernel scope link src 172.29.171.248 
192.168.201.0/24 dev bond1 proto kernel scope link src 192.168.201.254 
192.168.202.0/24 dev bond2 proto kernel scope link src 192.168.202.254 linkdown 

(bond2 ist konfiguriert, aber nicht verbunden)

firewalld-Konfiguration:

1
2
3
4
5
6
7

# firewall-cmd --get-active-zones
external
  interfaces: bondup
internal
  interfaces: bond1 bond2
mgmt
  interfaces: vlan170 eno1 vlan170@bondup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: bondup
  sources: 
  services: ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# firewall-cmd --zone=internal --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: bond1 bond2
  sources: 
  services: dhcpv6-client dns mdns samba-client ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# firewall-cmd --zone=mgmt --list-all
mgmt (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1 vlan170 vlan170@bondup
  sources: 
  services: 
  ports: 
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	rule family="ipv4" service name="ssh" accept

Bitte melden, falls weitere Informationen benötigt werden. Das Setup entspricht m.E. den Anleitungen zu firewalld, die es zu Dutzenden im Web gibt. Im Moment fällt mir nichts mehr ein, an welcher Stelle ich noch suchen könnte.

Vorab Danke!

Gruß, Tobias.

Crefeld schrieb:

Problem: Ein "interner" Client-PC bekommt per DHCP eine Adresse, kann aber weder per DNS noch per ping auf Hosts am "external" Interface zugreifen. ping vom Client auf den NAT-Router ist erfolgreich.

Poste mal vom internen Client-PC die Ausgabe von:

sudo arp-scan -I <Interface> -l # BTW: l ist nicht 1

(Interface anpassen und ohne spitze Klammern) und vom NAT-Router die Ausgaben von:

sysctl net.ipv4.ip_forward
sudo iptables -nvx -L FORWARD
sudo iptables -nvx -L POSTROUTING -t nat

lubux schrieb:

Poste mal vom internen Client-PC die Ausgabe von:

sudo arp-scan -I <Interface> -l # BTW: l ist nicht 1

Das ist mit diesem Client nicht ganz so einfach, weil da MS drauf läuft. Wie dort das Pendant heißt, muss ich erst nachfragen.

(Interface anpassen und ohne spitze Klammern) und vom NAT-Router die Ausgaben von:

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
# sudo iptables -nvx -L FORWARD
sudo iptables -nvx -L POSTROUTING -t nat
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Bei Ubuntu-22 ist nftables statt iptables Standard. Die dazugehörige Ausgabe ist allerdings "endlos" - keine Ahnung, auf was man dort achten soll. Habe die Ausgabe von "nft list table inet firewalld" als Datei angehängt.

Crefeld schrieb:

sudo iptables -nvx -L POSTROUTING -t nat      
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Wenn Du mit:

which iptables

auf dem NAT-Router eine Ausgabe bekommst, dann versuch mal auf dem NAT-Router mit (noch nicht persistent):

sudo iptables -t nat -I POSTROUTING 1 -j MASQUERADE

evtl. auch nur mit:

sudo iptables -t nat -I POSTROUTING 1 -o <richtiges-Interface> -j MASQUERADE

(richtiges-Interface anpassen und ohne spitze Klammern).

lubux schrieb:

sudo iptables -t nat -I POSTROUTING 1 -j MASQUERADE

evtl. auch nur mit:

sudo iptables -t nat -I POSTROUTING 1 -o <richtiges-Interface> -j MASQUERADE

(richtiges-Interface anpassen und ohne spitze Klammern).

Das ist möglich und danach sind auch in der Chain POSTROUTING Einträge drin:

sudo iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 MASQUERADE  all  --  *      bondup  0.0.0.0/0            0.0.0.0/0           
       1      328 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

An den "unreachable"-Meldungen ändert es hingegen nichts.

BTW: Kann bzw. darf man denn iptables und nftables beliebig mischen?

Crefeld schrieb:

An den "unreachable"-Meldungen ändert es hingegen nichts.

Starte mal den Client auf dem Du z. Zt. Windows hast, mit einem Linux-Live-OS (Stick oder DVD) und mach dann von dort den arp-scan.

Crefeld schrieb:

BTW: Kann bzw. darf man denn iptables und nftables beliebig mischen?

Temporär und zum testen darf/kann man das machen. Aber wenn man nftables gut kann, kann man statt der iptables-Regel(n) auch die gleichwertige nftables-Regel benutzen.

Also ganz generell möchte ich nicht "back to the roots" und wieder endlose Listen basteln - egal ob für nftables, iptables, ... oder gleich ipchains. 😉

Wenn es schon Toolkits wie firewalld, ufw, SuSEfirewall2, etc. gibt, möchte ich die auch verwenden. Bislang habe ich mit firewalld gute Erfahrungen gemacht, aber da waren weder Ubuntu noch NAT gegeben.

Nach Aktivierung des Loggings ( LogDenied=unicast in /etc/firewalld/firewalld.conf loggt in /var/log/kern.log ) sind mir tausende Einträge "filter_FWD_internal_REJECT" aufgefallen.

Warum die Access-Rules nicht funktionieren, habe ich noch nicht verstanden, aber es gibt eine Möglichkeit, ohne spezifische Regeln die NAT-Maschine zu aktivieren. Verhindert hat das letztlich das Target in der Zone "internal" (siehe oben). "default" bedeutet, dass spezifische Regeln folgen müssen, die den erlaubten Traffic weiterleiten. Wenn man hier ACCEPT einträgt, wird aller Traffic aus der Zone weitergeleitet:

1
2

firewall-cmd --zone=internal --set-target ACCEPT --permanent
firewall-cmd --reload

Damit funktioniert es nun erstmal.

Wie man die passenden Regeln für "forwarding" einträgt, ist mir noch nicht klar. Es gibt eine Menge Beispiele im Web, aber im Moment bin ich mir nicht sicher, ob hier bestimmte Objektbezeichner nicht abhängig sind vom verwendeten Filter und die meisten setzen noch die Kombination von firewalld und iptables ein.

Nichtdestotrotz erstmal Danke für die Unterstützung!

Gruß, Tobias.

Crefeld schrieb:

Also ganz generell möchte ich nicht "back to the roots" und wieder endlose Listen basteln ...

BTW: Das hat nichts mit "back to the roots" zu tun. Die besten Betriebssysteme waren, sind und bleiben die, bei denen man die _Konfiguration & Co._ für Kernel und userland, mit Textdateien via Kommandozeile/Terminal machen kann.

lubux schrieb:

BTW: Das hat nichts mit "back to the roots" zu tun. Die besten Betriebssysteme waren, sind und bleiben die, bei denen man die _Konfiguration & Co._ für Kernel und userland, mit Textdateien via Kommandozeile/Terminal machen kann.

Also das spricht wiederum nicht gegen die Verwendung von firewalld. Es kann über ein CLI bedient werden und die Konfiguration liegt unter /etc/firewalld/ . Dort steht auch drin, welcher Filter als "FirewallBackend" verwendet wird. Bei Ubuntu-22 ist das per Default nftables, aber auch iptables ist möglich. In Anbetracht der geringen Last bin ich am überlegen, auf iptables umzustellen. Die anderen x-tables brauche ich ja auch nicht.

Im normalen Serverbetrieb ist die Anpassung von firewalld mit einer Handvoll Aufrufen erledigt. Nur das Thema NAT scheint etwas sperriger zu sein. Aber vielleicht fehlt auch hier nur die passende Anleitung - mal sehen.

Gruß, Tobias.