pf rdomains Probleme trotz default route

yggdrasil

Well-Known Member
Servus zusammen,

ich versuche derzeit, mittels Rdomains VPNs auf meinem Router zu segregieren. Das Übersetzen von einer Rdomain in die andere per pf funktioniert, ein Ping geht durch zum Zielsystem, doch dessen Antwort wird nicht zurückgeleitet. Ich weiß, daß das üblicherweise an einer fehlenden Route liegt, aber ich hab default routen in alles rdomains gesetzt, mal per blackhole route auf das loopback interface, mal per regulärer route auf ein extra eingebrachtes vether-Interface, oder Kombinationen/Variante davon. Nicht scheint zu fruchten. forwarding per sysctl ist auch gesetzt.

# pfctl -sr
block return log all
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from ! (egress:network) to any set (prio(5, 7)) nat-to (egress:0) round-robin
pass on ! egress all flags S/SA
pass out on egress all flags S/SA
pass in log (all, to pflog1) quick on aggr0 inet from any to 172.19.57.95 flags S/SA rtable 99 nat-to (em0) round-robin
pass in log (all, to pflog1) quick on aggr0 inet from any to 10.182.225.131 flags S/SA rtable 101 nat-to (tun1) round-robin
pass inet proto icmp all
pass proto ipv6-icmp all
pass in log (all, to pflog1) on aggr0 inet6 from any to fd4b:5320:4954:6464::/96 flags S/SA rtable 101 af-to inet from (tun1) round-robin
Die af-to-Regel war meine ursprünglicher Versuch, aber ich habe die beiden oberen rdomain zum testen eingesetzt, um sicherzustellen, dass keine NAT64-Probleme ursächlich sind.

# ifconfig tun1
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 101 mtu 1400
description: OpenConnect
index 13 priority 0 llprio 3
groups: tun vpn
status: active
inet 10.182.253.188 --> 10.182.253.188 netmask 0xff000000

# ifconfig em0
em0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> rdomain 99 mtu 1500
lladdr 00:0d:b9:5a:1d:dc
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 172.19.57.96 netmask 0xffffff00 broadcast 172.19.57.255

# route -T 99 show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 172.19.57.96 UGSB 0 197 - 8 em0
localhost localhost UHl 0 0 32768 1 lo99
172.19.57/24 172.19.57.96 UCn 1 0 - 4 em0
172.19.57.95 00:0d:b9:5a:1e:fc UHLc 0 38 - 3 em0
172.19.57.96 00:0d:b9:5a:1d:dc UHLhl 1 39 - 1 em0
172.19.57.255 172.19.57.96 UHb 0 0 - 1 em0

# route -T 101 show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default localhost UGSB 0 6 32768 8 lo101
10.0.20.9 10.182.253.188 UGHS 0 0 - 8 tun1
10.34.34/24 10.182.253.188 UGS 0 0 - 8 tun1
10.100/16 10.182.253.188 UGS 0 0 - 8 tun1
10.101/16 10.182.253.188 UGS 0 0 - 8 tun1
10.103/16 10.182.253.188 UGS 0 0 - 8 tun1
10.182.58/24 10.182.253.188 UGS 0 0 - 8 tun1
10.182.60/24 10.182.253.188 UGS 0 0 - 8 tun1
10.182.61/24 10.182.253.188 UGS 0 0 - 8 tun1
10.182.80/21 10.182.253.188 UGS 0 0 - 8 tun1
10.182.88/21 10.182.253.188 UGS 0 0 - 8 tun1
10.182.80.71 10.182.253.188 UGHS 0 0 - 8 tun1
10.182.80.72 10.182.253.188 UGHS 0 0 - 8 tun1
10.182.104/24 10.182.253.188 UGS 0 0 - 8 tun1
10.182.104.64/26 10.182.253.188 UGS 0 0 - 8 tun1
10.182.120/24 10.182.253.188 UGS 0 0 - 8 tun1
10.182.151.176/28 10.182.253.188 UGS 0 0 - 8 tun1
10.182.225.128/26 10.182.253.188 UGS 0 47 - 8 tun1
10.182.253.188 10.182.253.188 UHhl 25 72 - 1 tun1
10.182.253.188 10.182.253.188 UH 0 0 - 8 tun1
10.213.25.80/29 10.182.253.188 UGS 0 0 - 8 tun1
10.213.28/24 10.182.253.188 UGS 0 0 - 8 tun1
10.213.28.0/26 10.182.253.188 UGS 0 0 - 8 tun1
10.213.57/24 10.182.253.188 UGS 0 0 - 8 tun1
10.213.65/24 10.182.253.188 UGS 0 0 - 8 tun1
localhost localhost UHhl 1 2 32768 1 lo101
172.23.6.0/26 10.182.253.188 UGS 0 0 - 8 tun1
172.23.120.0/26 10.182.253.188 UGS 0 0 - 8 tun1
192.168/16 10.182.253.188 UGS 0 0 - 8 tun1

Übersehe ich irgendwas offensichtliches?

Danke!
 
hi

also eine default route auf sich selber ist nicht gut ( rdomain 99 )

pro rdomain sollte es eine default route , zumindest , 127.0.0.1 geben ( je rdom ),

die ausnahme ist wenn du in der rdom einen process hast der auf lo LISTEN.

wenn das routing funktioniert sollte ein ein ping auch ohne nat funktionieren .
z.b. auf die ip von em0 ( rdom 99 ) und die local ip von tun0 in rdom 101.

da pf stateful ist braucht man keine regel fuer das anwort paket.

du kannst alternativ zum testen mal bei einer der regel die in die rdom zeigen,
ein nat-to (em0) setzen.

mit tcpdump prüfen.
 
Hallo mark05,

also eine default route auf sich selber ist nicht gut ( rdomain 99 )

pro rdomain sollte es eine default route , zumindest , 127.0.0.1 geben ( je rdom ),
Ich hab auch Varianten versucht, wie lo99 mit 127.0.0.1 erzeugen, und default route darauf zeigen lassen probiert, oder ein vether if mit ner IP auf die die default route zeigt. Kein Erfolg. Laut so ziemlich allen Quellen, die ich gefunden habe, sollte das auch kein Problem sein, denn die Route kann auch eine blackhole route sein, hauptsache, ich hab eine Route für das Paket, damit ich durch den initialen Routencheck im Kernel komme, und PF überhaupt das Paket zu sehen bekommt.

die ausnahme ist wenn du in der rdom einen process hast der auf lo LISTEN.
Ich weiß leider nicht, was du hier meinst.

wenn das routing funktioniert sollte ein ein ping auch ohne nat funktionieren .
z.b. auf die ip von em0 ( rdom 99 ) und die local ip von tun0 in rdom 101.

Wenn ich eine zusätzliche Regel einführe
pass in quick log(all, to pflog1) on $int_if inet to 172.19.57.96 rtable 99
Kann ich die IP auf em0 anpingen. Sonst aber keine Änderung. Ich wüßte auch nicht, welchen Effekt das erzeugen sollte.

da pf stateful ist braucht man keine regel fuer das anwort paket.
Hab ich ja auch nicht.

du kannst alternativ zum testen mal bei einer der regel die in die rdom zeigen,
ein nat-to (em0) setzen.
? Das hab ich doch schon?

mit tcpdump prüfen.
Hab ich schon überall am laufen. em0 (bzw tun0 wenn ich die andere rdomain teste) sieht echo request und reply, aber alle anderen (aggr0, pflog1, wo ich (s.o.) alles aus den regeln loggen lasse), sehen nur die request Pakete. Reply kommt hier nie an.
 
pf greift das packet nicht.

mal ein beispiel

/etc 37>cat hostname.lo10
rdomain 10
group vpn
inet 127.0.0.1/8
!/sbin/route -n -T 10 exec /usr/sbin/ftp-proxy -D 7
!/sbin/route -n -T 10 add default 127.0.0.1


/etc 41>cat hostname.em0
rdomain 10
inet 172.19.57.96/24
up

nun pf
from rdomain 0 ( root ) to rdomain 10 vpn

pass out on (default gw if ) from lan:network to em0:network rtable 10
( alternativ kannst du auch
pass in on lan from lan:network to em0:network rtable 10
mach kannst du so keinen , bzw nicht ohne weiteres , traffic von der firewall selbst aus generieren

from rdomain 10 vpn to rdomain 0
pass in on lo10 inet from em0:network to lan:network rtable 0


das sollte reichen um aus beiden richtungen traffic zu initieren.

holger
 
pf greift das packet nicht.
Ja, das return paket kommt nicht zu pf (oder pf ordnet es nicht dem state zu)

Dein Beispiel hab ich hier (mit rdomain 99 statt 10) auch schon versucht. jetzt gerade zur Sicherheit auch noch mal.

nun pf
from rdomain 0 ( root ) to rdomain 10 vpn

pass out on (default gw if ) from lan:network to em0:network rtable 10
( alternativ kannst du auch
pass in on lan from lan:network to em0:network rtable 10
mach kannst du so keinen , bzw nicht ohne weiteres , traffic von der firewall selbst aus generieren
Meinst du mit "default gw if" das IF, auf dem die default route in rdomain 10/99 liegt? Also das loopback? Jedenfalls kann dein erster Vorschlag doch eigentlich nicht funktionieren, da rtable-Änderungen nur bei "in"-Regeln greifen kann, bei "out"-Regeln ist es zu spät.

Deine zweite Regel ist doch genau die Regeln, die ich auch schon hatte. Hab sie nochmal wie folgt versucht:
pass in quick on aggr0 inet from 10.0.0.0/16 to 172.19.57.0/24 flags S/SA rtable 99 nat-to (em0) round-robin
Mit und ohne Nat-to, keine Funktion.

from rdomain 10 vpn to rdomain 0
pass in on lo10 inet from em0:network to lan:network rtable 0


das sollte reichen um aus beiden richtungen traffic zu initieren.
Diese Richtung will ich gar nicht erlauben. Aber ich seh auch nicht, wie "pass in on lo" überhaupt funktionieren kann
 
hi


mit default gw if meine ich das interface bei dem die pakete fuer lan an ankommen.

ich habe das mal nach ge lab 't

/etc 50>route -n -T 10 show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 127.0.0.1 UGS 0 0 32768 8 lo10
127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo10
172.19.57/24 172.19.57.96 UCn 0 0 - 4 em1
172.19.57.96 00:90:0b:23:51:59 UHLl 0 57 - 1 em1
172.19.57.255 172.19.57.96 UHb 0 0 - 1 em1

/etc 18>route -n -T 20 show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 127.0.0.1 UGS 0 1 32768 8 lo20
10.182.253.188 fe:e1:ba:d3:73:99 UHLl 0 0 - 1 vether2
10.182.253.188/32 10.182.253.188 UCn 0 0 - 4 vether2
127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo20

kern.bufcachepercent=90

#hw.setperf=45
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
# debugging
net.inet6.icmp6.nd6_debug=0
# ipsec comp
net.inet.ipcomp.enable=1
net.pipex.enable=1
net.inet.gre.allow=1
net.inet.gre.wccp=1
net.inet.ip.multipath=1
rdomain 0 to rdomain 10 und 20
pass out on em0 from em0:network to ( vether2 ) rtable 20
pass out on lo10 from em1:network to ( vether2 ) rtable 20

pass out on lo10 from em1:network to ( vether2 ) rtable 20


/etc 38>ping 10.182.253.188
PING 10.182.253.188 (10.182.253.188): 56 data bytes
64 bytes from 10.182.253.188: icmp_seq=0 ttl=255 time=1.386 ms
64 bytes from 10.182.253.188: icmp_seq=1 ttl=255 time=0.976 ms
64 bytes from 10.182.253.188: icmp_seq=2 ttl=255 time=0.887 ms

/etc 51>ping -V 10 172.19.57.96
PING 172.19.57.96 (172.19.57.96): 56 data bytes
64 bytes from 172.19.57.96: icmp_seq=0 ttl=255 time=1.242 ms
64 bytes from 172.19.57.96: icmp_seq=1 ttl=255 time=0.892 ms
64 bytes from 172.19.57.96: icmp_seq=2 ttl=255 time=0.850 ms

und noch rdomain 10 nach 20

/etc 68>ping -V 10 -S 172.19.57.96 10.182.253.188
PING 10.182.253.188 (10.182.253.188): 56 data bytes
64 bytes from 10.182.253.188: icmp_seq=0 ttl=255 time=1.637 ms
64 bytes from 10.182.253.188: icmp_seq=1 ttl=255 time=0.925 ms
64 bytes from 10.182.253.188: icmp_seq=2 ttl=255 time=1.048 ms


ich hoffe das hilft

holger
 
Leider nicht wirklich, aber danke für deine Mühen. Ich sehe, dass du immer nur vom OpenBSD Host aus pingst, ich pinge von nem anderen Computer, der auf aggr0 (default rdom 0) verbunden ist. Kannst du das auch mal testen? Und könntest du ein "log(all, to pflogX)" in die "pass out [...] rtable X" Regeln hängen? Denn nach allem was ich sonst zu dem Thema lese ist routing table wechseln outbound eigentlich nicht möglich, ich hätte daher gern mal gesehen, wie das bei dir überhaupt funktionieren kann.
 
regeln
pass out on em0 from em0:network to ( vether2 ) rtable 20
pass out on em0 from em0:network to em1:network rtable 10

pass out log on lo10 from em1:network to ( vether2 ) rtable 20
pass out log on lo10 from em1:network to em0:network rtable 0 nat-to (em0)

das nat-to ist bei der letzen regel notwendigt weil das source netz ( em1)
in der route 0 domain nicht bekannt ist.

man koennte das auch via statischer route gen lo der rtable 0 bekannt machen.

von meinem client aus

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:60:77:59:20
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 172.19.57.10 netmask 0xffffff00 broadcast 172.19.57.255

Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 172.19.57.96 UGS 0 6 - 8 em0
224/4 127.0.0.1 URS 0 30 32768 8 lo0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo0
172.19.57/24 172.19.57.10 UCn 1 0 - 4 em0
172.19.57.10 00:0d:60:77:59:20 UHLl 0 25 - 1 em0
172.19.57.96 00:90:0b:23:51:59 UHLch 1 4 - 3 em0
172.19.57.255 172.19.57.10 UHb 0 0 - 1 em0

PING 192.168.131.110 (192.168.131.110): 56 data bytes
64 bytes from 192.168.131.110: icmp_seq=0 ttl=63 time=1.997 ms
64 bytes from 192.168.131.110: icmp_seq=1 ttl=63 time=1.642 ms
64 bytes from 192.168.131.110: icmp_seq=2 ttl=63 time=1.540 ms

--- 192.168.131.110 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.540/1.726/1.997/0.196 ms


hi

warum sollte outbound routing nicht moeglich sein ?

ein tip noch,test erstmal nur mit den entsprechenden pf ( rtable ) regeln ,
alle anderen regeln die du hast mal weg lassen.

wichtig ist das das routing in ordnung ist und zu verstehen wie routing funktioniert,
in und ausserhalb der rdomain.


mein ganzes netz ist mit rdomain aufgebaut

rdomains fuer
wan1 kabel
wan2 dsl

dmz1 ( xbox/windows isolation )
dmz2 ( mail/webserver ) ich habe 1 feste ip da kabel eine buissnes leitung ist.

rdomain 0 ist lan und wlan

gesteuert und reguliert mit pf.
interessant ist vielleicht auch das ich ipv6 via dsl spreche und ipv4 via kabel
outbound vom lan aus.

wlan sprich nur ipv4 via dsl.

jeweils in die boese internet welt.

holger
 
warum sollte outbound routing nicht moeglich sein ?
Um aus der pf.conf(5) zu zitieren (wird so auf misc@ weitergegeben):
rtable number
Used to select an alternate routing table for the routing lookup.
Only effective before the route lookup happened, i.e. when
filtering inbound.

ein tip noch,test erstmal nur mit den entsprechenden pf ( rtable ) regeln ,
alle anderen regeln die du hast mal weg lassen.

wichtig ist das das routing in ordnung ist und zu verstehen wie routing funktioniert,
in und ausserhalb der rdomain.
Joar, da ich das auf meinem Router einsetze, wollte ich eigentlich nicht zu arg an den Regeln umeinanderpfuschen, aber ich fürchte, ich muss das wirklich mal auf nem separaten Gerät austesten. Dachte ja, ich hätte nur irgend'ne Kleinigkeit übersehen, aber anscheinend isses doch was größeres.

mein ganzes netz ist mit rdomain aufgebaut

rdomains fuer
wan1 kabel
wan2 dsl

dmz1 ( xbox/windows isolation )
dmz2 ( mail/webserver ) ich habe 1 feste ip da kabel eine buissnes leitung ist.

rdomain 0 ist lan und wlan

gesteuert und reguliert mit pf.
interessant ist vielleicht auch das ich ipv6 via dsl spreche und ipv4 via kabel
outbound vom lan aus.

wlan sprich nur ipv4 via dsl.

jeweils in die boese internet welt.
Aus sowas will ich am Ende auch raus. Nur daß ich mich noch nicht zu nem Kabelanschluß als zweitem Internetzugang durchgerungen hab. Aus reiner Neugier, wie regelst du ausgehende Verbindungen? Round-robin?
 
:D

ipv6 via dsl ipv4 via kabel

nur wenn kabel aus fällt schalte ich um , manuel


wlan z.b. geht outbound via dsl in general


ein outbound routing vestehe ich das eine vebindung von inner to outer geht
über eine rdomain hin.

und durch den "pass in on if" greife ich das paket vor dem route lookup am interface ab.

holger
 
Zurück
Oben