Gateway mit PF blockiert RADIUS Authentifizierungen

sins

Active Member
Hallo,

hier wird eine OpenBSD 5.0 RELEASE i386 Maschine (in einer ESXi VM) als Gateway zwischen mehreren Netzen eingesetzt. Sie ist für die Kommunikation zwischen einem Access Point Controller und einem FreeRADIUS Server verantwortlich.

Wenn PF aus ist, funktioniert die Kommunikation einwandfrei.
Wenn PF eingeschaltet wurde, brechen Autnehtifizierungen ab.

Details:
Code:
nat ~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding=1
nat ~ # ifconfig vic1
        [...]
        inet 10.2.90.1 netmask 0xffffff00 broadcast 10.2.90.255
        inet 10.251.148.250 netmask 0xffffff00 broadcast 10.251.148.255
        inet 172.16.148.250 netmask 0xffffff00 broadcast 172.16.148.255
        inet 172.16.2.250 netmask 0xffffff00 broadcast 172.16.2.255
nat ~ # ifconfig vic2
vic2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        [...]
        inet 10.2.91.1 netmask 0xffffff00 broadcast 10.2.91.255
nat ~ # pfctl -sr
pass in all flags S/SA
pass out all flags S/SA
pass in quick on vic0 inet proto tcp from any to (vic0) port = ssh flags S/SA
Ich habe es auch mit den "pass" Parametern "no state" und "flags all" probiert - keine Änderung.

FreeRADIUS Log für eine erfolgreiche Authentifizierung:
Code:
[...]
Login OK: [dolphin-9500] (from client xnet port 918 cli 00-0B-6C-2C-EF-DA)

FreeRADIUS Log für eine fehlgeschlagene Authentifizierung:
Code:
[...]
Waking up in 3.8 seconds.
WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WARNING: !! EAP session for state 0x32c3992035d694a9 did not finish!
WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility
WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Ready to process requests.
Offensichtlich ist mit den Zertifikaten alles in Ordnung, sonst würde die Authentifizierung mit ausgeschaltetem PF nicht funktionieren.

PF Log zeigt leider nichts außergewöhnliches:
Code:
nat ~ # tcpdump -n -e -ttt -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Jan 23 13:06:29.021700 rule def/(fragment) pass in on vic2: 10.2.91.201.32771 > 10.251.148.199.1812: Axs? id:2f [1797] [|radius] (frag 39547:1480@0+) (DF)
Jan 23 13:06:29.021723 rule def/(fragment) pass in on vic2: 10.2.91.201 > 10.251.148.199: (frag 39547:325@1480) (DF)
Jan 23 13:06:31.734158 rule def/(fragment) pass in on vic2: 10.2.91.201.32771 > 10.251.148.199.1812: Axs? id:6e [1797] [|radius] (frag 39548:1480@0+) (DF)
Jan 23 13:06:31.734179 rule def/(fragment) pass in on vic2: 10.2.91.201 > 10.251.148.199: (frag 39548:325@1480) (DF)

Klar ist, dass der Client keine endgültige Antwort vom Server kriegt.

Ich stelle gerne auch tcpdumps für erfolgreiche und fehlgeschlagene Authentifizierungen bereit, bin mir aber unsicher auf welchem Interface und mit welchen Parametern es am sinnvollsten wäre.

Jegliche Tipps, die zur Lösung meines Problems führen könnten sind sehr willkommen. Sobald mir eine Lösung bekannt ist, wird dieser Beitrag erweitert.

-- Sins

Workarounds:
1. Die Option set skip on $participating_interfaces setzen und den traffic auf anderen Interfaces filtern.
2. Den RADIUS Server in ein Netz mit dem Controller und den APs hängen.
 
Zuletzt bearbeitet:
moin,
a: flags S/SA ist default und muss nicht explizit gesetzt werden.
b: eingentlich sollte ein
Code:
pass in on vic2 proto tcp from any to 10.251.148.199 port 1812
funktionieren , jedoch macht mir die fragementierung kopf zerbrechen ,
normalerweise sollte die oben genante rule autoamtisch ein reassamble machen.

aber wer weis was diese vmware kiste macht ......

holger
 
Nutzt Freeradius nicht UDP?

Ich würde mal ein "block log all" in den pf-Rules oben reinsetzen und mir dann das tcpdump nochmal ansehen. Das was dein tcpdump bisher ausspuckt scheint ja nicht von irgendeiner Regel, sondern von der Defragmentation erzeugt worden zu sein.

mfg
morph
 
Danke für die Vorschläge! Leider hilft es nicht, den den Traffic explizit zuzulassen, wie es mark05 vorgeschlagen hat (Ich habe natürlich mit udp getestet).

Folgendes wird mit block log all angezeigt:
Code:
12:39:57.050035 rule 0/(match) block in on vic2: 10.2.91.201.32771 > 10.251.148.199.1812: Axs? id:23 [276] 44, [|radius] (DF)

Wenn ich den tarffic explizit zulasse wird nichts mehr geblockt:
Code:
nat ~ # pfctl -sr|grep 'vic[12]'
pass in on vic2 inet proto udp from 10.2.91.201 to 10.251.148.199 port = radius
pass out on vic1 inet proto udp from 10.2.91.201 to 10.251.148.199 port = radius
Code:
12:52:23.318887 rule def/(fragment) pass in on vic2: 10.2.91.201.32771 > 10.251.148.199.1812: Axs? id:86 [1702] [|radius] (frag 2150:1480@0+) (DF)
12:52:23.318916 rule def/(fragment) pass in on vic2: 10.2.91.201 > 10.251.148.199: (frag 2150:230@1480) (DF)

Folgende Optionen haben ebenfalls nicht geholfen:
set reassemble no

Wenn ich als erste Regel match in all scrub (no-df) einstelle, wird die Verbindung trotz späterer pass regeln geblockt:
Code:
13:10:11.673856 rule 1/(match) block in on vic2: 10.2.91.201.32771 > 10.251.148.198.1812: Axs? id:b6 [276] 44, [|radius] (DF)

Die einzige Möglichkeit RAIDUS Authentifizierungen zuzulassen, ohne pf ganz auszuschalten, ist set skip on { vic1 vic2 } einzustellen. Dies ermöglicht das Filtern auf dem externen Interface, verhindert aber jegliches NAT auf/zu den internen Interfaces.

-- Sins

Edit: Ich werde vorerst die RADIUS Server in das Netz vom Controller hängen, damit sie nicht über das Gateway kommunizieren müssen.
 
Zuletzt bearbeitet:
hi
a : es war nur ein bespiel was ich als regel genannt habe und nicht vollstaendig.

und so wie ich das sehe geht es bei dir um 2 port 199 und 1812

radis sollte grundsaetzlich gehen ,

worum ich mich aber zu erst einmal kuemmen wuerde sind die fragmentations.

die fw kann man dann solange mit pfctl -d abschalten.

holger
 
Gerade das wundert mich ja!

Mit set reassemble no werden fragmentierte Pakete nicht mehr zusammgengefügt. Dazu kommen Regeln, die alles mit pass zulassen.

Wenn man wenigstens Fehlermeldungen sehen würde. =/

Trotzdem vielen Dank für's Mitgrübeln.
 
Wenn dir der Output von pf nicht ausreicht, dann kann du die runtime options entsprechend anpassen.

set debug misc

Damit solltest du in der Lage sein, scrub-Meldungen und Fragmentation-Meldungen besser zu analysieren.

In der alten scrub-Doku habe ich gelesen, dass fragmentierte Pakete generell nicht durchs NAT gelassen werden. Diese müssen also vorher zusammengebaut werden. Ob das heute noch so ist, kann ich nicht sagen. Außerdem hat scrub die Pakete mit gesetztem DF-bit verworfen, es sei denn, scrub wurde mit der Option (no-df) davon abgehalten.

Ein Blick in die man-pages würde vielleicht eher helfen Licht ins Dunkel zu bringen. In der aktuellen PF-FAQ finde ich nichts zum Thema "Packet Normalization".

Über die runtime options kannst du übrigens auch den reservierten Speicher für Fragmente heraufsetzen. Vielleicht sind deine Schlüssel einfach zu lang.

mfg
morph
 
Folgendes habe ich über Normalization in der FAQ gelesen:
The scrubbing process will cause PF to drop any incoming packets with illegal TCP flag combinations (such as SYN and RST) and to normalize potentially ambiguous combinations (such as SYN and FIN).

Laut Manpage werden nur fragmentierte Pakete fallen gelassen, die das "don't fragment" Bit gesetzt haben. Dagegen gibt es die (no-df) Option.

Ich werde mir die Pakete mal genauer anschauen und den misc Loglevel testen (eher nächste, oder übernächste Woche).

-- Sins
 
Zurück
Oben