Gast vlan NUR für Internet

Ich habe mir jetzt eine Testdomain gebaut. Aber mit der Firewall und den Routen komme ich noch durcheinander. Immerhin kann ich aus meiner rdomain heraus ins Internet. Auf das Gateway habe ich nur per TCP Zugriff, aber nicht per UDP.
Code: 
anchor "arbeit" quick on rdomain 40 {
        pass out log on rdomain 40 to !vlan40 nat-to (egress) rtable 0
        pass in log on rdomain 40 proto udp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0 tag VLAN40
        pass in log on rdomain 40 proto tcp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0
        pass in log on rdomain 40 proto tcp to vlan40 port 80 rdr-to 192.168.21.1 rtable 0
        pass in log on rdomain 40 proto tcp to vlan40 port 443 rdr-to 192.168.21.1 rtable 0
}
Auch sehe ich die Pakete nicht in den anderen Regeln. Sollte es nicht noch eine Regel für egress out geben? Ohne rdomains ist das doch so.
 
Ich habe mit der rdomain weiter gebastelt. Kann es sein, dass bei Paketen aus der rdomain nur die Regeln der rdomain gelten und alle anderen ausgeschaltet sind? Wenn ich ein pass out einfüge und das nat-to mittels eines Matches erledige, dann kann ich mein gesamtes Netzwerk erreichen. Das verstehe ich nicht wirklich unter Abschottung. Es greift dann keine andere Regel mehr...?!?!
 
Das ist isoliert schwieriger zu betrachten.. der "anchor" greift hier halt alles ab - und das "quick"; wieso sollten dann noch andere Regeln gelten.

PS: wenn im anchor schon 'on rdomain 40' steht, brauchst Du das innerhalb des anchors nicht nochmal wiederholen - das aendert funktional aber nix.
 
Ein anchor Arbeit in rdomain reicht .
Die Regeln sollten in Interface beinhalten
Und nicht die rdomain weil du so alle
Interfaces der rdomain an sprichst
.
Eine rdomain ist wie ein eigener
Router / Firewall zu betrachten und
Benötigt somit für inbound oder
Outbound Regeln.
Wichtig ist du beachten ist das immer
Vor der Pf Regel ein Routing lookup
Gemacht wird, deswegen ist
Das Default GW so wichtig in der
Rdomain.

Holger
 
Erst einmal Danke für die Infos. Ich habe in den Regel im anchor noch die rdomain stehen, da sie vorher mal außerhalb des anchors standen.
Dass eine rdomain wie eine eigene Firewall ist, dass ist auch mein Verständnis. Allerdings taucht ein Paket aus der rdomain 40 nicht mehr in der Firewall der rdomain 0 auf. Das irritiert mich.
Zunächst würde ich gerne das Problem mit UDP lösen. Ich hätte nämlich gerne DNS in der rdomain 40. Mit TCP funktioniert das auch schon, aber nicht mit UDP. Da bekomme ich bei dem lokalen DNS Server, also 192.168.40.1 in der rdomain 40, einen Timeout. UDP mit externen DNS-Servern, z.B. google funktioniert. Hat da jemand von Euch eine Idee?
In den vielen Beispielen ist mir bis jetzt auch kein DNS aufgefallen. Oft wird nur TCP angeführt und dann darauf verwiesen, dass der Rest analog funktioniert.
PS: Wenn ich das quick beim anchor entferne, dann funktioniert meine rdomain auch nicht richtig. Aber ich habe auch eine ganze Menge anderer Regeln, da es sich hier um meine Firewall zu Hause handelt. Wenn Euch der "Rest" nicht stört, dann kann ich gerne mal die komplette pf.conf posten.
 
Naja.. wenn Du im "globalen" noch so ein UDP "catch-all" drin hast, ist das packet ggfs nicht mehr matching zu der Regel in rdomain 40.
Und Rueckwege nicht vergessen..
 
Ich habe das UDP-Problem weiter einkreisen können. Die Antwort erfolgt anscheinend vom "falschen" Port. Hier ein Dump mit Google:
Code: 
11:35:44.713459 192.168.40.2.39462 > 8.8.8.8.53: 8614+ [1au] A? www.han.de.(51)
11:35:44.724184 8.8.8.8.53 > 192.168.40.2.39462: 8614 1/0/1 A 92.51.145.18(55) [tos 0x80]
Und hier mit dem lokalen DNS:
Code: 
11:34:23.267075 192.168.40.2.33197 > 192.168.40.1.53: 1900+ [1au] A? www.han.de.(51)
11:34:23.267195 192.168.40.1.52618 > 192.168.40.2.33197: udp 55
11:34:23.267498 192.168.40.2 > 192.168.40.1: icmp: 192.168.40.2 udp port 33197 unreachable
Bei Google erfolgt die Antwort vom Destination-Port, lokal aber nicht. Wie kommt es dazu und wie kann ich das abstellen?
 
Da koennte ein nat-to mit reinhirschen.. ist der dump von dem device/interface mit 192.68.40.1?

Vielleicht doch mal das ganze Brimmborium :)
 
Ok, Du haast es so gewoll ;):
Meine pf.conf:
Code: 
#       $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# increase default state limit from 10'000 states on busy systems
set limit states 100000

# Block all Netbios service. 137=name, 138=datagram, 139=session
# Block MS/Windows hosts2 name server requests 81
# 445=microsoft-ds 135=DCE endpoint resolution
# 1900=UPnP 3544=Teredo
bad_ports = "{ 81 135 137:139 445 1900 3544 }"

table <mobile-home> persist file "/etc/mobile-home.conf"

table <internet> persist const { arbeit:network lan:network haus:network gast:network smarthome:network }

dumont = "192.168.93.2"
mail = "192.168.21.20"
mail_ports = "{ imap imaps submission }"

table <martians> const  { 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 \
                        192.0.0.0/24 192.0.2.0/24 192.88.99.0/24 192.168.0.0/16 198.18.0.0/15 \
                        198.51.100.0/24 203.0.113.0/24 224.0.0.22 240.0.0.0/4 255.255.255.255/32 \
                        ::/128 ::/96 ::1/128 ::ffff:0:0/96 100::/64 2001:10::/28 2001:2::/48 \
                        2001:db8::/32 3ffe::/16 fec0::/10 fc00::/7 }

table <local> persist const { lan:0:network arbeit:0:network haus:0:network smarthome:0:network }
table <teredo> const { 192.168.21.67 }
table <leased> persist
table <abandoned> persist
table <changed> persist

set reassemble yes
set block-policy return
set loginterface egress
set skip on { enc0 tun }

set limit table-entries 400000

match in all scrub (no-df random-id)

pass log quick on lo0
pass log quick on lo40
block log

block in quick log on ! em1 from { urpf-failed }
block in quick log on ! em1 from { no-route }
block in quick proto {tcp,udp} to port $bad_ports

# ICMP
pass quick inet6 proto icmp6

# DHCPv6
pass in on em1 inet6 proto udp from fe80::/10 port dhcpv6-client to fe80::/10 port dhcpv6-server no state label DHCPv6
pass in on em1 inet6 proto udp from fe80::/10 port dhcpv6-server to fe80::/10 port dhcpv6-client no state label DHCPv6


anchor "arbeit" on rdomain 40 {
        block log
        pass in log proto udp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0 keep state (floating)
        pass in log quick proto tcp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0
        pass in log proto tcp to vlan40 port 80 rdr-to 192.168.21.1 rtable 0
        pass in log proto tcp to vlan40 port 443 rdr-to 192.168.21.1 rtable 0 keep state (floating)
        pass out log
        # pass in log to !vlan40 nat-to (egress) rtable 0
        match out log to vlan40:network nat-to 192.168.21.1 rtable 0
        match out log to !vlan40:network nat-to (egress) static-port rtable 0
        match log proto udp to port 53
        match log proto udp from port 53
}
match log proto udp to port 53
match log proto udp from port 53
pass out quick log to vlan40:network nat-to vlan40 rtable 40
#
# IN
#


# Lan:network
pass in on lan

# Mobile Home
pass in on grid from <mobile-home> label MOBILE-WOPR

# SSH
pass in log proto tcp to port ssh label SSH

# DNS
pass in log on !egress proto { tcp udp } to (self) port domain label DNS
pass in log proto { tcp udp } to (self) port domain label DNS

# mDNS
pass in on lan proto udp to lan:network port mdns label mDNS

# NTP
pass in on !egress proto udp to (self) port ntp label NTP

# DHCP
pass in on !em1 proto udp from port bootpc to port bootps label DHCP
pass in on em1 proto udp from port bootps to port bootpc label DHCP-DG

# HTTP
pass in on lan proto tcp to lan port { http https } label HTTP

# LDAP
pass in on lan proto tcp to lan port ldaps label LDAP

# MQTT
pass in on lan inet proto tcp to lan port { 1883 8883 } label MQTT
pass in on smarthome inet proto tcp to smarthome port { 1883 8883 } label MQTT

#
# Forwarding
#
pass in log on !egress to !(self) label ROUTING

#
# Redirects
#

match out to 192.168.10.0/24 nat-to 192.168.10.211
match out on smarthome nat-to smarthome

#
# OUT
#
pass out log ! received-on any
pass out log proto {icmp icmp6} ! received-on any


pass out on { grid haus smarthome } received-on lan label LAN-OUT

pass out on lan proto tcp from $dumont to $mail port $mail_ports label DUMONT-MAIL
pass out on lan from <mobile-home>

# -> INTERNET
pass out log on egress to !<martians>
#pass out log quick on egress from (self) to vlan40:network nat-to 192.168.40.1 rtable 40
pass out log on egress from (self) label SELF
pass out log on egress from lan:network label LAN
pass out on egress received-on arbeit label ARBEIT
pass out on egress received-on gast label GAST
pass out on egress received-on haus label HAUS
pass out on egress received-on smarthome label SMARTHOME
pass out log on egress tagged VLAN40 label V40
match out log on egress inet to ! vlan40:network nat-to (egress)
match out on egress inet6 from fc00::/7 nat-to (egress)
Ich habe in rdomain 0 noch eine Route für das Netzwerk 192.168.40.0/24:
Code: 
route add -net 192.168.40.0/24 -iface 192.168.40.1
Und hier der Routing-Table 40:
Code: 
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            192.168.40.1       UGS        0    12828     -     8 vlan40
192.168.40/24      192.168.40.1       UCn        1        0     -     4 vlan40
192.168.40.1       fe:e1:ba:d1:10:08  UHLhl      1      394     -     1 vlan40
192.168.40.2       90:1b:0e:92:47:5d  UHLc       1      563     -     3 vlan40
192.168.40.255     192.168.40.1       UHb        0        0     -     1 vlan40
 
Smarthome hat die 192.168.201.0/24. Was ist das Problem mit der pass out Regel? Ich nehme sie erst einmal raus.
 
Mit der pass out Regel erhalte ich ein Paket zurück.
Auf dem Testrechern mit IP 192.168.40.2 mache ich ein dig @192.168.40.1 www.han.de.
Mit der Regel sieht der Traffic wie folgt aus:
Code: 
14:36:18.637960 192.168.40.2.28742 > 192.168.40.1.53: 41217+ [1au] A? www.han.de.(51)
14:36:18.638101 192.168.40.1.53537 > 192.168.40.2.28742: udp 55
14:36:18.638373 192.168.40.2 > 192.168.40.1: icmp: 192.168.40.2 udp port 28742 unreachable
Ohne die Regel:
Code: 
14:35:44.283981 192.168.40.2.30908 > 192.168.40.1.53: 62044+ [1au] A? www.han.de.(51)
 
Ich habe jetzt eine funktionierende Version:
Code: 
anchor "arbeit" on rdomain 40 {
        block log
        match in log to 192.168.40.1 nat-to 192.168.21.1 rtable 0
        pass in log proto udp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0 keep state
        pass in log proto tcp to vlan40 port 53 rdr-to 192.168.21.1 rtable 0 keep state
        pass in log proto tcp to vlan40 port 80 rdr-to 192.168.21.1 rtable 0
        pass in log proto tcp to vlan40 port 443 rdr-to 192.168.21.1 rtable 0
        pass out log
        match out log to !192.168.0.0/16 nat-to (egress) static-port rtable 0
}
Das nat-to muss vor dem redirect stehen. Jetzt muss ich noch die Ports einschränken, da rdate nicht funktioniert. Den ntpd habe ich direkt in die rdomain eingebunden. Sollte man da auch einen redirect verwenden?
 
Wie kann ich jetzt verhindern, dass man aus der rdomain 40 alle Adressen der anderen lokalen Netze erreichen kann? So ist das noch keine Abschottung, da eine Kommunikation zu z.B. 192.168.21.2 möglich ist. Ich sehe im pflog nur die Regeln der rdomain 40.

Oder muss ich dazu den Internetzugang in eine eigene rdomain verlegen?
 
Ich habe mit der rdomain etwas gespielt und bin (in meinem Anwendungsfall) nicht wirklich überzeugt. Der Aufwand ist nicht unerheblich und meiner Meinung nach fehlt eine Steuerung beim Übergang von einer rdomain in eine andere. So kann ich anscheinend nur in rdomain 40 steuern, welche Adressen aus rdomain 0 zu erreichen sind. Das macht das Regelwerk für mich unübersichtlich und damit fehleranfällig. Das Problem lässt sich zwar durch geschicktes Zuschneiden der rdomains einschränken, aber dass ich beim Zugang einer rdomain aus einer anderen die Berechtigungen für die Zieldomain in der Quelle setzen muss und damit ggf. alle Einschränkungen der Zieldomain wiederholen muss finde ich "unschön". Somit bleibe ich bei einem Routing/Firewall ohne rdomains. Auf die "Martians" könnte man auch ohne rdomain mittels self-Keyword verzichten, wie schon erwähnt wurde.

Sollte ich bei den rdomains etwas übersehen haben, so bin ich über Anmerkungen nach wie vor dankbar. :)
 
Sowas braucht doch ein bischen design, das ist nichts, was man mal so "dazu klatscht".
Ich konnte nicht soviel Hirnschmalz mit reinstecken, aber mit Holzhammer-Ansatz ist schwer (erstmal alles wieder routen).

Und noch einer zum Hausbau.. wenn man zwei rdomains direkt verbinden will: pair(4)
 
Ok, das wäre dann aber ein anderer Ansatz. Ich habe nur ein oder zwei Mal von der Verwendung von pair gelesen. Meist in sehr komplizierten Setups. Mein Versuch war es, ein Netzwerk komplett zu isolieren. Das Vlan 40 war auch neu und wurde außer einer VM nicht weiter verwendet. Ein Testnetzwerk also. Ich würde gerne mehr darüber erfahren, aber die Informationen sind rar. Ich nehme an, dass man die Verbindungen zu anderen Netzwerken dann über pair(4) realisiert. Laufen denn dann die Pakete erneut über PF? Oder bekomme ich dann ein anderes in Device?
Mein Problem ist ja, dass die Pakete, die mittels pass von einer rdomain in eine andere transferiert wurden, nicht wieder durch die Firewall liefen. Deshalb konnte ich mich aus dem Testnetz heraus mit meiner gesamten Infrastrukture um ich herum verbinden. Und dann die Einschränkungen, die für andere Netze gelten, auch noch einmal beim rdomain-Übergang abzubilden, scheint mir nicht zewckmäßig.
Kennt Ihr, @double-p oder @mark05, noch weitere Informationen?
 
Ein "pair" ist wie ein Kabel zwischen rdomains, siehe manpage und zumindest meinen Vortrag von damals.

Es geht immer alles durch pf, dass ein interface traversiert. Der "shortcut" gegenueber den rules ist dann der state im pf,
der im default "global" ist. (zB eine packet mit DNS-query geht auf extif0 raus und hat dort eine nat-to regel, wenn die "passende"
Antwort auf extif0 wieder ankommt, darf das ohne extra regel durch. das gilt aber auch, wenn mehrere interface involviert sind - solange
es halt "passt"
 
Wenn du pair verwendest ist der Effekt der rdomain verloren.

Du braucht maximal eine nat Regel für outbound nat in das Internet , sie muss nur geschickt
Geschrieben werden

Z.b.

Pass in on vlan10 inet from vlan10:Network top ! Lan:Network rtable 0 nat-to ( pppoe0 )

Das noch 2 der für DNS und ntp und gut ist.

Ein Block ist nicht nötig das nix Ohne entsprechende Pf Regel inbound zur rdomain geht , und in der rdomain nur
Den Gast Traffic als inbound auf vlan10 hast.

Holger , am Roten Meer
 
Das kann man zu pair nicht generell sagen, wenn ich zB 6 segmente habe und 2 verbinden will (ohne 378613 rdr-tos ..), dann ist das "legit" ;-)

pb, noch nicht an der Adria ;-)
 
mark05 schrieb:
Wenn du pair verwendest ist der Effekt der rdomain verloren.

Du braucht maximal eine nat Regel für outbound nat in das Internet , sie muss nur geschickt
Geschrieben werden

Z.b.

Pass in on vlan10 inet from vlan10:Network top ! Lan:Network rtable 0 nat-to ( pppoe0 )

Das noch 2 der für DNS und ntp und gut ist.

Ein Block ist nicht nötig das nix Ohne entsprechende Pf Regel inbound zur rdomain geht , und in der rdomain nur
Den Gast Traffic als inbound auf vlan10 hast.

Holger , am Roten Meer
Zum Vergrößern anklicken....
Jetzt habe ich mehr als die beiden Netze. Dann lande ich in der Regel ja doch wieder bei der "Mars"-Tabellen, ohne die es hier ja gehen sollte. :)
 
Ich gehe immer vom ursprünglichen
Sxwnario aus , 1 vlan mit einem IP Netz
In einer rdomain. Der Rest ist rdomain 0
Hier sollte vlan netz outbound ins Internet
, ansonsten nix erreichen können.

Holger

P.s. scheiss Wind hier
 
Ok, aber wo ist jetzt der Vorteil der rdomain in diesem Szenario? Wenn ich die outbound-rule aus der rdomain zum Internet nicht einschränke, dann ist die rdomain 0 offen. Wenn das nicht wäre, dann würde ich den Vorteil ja verstehen. Sieht es denn anders aus, wenn ich das egress interface auch in eine eigene rdomain lege? Ich vermute mal ja...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben