HI All, I'm testing freeradius server version 2.2.0. Worked fine using IPv4. When I switched to IPv6 I got the following error: Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 41189 Here is the entry from the clients.conf: client goya { ipv6addr = fe80::215:17ff:fed0:d278 # netmask = 128 secret = test shortname = test-net } Radtest command used with output: radtest -6 test test fe80::21b:78ff:fe40:1de1 0 test Sending Access-Request of id 143 to fe80::21b:78ff:fe40:1de1 port 1812 User-Name = "test" User-Password = "test" NAS-IPv6-Address = ::1 NAS-Port = 0 Message-Authenticator = 0x00000000000000000000000000000000 Tcpdump on server: [root@jackass ~]# tcpdump -i eth0 host fe80::21b:78ff:fe40:1de1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 16:40:27.693362 fe80::21b:78ff:fe40:1de1 > fe80::215:17ff:fed0:d278: icmp6: neighbor adv: tgt is fe80::21b:78ff:fe40:1de1 16:40:27.693704 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 16:40:32.692677 fe80::21b:78ff:fe40:1de1 > fe80::215:17ff:fed0:d278: icmp6: neighbor sol: who has fe80::215:17ff:fed0:d278 16:40:32.694009 fe80::215:17ff:fed0:d278 > fe80::21b:78ff:fe40:1de1: icmp6: neighbor adv: tgt is fe80::215:17ff:fed0:d278 16:40:32.697159 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 16:40:37.702304 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 Ifconfig on server: [root@jackass ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:78:40:1D:E1 inet addr:10.10.20.208 Bcast:10.10.20.255 Mask:255.255.255.0 inet6 addr: fe80::21b:78ff:fe40:1de1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11032790 errors:0 dropped:0 overruns:0 frame:0 TX packets:282990 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2421527725 (2.2 GiB) TX bytes:116875391 (111.4 MiB) Interrupt:209 Here is the related logs from radius -X: radiusd: #### Loading Clients #### client 127.0.0.1 { require_message_authenticator = no secret = "testing123" shortname = "localhost" nastype = "other" } client 10.10.0.0/16 { require_message_authenticator = no secret = "test" shortname = "test-net" } client goya { ipv6addr = fe80::215:17ff:fed0:d278 IPv6 address [fe80::215:17ff:fed0:d278] require_message_authenticator = no secret = "test" shortname = "test-net" } ... radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "acct" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "control" listen { socket = "/usr/local/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 53193 Listening on authentication address :: port 1812 Listening on accounting address :: port 1813 Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address :: port 1814 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Thanks in advance, Mike
what does this do...
client fe80::215:17ff:fed0:d278 { secret = test shortname = test-net nastype = other }
... ?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Same :( radiusd: #### Loading Clients #### client 127.0.0.1 { require_message_authenticator = no secret = "testing123" shortname = "localhost" nastype = "other" } client 10.10.0.0/16 { require_message_authenticator = no secret = "bigsecret" shortname = "test-net" } client fe80::215:17ff:fed0:d278 { require_message_authenticator = no secret = "bigsecret" shortname = "test-net" nastype = "other" } ... radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "acct" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "control" listen { socket = "/usr/local/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 54225 Listening on authentication address :: port 1812 Listening on accounting address :: port 1813 Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address :: port 1814 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests.
Hi, it's a very bad idea to use link-local addresses. You should use a global or ULA address instead. I don't *know* why this doesn't work, but it does with our global-scope addresses just fine, so I'm guessing it's the address type. Especially since link-local addresses are only valid with an interface scope. So "fe80::215:17ff:fed0:d278" simply isn't an IPv6 address. "fe80::215:17ff:fed0:d278%eth0" is the valid address. I don't know if the FreeRADIUS address parser is prepared to handle such interface-scoped addresses. There's not much use case for this. Greetings, Stefan Winter Am 23.05.13 16:11, schrieb Michael Sherman:
what does this do...
client fe80::215:17ff:fed0:d278 { secret = test shortname = test-net nastype = other }
... ?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Same :(
radiusd: #### Loading Clients #### client 127.0.0.1 { require_message_authenticator = no secret = "testing123" shortname = "localhost" nastype = "other" } client 10.10.0.0/16 { require_message_authenticator = no secret = "bigsecret" shortname = "test-net" } client fe80::215:17ff:fed0:d278 { require_message_authenticator = no secret = "bigsecret" shortname = "test-net" nastype = "other" } ... radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "acct" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "control" listen { socket = "/usr/local/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 54225 Listening on authentication address :: port 1812 Listening on accounting address :: port 1813 Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address :: port 1814 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 48848 Ready to process requests. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 05/24/2013 05:18 AM, Stefan Winter wrote:
simply isn't an IPv6 address
Very true.
"fe80::215:17ff:fed0:d278%eth0"
is the valid address. I don't know if the FreeRADIUS address parser is prepared to handle such interface-scoped addresses. There's not much use case for this.
Not sure I could agree with that; I can think of a bunch of use-cases for LL. In particular, a nice property of LL is that you know the request definitely came from the same link, which could be useful in some proxying scenarios e.g. 2-level ORPS hierarchy. But you're right that in general, using a global address makes more sense.
Stefan Winter wrote:
I don't *know* why this doesn't work, but it does with our global-scope addresses just fine, so I'm guessing it's the address type.
Especially since link-local addresses are only valid with an interface scope.
Exactly.
is the valid address. I don't know if the FreeRADIUS address parser is prepared to handle such interface-scoped addresses. There's not much use case for this.
FreeRADIUS calls getaddrinfo, which *should* parse link-local addresses. I guess... Alan DeKok.
Using global IPV6 addresses worked. Thanks for the help. Mike
-----Original Message----- From: freeradius-users- bounces+michael.sherman=exfo.com@lists.freeradius.org [mailto:freeradius-users- bounces+michael.sherman=exfo.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 24, 2013 9:57 AM To: FreeRadius users mailing list Subject: Re: Failure authenticate using IPv6
Stefan Winter wrote:
I don't *know* why this doesn't work, but it does with our global- scope addresses just fine, so I'm guessing it's the address type.
Especially since link-local addresses are only valid with an interface scope.
Exactly.
is the valid address. I don't know if the FreeRADIUS address parser is prepared to handle such interface-scoped addresses. There's not much use case for this.
FreeRADIUS calls getaddrinfo, which *should* parse link-local addresses. I guess...
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Michael Sherman -
Phil Mayers -
Stefan Winter