OpenSuse 13.1 - NAT - Shorewall

Hallo!

Ich verwende OpenSuse 13.1 und setze als Firewall Shorewall (shorewall-4.5.20-2.1.3.noarch) ein.

Ich habe 2 Netzwerk-Interfaces (eth0 = Internet, eth1 = internes Netz)

NAT habe ich konfiguriert und es funktioniert eigentlich auch. Nur manche Pakete landen trotzdem am eth0 mit der IP-Adresse 10.10.x.y. Dann kommt natürlich auch keine Verbindung dabei zu stande. Gesehen habe ich z.B. https (tcp/443) und sip (udp/5060) und kann es mir nicht erklären. Bei anderen internen IP-Adressen funktioniert es dann komischerweise.

Hat da jemand eine Idee, was da passiert?

Grüße,
Günther

Hallo Günther,

kannst Du bitte die genaue Netzwerkkonfiguration (eth0 und eth1) posten und sagen, wer wohin kommunizieren kann? Das kommt so im Moment leider nicht ganz klar rüber.
Genauso, was erreicht werden soll. Hast Du eine DMZ eingerichtet?

Viele Grüße,
Sarah

Hallo!

Danke schon mal für das Interesse.

Hier ist die schematische Darstellung:

Clients (10.10.x.y)
|
Server eth1 (10.10.x.254)
Shorewall mit NAT
Server eth0 (193.x.y.z)
|
Internet

Das Problem ist, dass manche Client-Verbindungen trotz NAT beim Server (2 Netzwerkkarten) mit einer internen 10.10-Adresse raus ins Internet kommen. Am Interface eth0 kann ich dann per tcpdump diese Pakete sehen. Eigentlich dürfte da ausgehend nur mehr die eine offizielle Server-IP-Adresse (193.x.y.z) zu sehen sein, dem ist aber nicht so.
Die ins Internet ausgehenden IP-Pakete mit 10.10.x.y werden von den Routern im Internet verworfen, womit diese entsprechenden Client-Verbindungen dann auf Timeout laufen. Andere Clients mit 10.10.x.y werden aber auf genau dem selben Weg ordnungsgemäß geNATet, da funktioniert diese Verbindung dann ohne Probleme.
Der Server hat noch ein weiteres Interface (san0 für die iSCSI-Anbindung), das tut aber hier nichts zur Sache.

Soll ich noch weitere Infos (spezielle Konfigurations-Dateien) beilegen?

hier mal ein paar Dateiinhalte:

/etc/shorewall/masq:

#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST
eth0                    10.10.0.0/16    193.x.y.z

/etc/shorewall/interfaces:

#ZONE           INTERFACE               OPTIONS
net             eth0                    blacklist
loc             eth1                    dhcp
san             san0                    -
vpn             ppp+                    dhcp

/etc/shorewall/zones:

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
loc     ipv4
san     ipv4
net     ipv4
vpn     ipv4

/etc/shorewall/policy:

#SOURCE DEST    POLICY          LOG     LIMIT:          CONNLIMIT:
#                               LEVEL   BURST           MASK
loc     san     REJECT          info
net     san     REJECT          info
san     loc     ACCEPT
loc     net     ACCEPT
fw      all     ACCEPT
loc     fw      REJECT
#loc    fw      ACCEPT
vpn     net     ACCEPT
net     vpn     ACCEPT
net     all     DROP
all     all     REJECT

/etc/shorewall/rules:


#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            U
#                                                       PORT    PORT(S)         DEST            LIMIT           G
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
#
# Sicherheit:
REJECT  loc     san:192.168.200.0/24    all
REJECT  loc     fw:192.168.200.0/24     all
#
#
ACCEPT  all             all             icmp
#
# all --->>> fw
#
ACCEPT  all             fw              tcp     smtp
ACCEPT  all             fw              tcp     domain
ACCEPT  all             fw              udp     domain
ACCEPT  all             fw              tcp     http
ACCEPT  all             fw              tcp     pop3
...viele Zeilen mehr (aber keine NAT-Ausnahmen)...

Grüße
Günther

Hallo!

Habe neue Erkenntnisse gewonnen:
Durch einen temporären Konfigurationsfehler bin ich auf etwas interessantes draufgekommen! Die Adresse, die als MASQ-Adresse angegebene IP-Adresse wird anscheinend für laufende Verbindungen trotz Konfigurations-Änderung und Shorewall-Restart nicht mehr geändert!!

Datei /etc/shorewall/masq (vorher)

#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST
eth0                   10.10.0.0/16    192.168.42.250

Dann habe ich mit einem Client 10.10.99.15 auf der Seite von eth1 einen Ping gestartet und laufen lassen. (klar, die ICMP-Request-Pakete kommen auf eth0 mit IP 192.168.42.250 daher)

Dann habe ich die Datei /etc/shorewall/masq geändert:

#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST
eth0                    10.10.0.0/16    192.168.42.208

Anschließend den Befehl:

shorewall restart

Die ICMP-Request-Pakete kommen aber auf der eth0-Seite immer noch mit 192.168.42.250 daher!!! :o:’(

ein

iptables-save|grep 192.168.42.250

ergibt aber kein Ergebnis mehr!!

Ich glaube, dass das genau der Fehler von oben ist. Einziger Unterschied oben: da kommen evtl. schon Pakete vor dem Start von Shorewall daher, die dann auch nach dem Start von Shorewall noch unMASQed weitergeleitet werden.

Gibt es da irgendeinen Cache, den ich händisch leeren kann?
Ein Reboot hilft auch, ist aber nicht allzu elegant?

Danke,
Günther

Shorewall ist eine Firewall. Willst Du Firewall-Regeln löschen oder was meinst Du mit “Cache leeren/ löschen”?
Shorewall hat eine sehr gute Dokumentation.
Mit “shorewall clear” kannst Du die Regeln löschen. Es gibt aber auch noch weitere hilfreiche Befehle.

Hallo!

Ich habe Shorewall als “Frontend” für die Kernel-IP-Tables-Regeln verstanden.

Ich dachte, mit “shorewall restart” hätte ich die alten Regeln schon über Bord geworfen und die neuen mit der richtigen IP-Adresse in Betrieb genommen. Der Befehl “iptables-save” bestätigt das ja auch.

Jetzt hätte ich den Verdacht, dass irgendwo noch (ähnlich einem Arp-Cache) diese alte Masq-IP-Adresse für die bereits bestehenden Verbindungen in Verwendung sein könnte. Ich habe nur keine Ahnung wo im Speicher (RAM).

Nein. Shorewall ist eine richtige Firewall mit IPTABLES-Regeln.
Ich würde Dir empfehlen arping unter One-to-one NAT auszuprobieren: http://shorewall.net/NAT.htm
Wenn man Server für das WAN und Intranet zugänglich machen will, verwendet man normalerweise zusätzlich eine 3. Netzwerkkarte für die DMZ (Demilitarisierte Zone). Dort stehen dann die Webserver, die zur Verfügung stehen sollen. Das ist um einiges sicherer.

Kernel-Konfigurationen findest Du unter: http://shorewall.net/kernel.htm

Hallo!

Arping habe ich ausprobiert, leider ohne den gewünschten Erfolg.
Das unter http://shorewall.net/NAT.htm angeführte Szenario ist leider bei mir nicht das Problem: nicht das ISP-Caching sondern das Caching am eigenen Server stellt das Problem dar. Somit sollte man das ja eigentlich besser im Griff haben, denkt man.

Auch http://shorewall.net/kernel.htm hat mir da nicht wirklich weiter geholfen, die ich die Parameter eh schon alle aktiviert habe und mehr.

Auch gibt es bei mir keinen internen Web-Server. Bei mir geht es um echte Clients, die falsch nach außen genattet werden. (10.10.x.y-IP-Adresse statt offizieller IP-Adresse des Gateway-Servers, siehe erste Posts)