Leap 15.5 + Firewalls: IPv4-Weiterleitung lässt nur Ping von IPs durch und ignoriert den Rest.

generalmajor · 30 Juli 2023

Nachdem ich meinen Heimserver komplett neu aufsetzen musste, kriege ich es nicht hin, dass daran hängende Clients ins Internet kommen. Früher musste ich im YaST nur die interne NIC mit statischer IP (169.254.164.1) konfigurieren & in die interne Firewall-Zone setzen, die externe mit DHCP (vom Router) einrichten und IPv4-Weiterleitung aktivieren. Fertig.

Nach Neuinstallation mit gleicher Netzwerk-Konfiguration komme ich mit dem Client (169.254.164.5) nicht mehr ins Internet, sondern nur noch auf den Server. Pings an externe IPs wie 8.8.8.8 gehen aber!

Hier die aktuelle Server-Config (mitsamt einer unverständlichen Warnmeldung aus dem syslog):

Code:

valen:~ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN grou
p 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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP gr
oup default qlen 1000
    link/ether 14:dd:a9:d4:1e:70 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.178.41/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP gr
oup default qlen 1000
    link/ether 14:dd:a9:d4:1e:71 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 169.254.164.1/24 brd 169.254.164.255 scope global eth1
       valid_lft forever preferred_lft forever

valen:~ # ip route show
default via 192.168.178.1 dev eth0 proto dhcp
169.254.164.0/24 dev eth1 proto kernel scope link src 169.254.164.1
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.41

valen:~ # iptables -t nat -nv -L >> netconfig.txt
Chain PREROUTING (policy ACCEPT 41 packets, 2456 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain OUTPUT (policy ACCEPT 12 packets, 909 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source dest
ination
   12 909 MASQUERADE all -- * eth0 0.0.0.0/0 0.0
.0.0/0
    0 0 LOG all -- * eth0 0.0.0.0/0 0.0.
0.0/0 LOG flags 0 level 7 prefix "MASQUERADE: "

valen:~ # iptables -L -v
Chain INPUT (policy ACCEPT 496 packets, 40562 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain FORWARD (policy ACCEPT 36 packets, 2276 bytes)
 pkts bytes target prot opt in out source dest
ination
    0 0 LOG all -- eth0 any anywhere anyw
here LOG level debug prefix "FORWARD: "
   36 2276 LOG all -- eth1 any anywhere anyw
here LOG level debug prefix "FORWARD: "

Chain OUTPUT (policy ACCEPT 307 packets, 43133 bytes)
 pkts bytes target prot opt in out source dest
ination

valen:~ # dmesg | grep MASQUERADE | tail -25
[ 5040.328157] x_tables: ip_tables: MASQUERADE target: used from hooks P
REROUTING, but only usable from POSTROUTING
valen:~ #

Und so ist der Client eingerichtet:

Code:

╭─jacek@epica ~
╰─➤ ip addr show
                                  2 ↵
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN grou
p 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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast sta
te UP group default qlen 1000
    link/ether b4:2e:99:c6:e9:9f brd ff:ff:ff:ff:ff:ff
    altname enp7s0
    inet 169.254.164.5/24 brd 169.254.164.255 scope global eth0
       valid_lft forever preferred_lft forever
╭─jacek@epica ~
╰─➤ ip route show
default via 169.254.164.1 dev eth0
169.254.164.0/24 dev eth0 proto kernel scope link src 169.254.164.5

Im Syslog finde ich unter FORWARD nur ausgehende Verbindungen, wenn ich einen externen Host wie www.google.de anpingen will:

Code:

[12810.381486] FORWARD: IN=eth1 OUT=eth0 MAC=14:dd:a9:d4:1e:71:b4:2e:99:
c6:e9:9f:08:00 SRC=169.254.164.5 DST=8.8.8.8 LEN=57 TOS=0x00 PREC=0x00 T
TL=63 ID=47287 DF PROTO=UDP SPT=51059 DPT=53 LEN=37
[12810.381551] FORWARD: IN=eth1 OUT=eth0 MAC=14:dd:a9:d4:1e:71:b4:2e:99:
c6:e9:9f:08:00 SRC=169.254.164.5 DST=8.8.4.4 LEN=57 TOS=0x00 PREC=0x00 T
TL=63 ID=31354 DF PROTO=UDP SPT=42060 DPT=53 LEN=37

Was läuft hier falsch? Bei den FW-Regeln habe ich mich an einige Anleitungen aus dem Netz gehalten. Danke!

Gräfin Klara · 30 Juli 2023

An einem client:
# host www.google.com
?

generalmajor · 30 Juli 2023

Schon probiert, Frau Gräfin! Aber leider ohne Erfolg. Timeout.

Gräfin Klara · 30 Juli 2023

generalmajor schrieb:
Pings an externe IPs wie 8.8.8.8 gehen aber!

Schon probiert, Frau Gräfin! Aber leider ohne Erfolg. Timeout.

Du hast als DNS den host dns.google (8.8.8.8)
DNS Abfragen erfolgen über Port 53, Protoll UDP.
Kontrolliere, ob die forwarding-rules das zulassen.

generalmajor · 30 Juli 2023

Es gibt keine Port- oder Protokoll-basierten Regeln bei mir: Jeden von einem Client initiierten Netzverkehr soll die FW durchlassen, und von außen erreichbare Server gibt es im internen Netz gar nicht.

Gräfin Klara · 31 Juli 2023

generalmajor schrieb:
.... einer unverständlichen Warnmeldung aus dem syslog:

Dein syslog und was bedeutet dieser Eintrag:

generalmajor schrieb:
[12810.381486] FORWARD: IN=eth1 OUT=eth0 MAC=14:dd:a9:d4:1e:71:b4:2e:99: c6:e9:9f:08:00 SRC=169.254.164.5 DST=8.8.8.8 LEN=57 TOS=0x00 PREC=0x00 T TL=63 ID=47287 DF PROTO=UDP SPT=51059 DPT=53 LEN=37

Der client (SRC) 169.254.164.5 will über deinen server von (IN) eth1 --> (OUT) eth0 und dann ins Netz nach (DST) 8.8.8.8.
Was will der client dort? Er will - das sieht man an Port (DPT) 53 - dass 8.8.8.8 ihm einen Namen wie z.B. "www,google.com"
in eine IP Adresse übersetzt (DNS query). Dein client kommuniziert mit (PROTO) UDP, was typisch ist für diese Abfrage.
Dein Server sperrt, läßt diese Abfrage nicht zu, deshalb dieser Eintrag im Log.

Vielleicht hilft dir diese Information für das weitere Vorgehen.

generalmajor · 4 Aug. 2023

Heißt das, die FW unterbindet die Auslieferungen von Datenpaketen, die für Hosts im internen Netz bestimmt sind? Das Logging aller weiterzuleitenden Pakete habe ich in der Config extra eingeschaltet. Siehe oben.

Eigentlich müsste doch die Zuordnung von Antworten zu Rechnern im internen Netz mittels conntrack funktionieren, oder? Das ist als Modul geladen und per net.netfilter.nf_conntrack_helper = 1 aktiviert. Habe ich geprüft. Muss ich dann Ports für ausgehende Verbindungen (also 53/UDP) auch in der Config hinterlegen, wie das bei Shorewall auch nötig ist?

Gräfin Klara · 5 Aug. 2023

generalmajor schrieb:
Heißt das, die FW unterbindet die Auslieferungen von Datenpaketen, die für Hosts im internen Netz bestimmt sind?

Nicht ganz...
Die FW unterbindet die Auslieferungen von Datenpaketen von Hosts aus internem Netz nach extern.

generalmajor schrieb:
Eigentlich müsste doch die Zuordnung von Antworten zu Rechnern im internen Netz mittels conntrack funktionieren, oder?

conntrack funktioniert erst, wenn eine Verbindung bereits besteht. (Connection Tracking).
Um eine Verbindung aufzubauen, muß das Packet erstmal hinausdürfen und genau das erlaubst deine FW ja nicht.

generalmajor schrieb:
Muss ich dann Ports für ausgehende Verbindungen (also 53/UDP) auch in der Config hinterlegen, wie das bei Shorewall auch nötig ist?

Wenn du Wert auf passive Sicherheiten legst, dann ja.
Wenn nein, dann genügt z.B.:

Code:

iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s hier die interne Netzadresse z.B. 169.254.164.0/27 oder ähnlich  -j ACCEPT
iptables -A FORWARD -j DROP
iptables -A POSTROUTING -t nat -o eth0 -s eth1 -j MASQUERADE

Die Parameter (eth0,eth1,..) mußt du selbst entprechend wählen
Hier steht eth0 für extern, eth1 für intern
Wie man das nach "Shorewall ???" übersetzt, mußt du selbst herausfinden.

spoensche · 6 Aug. 2023

Wie vergibst du die privaten IP-Adressen?

Mal so am Rande:
Der 169.254.x Addressbereich ist für die automatische IP Konfiguration vorgesehen und wird i.d.R. bei Problemen verwendet, aber nicht im regulären Betrieb.

generalmajor · 6 Aug. 2023

Wie vergibst du die privaten IP-Adressen?

Statisch nach Liste. 169.254.164.1 ist der Server. Weitere Hosts heißen 169.254.164.3 (Raspi), 169.254.164.5 (PC) und 169.254.164.9 (Laserdrucker). Diesen Adressraum hatte ich vor Jahren einführen müssen, nachdem DHCP im privaten Netz zu funktionieren aufgehört hatte.

Geier0815 · 7 Aug. 2023

Du willst einmal gucken was APIPA ist und Du möchtest dich mit privaten Netzwerkadressen beschäftigen und dann dein Netzwerk entsprechend umstellen. Kleiner Tipp: Auto- bzw Zeroconf und manuelle Vergabe beißen sich und darauf zu hoffen das damit eine Firewallkonfiguration funktioniert, ist, vorsichtig ausgedrückt, sehr optimistisch.

generalmajor · 8 Aug. 2023

OK, Zeroconf habe ich nie benützt. Bei Drucker ist die Adresse 169.254.164.9 anscheinend eine Rückfallebene für den Fall, dass es kein DHCP gäbe. Die Adressen haben vor meiner Server-Katastrofe /* welche die Neuinstallation erzwang */ in exakt der gleichen Form funktioniert.

spoensche · 14 Aug. 2023

generalmajor schrieb:
OK, Zeroconf habe ich nie benützt. Bei Drucker ist die Adresse 169.254.164.9 anscheinend eine Rückfallebene für den Fall, dass es kein DHCP gäbe. Die Adressen haben vor meiner Server-Katastrofe /* welche die Neuinstallation erzwang */ in exakt der gleichen Form funktioniert.

Also so wie jetzt? Das ändert nichts an den von mir und von @Geier0815 erwähnten Tatsachen.

generalmajor · 18 Aug. 2023

Ja, so wie jetzt.

Heißt das, die Verwendung des Adressraums 169.254.164.0/24 sei an dieser Stelle kontraproduktiv?

Gräfin Klara · 20 Aug. 2023

generalmajor schrieb:
Ja, so wie jetzt.

Heißt das, die Verwendung des Adressraums 169.254.164.0/24 sei an dieser Stelle kontraproduktiv?

Ja.
Gib all deinen Rechnern und dem Drucker eine fixe IP im Segment 192.168.96.0/25
Die verwendbaren Addressen wären: 192.168.96.1 - 192.168.96.126
Bitmask oder Subnetmaske ist 255.255.255.128
Danach sehen wir weiter

generalmajor · 26 Aug. 2023

OK, das Netzwerk funktioniert wieder, OHNE die IP-Adressen ändern zu müssen. Allerdings habe ich den firewalld durch shorewall ersetzt. Hier die Konfiguration:

/etc/shorewall/zones:

Code:

#ZONE           TYPE            OPTIONS         IN_OPTIONS      OUT_OPTIONS

fw              firewall
net             ipv4
loc             ipv4

/etc/shorewall/rules:

Code:

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE   
        USER/   MARK    CONNLIMIT       TIME            HEADERS         SWITCH          HELPER
#                                                       PORT    PORT(S)         DEST            LIMIT   
        GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

#       Don't allow connection pickup from the net
#
Invalid(DROP)   net             all             tcp
#
#       Accept DNS connections from the firewall to the network
#
DNS(ACCEPT)     $FW             net
#
#       Accept DNS connections from the local network to a dnsmasq proxy on the firewall.
#       Added 2023/08/01 by JR.
#
DNS(ACCEPT)     loc             $FW
#
#       Accept SSH connections from the local network for administration
#
SSH(ACCEPT)     net             $FW
SSH(ACCEPT)     loc             $FW
#
#       Allow Ping from the local network
#
Ping(ACCEPT)    loc             $FW
#  
#       Allow NFS from the local network.
#       Added 2023/08/01 by JR.
#  
ACCEPT          loc             $FW             tcp             2049

#
# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..
#

Ping(DROP)      net             $FW

ACCEPT          $FW             loc             icmp
ACCEPT          $FW             net             icmp
ACCEPT          loc             net             icmp
#
# Allow outgoing HTTP, HTTPS, POP3, and IMAP traffic.
# Added 2023/08/01 by JR.
#  
IMAP(ACCEPT)    loc             net
IMAPS(ACCEPT)   loc             net
POP3(ACCEPT)    loc             net
POP3S(ACCEPT)   loc             net
FTP(ACCEPT)     loc             net
ACCEPT          loc             net             tcp             80,443

/etc/shorewall/interfaces:

Code:

?FORMAT 2
#ZONE   INTERFACE       OPTIONS
net     NET_IF          dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,physical=eth0
loc     LOC_IF          tcpflags,nosmurfs,routefilter,logmartians,physical=eth1

/etc/shorewall/policy:

Code:

#SOURCE DEST            POLICY          LOGLEVEL        RATE    CONNLIMIT

loc     net             ACCEPT
$FW     net             ACCEPT
loc     $FW             ACCEPT
$FW     loc             ACCEPT
net     all             DROP            $LOG_LEVEL
# THE FOLLOWING POLICY MUST BE LAST
all     all             REJECT          $LOG_LEVEL

/etc/shorewall/snat:

Code:

?FORMAT 2
#ACTION                 SOURCE                  DEST            PROTO   DPORT   SPORT   IPSEC   MARK    USER          SWITCH  ORIGDEST        PROBABILITY
#
# Rules generated from masq file /home/teastep/shorewall/trunk/Shorewall/Samples/two-interfaces/masq by Shorewall 5.0.13-RC1 - Sat Oct 15 11:41:40 PDT 2016
#
MASQUERADE              169.254.164.0/24        eth0

Das File /etc/shorewall/shorewall.conf musste noch um diese eine Zeile ergänzt werden:

Code:

STARTUP_ENABLED=Yes

Einziger Nachteil: Für jeden ausgehenden Port bzw. Dienst muss eine eigene Regel gestrickt werden.

spoensche · 31 Aug. 2023

generalmajor schrieb:
OK, das Netzwerk funktioniert wieder, OHNE die IP-Adressen ändern zu müssen.

Aber nicht lange, weil dann das Ursprungsproblem wieder auftritt und es nichts mit der verwendeten Firewall zu tun hat.

Du kannst dich gerne weiterhin über die Standards hinwegsetzen und wundern warum es nicht funktioniert.
Allerdings musst dann damit leben, dass dir so keiner helfen kann und wird.

Leap 15.5 + Firewalls: IPv4-Weiterleitung lässt nur Ping von IPs durch und ignoriert den Rest.

generalmajor

Hacker

Gräfin Klara

Hacker

generalmajor

Hacker

Gräfin Klara

Hacker

generalmajor

Hacker

Gräfin Klara

Hacker

generalmajor

Hacker

Gräfin Klara

Hacker

spoensche

Moderator

generalmajor

Hacker

Geier0815

Guru

generalmajor

Hacker

spoensche

Moderator

generalmajor

Hacker

Gräfin Klara

Hacker

generalmajor

Hacker

spoensche

Moderator