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:
Ich habe es auch mit den "pass" Parametern "no state" und "flags all" probiert - keine Änderung.
FreeRADIUS Log für eine erfolgreiche Authentifizierung:
FreeRADIUS Log für eine fehlgeschlagene Authentifizierung:
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:
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.
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
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.
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: