Shorewall Masq - Pakete schleichen sich vorbei
Hallo, ich habe folgendes Problem: ich setze Opensuse (10.2) zusammen mit Shorewall (3.2.8) und Kernel (2.6.21.5, vanilla) ein. Da gibt es einen internen IP-Bereich (eth1, 10.10.0.0/16), den ich per MASQ auf eine der beiden offiziellen IP-Adressen umsetze. Prinzipiell klappt das auch gut so wie es ist, komischerweise kommen aber einige Pakete am Masquerading vorbei und tauchen am externen Interface (eth0) mit einer 10.10.x.x-Adresse auf. Eigentlich sind es nicht allzuviele Pakete, aber bei bestimmten IP-Adressen intern ist es mehr als bei anderen. Eine IP-Adresse schafft es z.B. somit gar nicht, per SIP (udp,5060) eine Verbindung nach außen aufzubauen, weil alle IP-Pakete nach außen mit der internen IP-Adresse gehen und diese Pakete somit verworfen werden. Außerdem sind viele "Abschluß-Pakete" davon betroffen, z.B. mit den Flag-Kombinationen "tcp RST", "tcp RST,ACK" oder "tcp FIN,ACK". Warum "schaffen" das manche Pakete, und die anderen sonst nicht??? Hier ein Auszug aus "iptables-save": # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *raw :PREROUTING ACCEPT [1037664:568310868] :OUTPUT ACCEPT [236837:242678896] COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *nat :PREROUTING ACCEPT [34127:3452365] :POSTROUTING ACCEPT [9058:637595] :OUTPUT ACCEPT [4668:281131] :eth0_masq - [0:0] :loc_dnat - [0:0] -A PREROUTING -i eth1 -m policy --dir in --pol none -j loc_dnat -A POSTROUTING -s erste.externe.ip.adresse -o eth0 -p tcp -m tcp --dport 25 -j SNAT --to-source zweite.externe.ip.adresse -A POSTROUTING -o eth0 -j eth0_masq -A eth0_masq -s 10.10.0.0/255.255.0.0 -m policy --dir out --pol none -j MASQUERADE -A loc_dnat -s 10.10.0.0/255.255.0.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *mangle :PREROUTING ACCEPT [1037745:568348082] :INPUT ACCEPT [279434:210078264] :FORWARD ACCEPT [758115:358182166] :OUTPUT ACCEPT [82722173:89736606604] :POSTROUTING ACCEPT [991208:599985684] :tcfor - [0:0] :tcout - [0:0] :tcpost - [0:0] :tcpre - [0:0] -A PREROUTING -j tcpre -A FORWARD -j tcfor -A OUTPUT -j tcout -A POSTROUTING -j tcpost COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *filter :INPUT DROP [108:12922] :FORWARD DROP [329:46162] :OUTPUT DROP [15:2502] :Drop - [0:0] :Reject - [0:0] :all2all - [0:0] :blacklst - [0:0] :dropBcast - [0:0] :dropInvalid - [0:0] :dropNotSyn - [0:0] ... Die Beispiel-IP-Adresse mit dem SIP-Problem ist z.B. 10.10.89.xxx, die kommt in dieser Ausgabe von "iptables-save" gar nicht vor. Die Konfiguration (Teile daraus) in /etc/shorewall: /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0 10.10.0.0/16 /etc/shorewall/nat: leer /etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT fw all ACCEPT loc fw REJECT #loc fw ACCEPT net all DROP vpn net ACCEPT net vpn ACCEPT all all REJECT /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect blacklist loc eth1 detect dhcp vpn ppp+ detect dhcp /etc/shorewall/shorewall.conf: STARTUP_ENABLED=Yes VERBOSITY=1 LOGFILE=/var/log/shorewall LOGFORMAT="Shorewall:%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL=info TCP_FLAGS_LOG_LEVEL=info RFC1918_LOG_LEVEL=info SMURF_LOG_LEVEL=info LOG_MARTIANS=No IPTABLES= PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SHOREWALL_SHELL=/bin/sh SUBSYSLOCK=/var/lock/subsys/shorewall MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE= IPSECFILE=zones IP_FORWARDING=On ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=No TC_EXPERT=No CLEAR_TC=No MARK_IN_FORWARD_CHAIN=No CLAMPMSS=No ROUTE_FILTER=No DETECT_DNAT_IPADDRS=No MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX= DISABLE_IPV6=Yes BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=Yes RFC1918_STRICT=No MACLIST_TABLE=filter MACLIST_TTL= SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=No IMPLICIT_CONTINUE=Yes HIGH_ROUTE_MARKS=No BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT TCP_FLAGS_DISPOSITION=DROP Könnte mich jemand auf den richtigen Weg bringen? Ich habe leider keine Idee wo ich da suchen könnte. Ist es ein Kernel-Problem? Ist Shorewall schuld? Was könnte sonst noch schuld sein? Wie kann ich den Fehler beheben? Liebe Grüße Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, hat denn keiner eine Idee, wo ich zum Suchen anfangen kann? Fehlen noch Angaben? Liebe Grüße Günther Günther Zisham schrieb:
Hallo,
ich habe folgendes Problem: ich setze Opensuse (10.2) zusammen mit Shorewall (3.2.8) und Kernel (2.6.21.5, vanilla) ein. Da gibt es einen internen IP-Bereich (eth1, 10.10.0.0/16), den ich per MASQ auf eine der beiden offiziellen IP-Adressen umsetze. Prinzipiell klappt das auch gut so wie es ist, komischerweise kommen aber einige Pakete am Masquerading vorbei und tauchen am externen Interface (eth0) mit einer 10.10.x.x-Adresse auf.
Eigentlich sind es nicht allzuviele Pakete, aber bei bestimmten IP-Adressen intern ist es mehr als bei anderen. Eine IP-Adresse schafft es z.B. somit gar nicht, per SIP (udp,5060) eine Verbindung nach außen aufzubauen, weil alle IP-Pakete nach außen mit der internen IP-Adresse gehen und diese Pakete somit verworfen werden. Außerdem sind viele "Abschluß-Pakete" davon betroffen, z.B. mit den Flag-Kombinationen "tcp RST", "tcp RST,ACK" oder "tcp FIN,ACK".
Warum "schaffen" das manche Pakete, und die anderen sonst nicht???
Hier ein Auszug aus "iptables-save":
# Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *raw :PREROUTING ACCEPT [1037664:568310868] :OUTPUT ACCEPT [236837:242678896] COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *nat :PREROUTING ACCEPT [34127:3452365] :POSTROUTING ACCEPT [9058:637595] :OUTPUT ACCEPT [4668:281131] :eth0_masq - [0:0] :loc_dnat - [0:0] -A PREROUTING -i eth1 -m policy --dir in --pol none -j loc_dnat -A POSTROUTING -s erste.externe.ip.adresse -o eth0 -p tcp -m tcp --dport 25 -j SNAT --to-source zweite.externe.ip.adresse -A POSTROUTING -o eth0 -j eth0_masq -A eth0_masq -s 10.10.0.0/255.255.0.0 -m policy --dir out --pol none -j MASQUERADE -A loc_dnat -s 10.10.0.0/255.255.0.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *mangle :PREROUTING ACCEPT [1037745:568348082] :INPUT ACCEPT [279434:210078264] :FORWARD ACCEPT [758115:358182166] :OUTPUT ACCEPT [82722173:89736606604] :POSTROUTING ACCEPT [991208:599985684] :tcfor - [0:0] :tcout - [0:0] :tcpost - [0:0] :tcpre - [0:0] -A PREROUTING -j tcpre -A FORWARD -j tcfor -A OUTPUT -j tcout -A POSTROUTING -j tcpost COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *filter :INPUT DROP [108:12922] :FORWARD DROP [329:46162] :OUTPUT DROP [15:2502] :Drop - [0:0] :Reject - [0:0] :all2all - [0:0] :blacklst - [0:0] :dropBcast - [0:0] :dropInvalid - [0:0] :dropNotSyn - [0:0] ...
Die Beispiel-IP-Adresse mit dem SIP-Problem ist z.B. 10.10.89.xxx, die kommt in dieser Ausgabe von "iptables-save" gar nicht vor.
Die Konfiguration (Teile daraus) in /etc/shorewall:
/etc/shorewall/masq: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0 10.10.0.0/16
/etc/shorewall/nat: leer
/etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT fw all ACCEPT loc fw REJECT #loc fw ACCEPT net all DROP vpn net ACCEPT net vpn ACCEPT all all REJECT
/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect blacklist loc eth1 detect dhcp vpn ppp+ detect dhcp
/etc/shorewall/shorewall.conf: STARTUP_ENABLED=Yes VERBOSITY=1 LOGFILE=/var/log/shorewall LOGFORMAT="Shorewall:%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL=info TCP_FLAGS_LOG_LEVEL=info RFC1918_LOG_LEVEL=info SMURF_LOG_LEVEL=info LOG_MARTIANS=No IPTABLES= PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SHOREWALL_SHELL=/bin/sh SUBSYSLOCK=/var/lock/subsys/shorewall MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE= IPSECFILE=zones IP_FORWARDING=On ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=No TC_EXPERT=No CLEAR_TC=No MARK_IN_FORWARD_CHAIN=No CLAMPMSS=No ROUTE_FILTER=No DETECT_DNAT_IPADDRS=No MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX= DISABLE_IPV6=Yes BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=Yes RFC1918_STRICT=No MACLIST_TABLE=filter MACLIST_TTL= SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=No IMPLICIT_CONTINUE=Yes HIGH_ROUTE_MARKS=No BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT TCP_FLAGS_DISPOSITION=DROP
Könnte mich jemand auf den richtigen Weg bringen? Ich habe leider keine Idee wo ich da suchen könnte. Ist es ein Kernel-Problem? Ist Shorewall schuld? Was könnte sonst noch schuld sein? Wie kann ich den Fehler beheben?
Liebe Grüße Günther
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 6. März 2008 17:10:13 schrieb Günther Zisham:
SIP
Hallo Eine Frage sip funzt nicht von dem Masq-rechner, oder von Rechner dahinter ? Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Karl Kehlenbrink schrieb:
Am Donnerstag, 6. März 2008 17:10:13 schrieb Günther Zisham:
SIP
Hallo
Eine Frage sip funzt nicht von dem Masq-rechner, oder von Rechner dahinter ?
Gruß Karl
Eigentlich schon. Der Router baut eine Verbindung vom VoIP-Server auf und hält die auch konstant. Es fließen im nicht allzu großen Abstand Pakete (Polling-Verfahren?). Außerdem gibt es da ja auch noch STUN. Nur bei diesen 2 von ungeführ 50 SIP-Endgeräten (Fritz-Box) funktioniert es nicht seit dem letzten Server-Neustart. Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 6. März 2008 20:23:39 schrieb Günther Zisham:
Außerdem gibt es da ja auch noch STUN.
Hallo Hier liegt wahrscheinlich der Hase. STUN sollte eingendlich die korrekte ip ermitteln und die NATs und Walls durchdringen, nicht wahr. Geht da irgend was an der Firewall zugrunde ?? Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Karl Kehlenbrink schrieb:
Am Donnerstag, 6. März 2008 20:23:39 schrieb Günther Zisham:
Außerdem gibt es da ja auch noch STUN.
Hallo
Hier liegt wahrscheinlich der Hase. STUN sollte eingendlich die korrekte ip ermitteln und die NATs und Walls durchdringen, nicht wahr.
Geht da irgend was an der Firewall zugrunde ??
Das dumme ist ja, dass diese Pakete ungehindert durch die Firewall durchgehen und nicht geNATet werden. Ich sehe am externen Interface die 10.10.x.x-Adressen, die somit beim nächsten Router im Internet herausgefiltert (zurecht) werden. Und ob STUN überhaupt auf Fritz-Boxen verwendet wird, weiß ich auch nicht. Stellt man bei der Fritzbox eine andere 10.10.x.x-Adresse ein, funktioniert es seltsamerweise. Vor dem letzten Server-Neustart funktionierte es auch bei dieser Adresse. Beim nächsten Server-Start sind dann wieder ein paar andere IP-Adressen funktionsunfähig ... Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, hat denn keiner eine Idee? Grüße Günther Günther Zisham schrieb:
Hallo,
ich habe folgendes Problem: ich setze Opensuse (10.2) zusammen mit Shorewall (3.2.8) und Kernel (2.6.21.5, vanilla) ein. Da gibt es einen internen IP-Bereich (eth1, 10.10.0.0/16), den ich per MASQ auf eine der beiden offiziellen IP-Adressen umsetze. Prinzipiell klappt das auch gut so wie es ist, komischerweise kommen aber einige Pakete am Masquerading vorbei und tauchen am externen Interface (eth0) mit einer 10.10.x.x-Adresse auf.
Eigentlich sind es nicht allzuviele Pakete, aber bei bestimmten IP-Adressen intern ist es mehr als bei anderen. Eine IP-Adresse schafft es z.B. somit gar nicht, per SIP (udp,5060) eine Verbindung nach außen aufzubauen, weil alle IP-Pakete nach außen mit der internen IP-Adresse gehen und diese Pakete somit verworfen werden. Außerdem sind viele "Abschluß-Pakete" davon betroffen, z.B. mit den Flag-Kombinationen "tcp RST", "tcp RST,ACK" oder "tcp FIN,ACK".
Warum "schaffen" das manche Pakete, und die anderen sonst nicht???
Hier ein Auszug aus "iptables-save":
# Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *raw :PREROUTING ACCEPT [1037664:568310868] :OUTPUT ACCEPT [236837:242678896] COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *nat :PREROUTING ACCEPT [34127:3452365] :POSTROUTING ACCEPT [9058:637595] :OUTPUT ACCEPT [4668:281131] :eth0_masq - [0:0] :loc_dnat - [0:0] -A PREROUTING -i eth1 -m policy --dir in --pol none -j loc_dnat -A POSTROUTING -s erste.externe.ip.adresse -o eth0 -p tcp -m tcp --dport 25 -j SNAT --to-source zweite.externe.ip.adresse -A POSTROUTING -o eth0 -j eth0_masq -A eth0_masq -s 10.10.0.0/255.255.0.0 -m policy --dir out --pol none -j MASQUERADE -A loc_dnat -s 10.10.0.0/255.255.0.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *mangle :PREROUTING ACCEPT [1037745:568348082] :INPUT ACCEPT [279434:210078264] :FORWARD ACCEPT [758115:358182166] :OUTPUT ACCEPT [82722173:89736606604] :POSTROUTING ACCEPT [991208:599985684] :tcfor - [0:0] :tcout - [0:0] :tcpost - [0:0] :tcpre - [0:0] -A PREROUTING -j tcpre -A FORWARD -j tcfor -A OUTPUT -j tcout -A POSTROUTING -j tcpost COMMIT # Completed on Tue Mar 4 21:28:53 2008 # Generated by iptables-save v1.3.6 on Tue Mar 4 21:28:53 2008 *filter :INPUT DROP [108:12922] :FORWARD DROP [329:46162] :OUTPUT DROP [15:2502] :Drop - [0:0] :Reject - [0:0] :all2all - [0:0] :blacklst - [0:0] :dropBcast - [0:0] :dropInvalid - [0:0] :dropNotSyn - [0:0] ...
Die Beispiel-IP-Adresse mit dem SIP-Problem ist z.B. 10.10.89.xxx, die kommt in dieser Ausgabe von "iptables-save" gar nicht vor.
Die Konfiguration (Teile daraus) in /etc/shorewall:
/etc/shorewall/masq: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0 10.10.0.0/16
/etc/shorewall/nat: leer
/etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT fw all ACCEPT loc fw REJECT #loc fw ACCEPT net all DROP vpn net ACCEPT net vpn ACCEPT all all REJECT
/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect blacklist loc eth1 detect dhcp vpn ppp+ detect dhcp
/etc/shorewall/shorewall.conf: STARTUP_ENABLED=Yes VERBOSITY=1 LOGFILE=/var/log/shorewall LOGFORMAT="Shorewall:%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL=info TCP_FLAGS_LOG_LEVEL=info RFC1918_LOG_LEVEL=info SMURF_LOG_LEVEL=info LOG_MARTIANS=No IPTABLES= PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SHOREWALL_SHELL=/bin/sh SUBSYSLOCK=/var/lock/subsys/shorewall MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE= IPSECFILE=zones IP_FORWARDING=On ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=No TC_EXPERT=No CLEAR_TC=No MARK_IN_FORWARD_CHAIN=No CLAMPMSS=No ROUTE_FILTER=No DETECT_DNAT_IPADDRS=No MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX= DISABLE_IPV6=Yes BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=Yes RFC1918_STRICT=No MACLIST_TABLE=filter MACLIST_TTL= SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=No IMPLICIT_CONTINUE=Yes HIGH_ROUTE_MARKS=No BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT TCP_FLAGS_DISPOSITION=DROP
Könnte mich jemand auf den richtigen Weg bringen? Ich habe leider keine Idee wo ich da suchen könnte. Ist es ein Kernel-Problem? Ist Shorewall schuld? Was könnte sonst noch schuld sein? Wie kann ich den Fehler beheben?
Liebe Grüße Günther
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (2)
-
Günther Zisham -
Karl Kehlenbrink