VLAN via RADIUS

[rokpapez]

Moin,

| LANCOM L-54g Wireless
| Ver. 6.10.0038 / 17.05.2006
| SN. 053890600416

Im RADIUS Accept-Accept zende Ich die folgende attribute:
Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-ID = "2"

Index AID Interface Network VLAN-Id Age Phy-Signal MAC-Address User-Name .....
1 1 WLAN-1 2 2 60 67 000cf138a2ba test3@domena.si .....

Und der Client ist im richtigen VLAN aber das Traffic laüft nicht.

Ich habe http://www.lancom-forum.de/lhtopic,2097 ... pe,30.html gefunden und Ich habe VLAN2 und VLAN3 auf WLAN-1-2 gesetzt.

root@apL:/
> dir Setup/VLAN/Port-Table

Port Use-Tagging Allow-Untagged-Frames Allow-All-VLANs Port-VLAN-Id
LAN-1 Yes No Yes 0
WLAN-1 No Yes No 2
WLAN-1-2 No Yes No 3

root@apL:/
> dir Setup/VLAN/Net

Name VLAN-ID Ports
Default_VLAN 1 p2p-1-1
management 200 LAN-1
eduroam 2 LAN-1,WLAN-1,WLAN-1-2
eduroam_guest 3 LAN-1,WLAN-1,WLAN-1-2

Da muss noch etwas fehlen auf der 802.1q seite.... was mahe Ich falsch ?

P.S.: Ist es OK, das man Radius authentication im Setup/IEEE802.1x/Radius-Server anstellt und Radius accounting
im Setup/WLAN/Radius-accounting ? Wofür brauht Mann denn das Setup/WLAN/Radius-Access-Check ?

[alf29]

Moin,

Ist die VLAN-Id für den Client übernommen worden? Das
kann manin der Stationstabelle sehen.

P.S.: Ist es OK, das man Radius authentication im Setup/IEEE802.1x/Radius-Server anstellt und Radius accounting
im Setup/WLAN/Radius-accounting ? Wofür brauht Mann denn das Setup/WLAN/Radius-Access-Check ?

Das wird für die Überprüfung von MAC-Adressen über
RADIUS gebraucht. Setup/802.1x/... ist wie der Name schon
sagt nur von Bedeutung, wenn man 802.1x benutzt.

Gruß Alfred

[rokpapez]

Hallo,

[quote="alf29"]
Ist die VLAN-Id für den Client übernommen worden? Das
kann manin der Stationstabelle sehen.
[quote]

Ja. Client bekommt das richtige VLAN:
root@apL:/
> dir Status/WLAN/Station-table

Index AID Interface Network VLAN-Id Age Phy-Signal MAC-Address User-Name Identification Tx-Bytes Rx-Bytes Th
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1 WLAN-1 1 3 60 82 000cf138a2ba test1@domena.si 2264 4674 0 6


User test1 sol in die VLAN3 gehen. WLAN-1 hat aber VLAN2:

root@apL:/
> dir /Setup/VLAN/Networks

Name VLAN-ID Ports
----------------------------------------------------------------------------------------------
Default_VLAN 1 p2p-1-1
management 200 LAN-1
eduroam 2 LAN-1,WLAN-1,WLAN-1-2
eduroam_guest 3 LAN-1,WLAN-1,WLAN-1-2

root@apL:/
> dir /Setup/VLAN/Port-Table

Port Use-Tagging Allow-Untagged-Frames Allow-All-VLANs Port-VLAN-Id
---------------------------------------------------------------------------------------------
LAN-1 Yes No Yes 0
WLAN-1 No Yes No 2
P2P-1-1 No Yes Yes 1
P2P-1-2 No Yes Yes 1
P2P-1-3 No Yes Yes 1
P2P-1-4 No Yes Yes 1
P2P-1-5 No Yes Yes 1
P2P-1-6 No Yes Yes 1
WLAN-1-2 No Yes No 3
WLAN-1-3 No Yes Yes 1
WLAN-1-4 No Yes Yes 1
WLAN-1-5 No Yes Yes 1
WLAN-1-6 No Yes Yes 1
WLAN-1-7 No Yes Yes 1
WLAN-1-8 No Yes Yes 1

Ich kann mit tcpdump DHCP requests von Client auf gateway VLAN2 interface sehen. Vieleicht stimmt was mit der Port-Table nicht ?
DHCP replies gehen zuruck zum Client aber ARP funkcionirt nicht

Gateway tcpdump output (Linux, eth0.2 hat VLAN2 und IP 10.0.2.1):
16:56:22.587139 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:f1:38:a2:ba, length: 300
16:56:22.587617 IP 10.0.2.1 > 10.0.2.200: icmp 28: echo request seq 0
16:56:23.000359 IP 10.0.2.1.bootps > 10.0.2.200.bootpc: BOOTP/DHCP, Reply, length: 300
16:56:26.588014 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:f1:38:a2:ba, length: 300
16:56:26.588535 IP 10.0.2.1.bootps > 10.0.2.200.bootpc: BOOTP/DHCP, Reply, length: 300

dhcpd.log:
May 29 16:56:22 localhost dhcpd: DHCPDISCOVER from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:23 localhost dhcpd: DHCPOFFER on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:26 localhost dhcpd: DHCPDISCOVER from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:26 localhost dhcpd: DHCPOFFER on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:34 localhost dhcpd: DHCPDISCOVER from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:34 localhost dhcpd: DHCPOFFER on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:50 localhost dhcpd: DHCPDISCOVER from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:56:50 localhost dhcpd: DHCPOFFER on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:57:28 localhost dhcpd: DHCPDISCOVER from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:57:28 localhost dhcpd: DHCPOFFER on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:57:28 localhost dhcpd: DHCPREQUEST for 10.0.2.200 (10.0.2.1) from 00:0c:f1:38:a2:ba (bor) via eth0.2
May 29 16:57:28 localhost dhcpd: DHCPACK on 10.0.2.200 to 00:0c:f1:38:a2:ba (bor) via eth0.2

Wenn ich versuhe auf dem Client, 10.0.2.1 zu pingen zeigt tcpdump am Gateway (Linux) folgendes:
16:58:57.718415 arp who-has 10.0.2.1 tell 10.0.2.200
16:58:57.718452 arp reply 10.0.2.1 is-at 00:09:6b:3f:22:4b
16:59:03.086683 arp who-has 10.0.2.1 tell 10.0.2.200
16:59:03.086701 arp reply 10.0.2.1 is-at 00:09:6b:3f:22:4b

Aber "arp -a" auf dem Windows Client zeigt kein ARP entry.

[alf29]

Moin,

kannst Du bitte mal eine Bridge-Trace machen? Da müßte
man besser sehen können, zu welchem VLAN jetzt welches
Paket gehört.

Gruß Alfred

[alf29]

Hi,

ich glaube, ich ahne, was da los ist. Schreibst Du mir eine PM, für welches Gerät
Du eune Firmware brauchst und wohin ich sie schicken soll?

Gruß & Dank

Alfred

[rokpapez]

Hi,

ich glaube, ich ahne, was da los ist. Schreibst Du mir eine PM, für welches Gerät
Du eune Firmware brauchst und wohin ich sie schicken soll?

Gruß & Dank

Alfred

Hallo Alfred,

Wir haben die neu firmware getested (Ver. 6.12.0005 / 29.05.2006) und
dem Problem sehen wir nich mehr.

Das Device-VLAN-Id wird mit dem neuen firmware auch sofort übernomen.

Danke für das schnelle fix .