Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Mueller, Jason C]

Hugh,


> According to section 5.5 in the Radiator 4.11 reference manual 
> ("doc/ref.pdf") you need to specify both ipv6 and ipv4 like this:
> 
> 
> BindAddress  ipv6:::, 0.0.0.0

That syntax doesn't work on my system. The issue is not with the binding 
statement. I am able to receive both IPv4 and IPv6 RADIUS traffic on the 
system. As pointed out in a previous thread where I had a question about the 
bind statement, whether or not you need to include the 0.0.0.0 portion is 
dependent on the IP stack implementation on your system. On the system I am 
working on, if I add the 0.0.0.0, I will get an error.

Radiator receives the IPv4 requests just find with my binding set to "ipv6:::". 
In fact, Radiator processes the IPv4 requests using the DEFAULT client stanza, 
as I indicated.

It seems to me that this is an issue where Radiator does not match on IPv4 
client stanzas when specifying a bind of "ipv6:::", which is a legitimate 
binding statement that results in IPv4 traffic also working.

To summarize again, with my current config, IPv4 traffic works just fine, only 
the matching for IPv4 clients doesn't work. This seems like a bug in Radiator.


> Hint: Linux also has a special file to control the system wide behaviour: 
> /proc/sys/net/ipv6/bindv6only

We have separation of duties here, and I may or may not be able to convince the 
administrator of the operating system to change this file. By changing this, I 
could add the 0.0.0.0 parameter to the BindAddress statement, but as indicated 
above, it is not necessary in order to receive IPv4 traffic. That is already 
working, and the administrator of the system will likely point that out.


> Hint: In order to support IPV6 address, you must install the Perl Socket6 
> module.

This is already done, or the IPv6 client would not have worked, and it does.

Any thoughts on why Radiator doesn't match properly?

Thanks.

-Jason

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Mueller, Jason C]

Christian,

>>> According to section 5.5 in the Radiator 4.11 reference manual 
>>> ("doc/ref.pdf") you need to specify both ipv6 and ipv4 like this:
>>> 
>>> 
>>> BindAddress  ipv6:::, 0.0.0.0
>> 
>> That syntax doesn't work on my system. The issue is not with the binding 
>> statement. I am able to receive both IPv4 and IPv6 RADIUS traffic on the 
>> system. As pointed out in a previous thread where I had a question about the 
>> bind statement, whether or not you need to include the 0.0.0.0 portion is 
>> dependent on the IP stack implementation on your system. On the system I am 
>> working on, if I add the 0.0.0.0, I will get an error.
> 
> 
> sounds like you perl socket library is too old to support ipv6.

Can you explain further? IPv6 binding works just fine. IPv6 clients also work 
fine.

-Jason

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Microsoft AV (Was Re: EAP PEAP Authentication Failing)

[Johnson, Neil M]

Well we rolled back to an image of the system made the day before the
change and it started working.

AndŠ we managed to break it again uninstalling Symantec and installing
Microsoft's Anti-virus like we did before.

I agree that something is hosing the network stackŠ.

Definitely not a RADIATOR problem, but a just a cautionary note to others
running RADIATOR under windows 2008 R2 (64) to test software installs and
patches.


-Neil

-- 
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: neil-john...@uiowa.edu






On 6/25/13 1:33 PM, "a.l.m.bu...@lboro.ac.uk" 
wrote:

>Hi,
>> 
>> 
>> I have EAPTLS_MaxFragmentSize set to 1400 bytes.  The Server should have
>> the same firewall configuration as the other eight servers that are
>> working.
>> 
>> Our server support staff think its a library that got corrupted while
>> installing the Anti-Virus software and recommend that I delete and
>> re-install RADIATOR first.
>
>possible..but more likely that the server firewall settings arent
>the same or the TCP/IP stack got blatted by its removal.
>
>any chance of running it on a Linux box instead? ;-)
>
>alan

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Microsoft AV (Was Re: EAP PEAP Authentication Failing)

[Alan Buxey]

What would be interesting is whether a clean install of Windows and just the 
installation of the Microsoft SEP kills it

alan

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Microsoft AV (Was Re: EAP PEAP Authentication Failing)

[Johnson, Neil M]

Well, according to our server support folks, they performed this same procedure 
on our other 8 RADIUS servers and didn't have any issues.

They were using SCCM (Microsoft's System Center Configuration Manager) to 
automate the uninstall and re-install of the software rather than a manual 
process. I wonder if performing the actions by hand would make a difference.

Since it appears to be one box, I'm assuming there was something wrong with it 
before the upgrade and it should be wiped and reinstalled from scratch.

-Neil
--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: neil-john...@uiowa.edu


From: Alan Buxey mailto:a.l.m.bu...@lboro.ac.uk>>
Reply-To: Alan Buxey mailto:a.l.m.bu...@lboro.ac.uk>>
Date: Thursday, June 27, 2013 1:35 PM
To: Neil Johnson mailto:neil-john...@uiowa.edu>>
Cc: Heikki Vatiainen mailto:h...@open.com.au>>, 
"radiator@open.com.au" 
mailto:radiator@open.com.au>>
Subject: Re: Microsoft AV (Was Re: [RADIATOR] EAP PEAP Authentication Failing)

What would be interesting is whether a clean install of Windows and just the 
installation of the Microsoft SEP kills it

alan

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Mueller, Jason C]

For the sake of testing out whether making the BindAddress look as you 
suggested might help, I went ahead and did as you suggested. My Bind Address 
now looks like this:
BindAddress ipv6:::, 0.0.0.0

I was thinking that there just might be a chance that Radiator would need the 
"0.0.0.0" value to tell Radiator itself something that allowed it to match IPv4 
requests against the Client statements correctly. No go.

As expected (due to the IPv6 config file bindv6only value being set to 0), an 
error was sent to the Radiator log, when it tried to bind 0.0.0.0. This is 
because it was already implicitly bound to 0.0.0.0 by the ipv6::: parameter. 
However, the inability to match on IPv4 client statements persists. In the log 
below, I *do not* have a DEFAULT client set. As I indicated previously, if I 
create a DEFAULT client, then all IPv4 RADIUS dialogues are processed using the 
DEFAULT client stanza.

Here is the log:
Thu Jun 27 14:35:47 2013: DEBUG: Finished reading configuration file 
'/etc/radiator/radius.cfg'
Thu Jun 27 14:35:47 2013: DEBUG: Reading dictionary file 
'/etc/radiator/dictionary'
Thu Jun 27 14:35:47 2013: DEBUG: Creating authentication port ipv61812
Thu Jun 27 14:35:47 2013: DEBUG: Creating accounting port ipv61813
Thu Jun 27 14:35:47 2013: DEBUG: Creating authentication port 0.0.0.0:1812
Thu Jun 27 14:35:47 2013: ERR: Could not bind authentication socket: Address 
already in use
Thu Jun 27 14:35:47 2013: DEBUG: Creating accounting port 0.0.0.0:1813
Thu Jun 27 14:35:47 2013: ERR: Could not bind accounting socket: Address 
already in use
Thu Jun 27 14:35:47 2013: NOTICE: Server started: Radiator 4.11 on 
thing-1.its.uiowa.edu
Thu Jun 27 14:36:11 2013: NOTICE: Request from unknown client 128.255.100.70: 
ignored
Thu Jun 27 14:36:12 2013: NOTICE: Request from unknown client 128.255.100.70: 
ignored
Thu Jun 27 14:36:13 2013: NOTICE: Request from unknown client 128.255.100.70: 
ignored

Quick summary again, when using ipv6::: and bindv6only set to 0:
* Both IPv4 and IPv6 traffic gets to Radiator
* IPv6 works with everything I have tried
* IPv4 clients will not match on the proper client stanza, only the DEFAULT 
client stanza

Let me know if you have any more questions. I hope that helps to clarify the 
issue. I would appreciate any help in resolving it. 

Thanks.

-Jason



On Jun 27, 2013, at 8:07 AM, "Mueller, Jason C"  wrote:

> Hugh,
> 
> 
>> According to section 5.5 in the Radiator 4.11 reference manual 
>> ("doc/ref.pdf") you need to specify both ipv6 and ipv4 like this:
>> 
>> 
>> BindAddress  ipv6:::, 0.0.0.0
> 
> That syntax doesn't work on my system. The issue is not with the binding 
> statement. I am able to receive both IPv4 and IPv6 RADIUS traffic on the 
> system. As pointed out in a previous thread where I had a question about the 
> bind statement, whether or not you need to include the 0.0.0.0 portion is 
> dependent on the IP stack implementation on your system. On the system I am 
> working on, if I add the 0.0.0.0, I will get an error.
> 
> Radiator receives the IPv4 requests just find with my binding set to 
> "ipv6:::". In fact, Radiator processes the IPv4 requests using the DEFAULT 
> client stanza, as I indicated.
> 
> It seems to me that this is an issue where Radiator does not match on IPv4 
> client stanzas when specifying a bind of "ipv6:::", which is a legitimate 
> binding statement that results in IPv4 traffic also working.
> 
> To summarize again, with my current config, IPv4 traffic works just fine, 
> only the matching for IPv4 clients doesn't work. This seems like a bug in 
> Radiator.
> 
> 
>> Hint: Linux also has a special file to control the system wide behaviour: 
>> /proc/sys/net/ipv6/bindv6only
> 
> We have separation of duties here, and I may or may not be able to convince 
> the administrator of the operating system to change this file. By changing 
> this, I could add the 0.0.0.0 parameter to the BindAddress statement, but as 
> indicated above, it is not necessary in order to receive IPv4 traffic. That 
> is already working, and the administrator of the system will likely point 
> that out.
> 
> 
>> Hint: In order to support IPV6 address, you must install the Perl Socket6 
>> module.
> 
> This is already done, or the IPv6 client would not have worked, and it does.
> 
> Any thoughts on why Radiator doesn't match properly?
> 
> Thanks.
> 
> -Jason
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[A . L . M . Buxey]

Hi,

> Quick summary again, when using ipv6::: and bindv6only set to 0:
> * Both IPv4 and IPv6 traffic gets to Radiator
> * IPv6 works with everything I have tried
> * IPv4 clients will not match on the proper client stanza, only the DEFAULT 
> client stanza

I have the following:

BindAddress 0.0.0.0,IPV6:::

and on Linux systems I have to have this tweak to let the binding work 
correctly:

net.ipv6.bindv6only = 1

(in /etc/sysctl.conf)


alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Christopher Bongaarts]

On 6/27/2013 3:01 PM, Mueller, Jason C wrote:

Quick summary again, when using ipv6::: and bindv6only set to 0:
* Both IPv4 and IPv6 traffic gets to Radiator
* IPv6 works with everything I have tried
* IPv4 clients will not match on the proper client stanza, only the DEFAULT 
client stanza


Perhaps in this situation you need to use the IPv6-formatted IPv4 
addresses instead?  e.g. |:::127.0.0.1|


--
%%  Christopher A. Bongaarts   %%  c...@umn.edu  %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota%%  +1 (612) 625-1809%%

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Mueller, Jason C]

Alan,

> Hi,
> 
>> Quick summary again, when using ipv6::: and bindv6only set to 0:
>> * Both IPv4 and IPv6 traffic gets to Radiator
>> * IPv6 works with everything I have tried
>> * IPv4 clients will not match on the proper client stanza, only the DEFAULT 
>> client stanza
> 
> I have the following:
> 
> BindAddress 0.0.0.0,IPV6:::
> 
> and on Linux systems I have to have this tweak to let the binding work 
> correctly:
> 
> net.ipv6.bindv6only = 1
> 
> (in /etc/sysctl.conf)

My problem with making that change is that I don't run the system Radiator runs 
on, and there is a lot of reluctance to change the bindv6only setting to 1, 
since that is a system-wide change that effects all other processes on the box.

I am curious if you have Client definitions that include IPv4 addresses or 
ranges that work correctly in your configuration.

-Jason

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Heikki Vatiainen]

On 06/28/2013 12:01 AM, Christopher Bongaarts wrote:
> On 6/27/2013 3:01 PM, Mueller, Jason C wrote:
>> Quick summary again, when using ipv6::: and bindv6only set to 0:
>> * Both IPv4 and IPv6 traffic gets to Radiator
>> * IPv6 works with everything I have tried
>> * IPv4 clients will not match on the proper client stanza, only the DEFAULT 
>> client stanza
> 
> Perhaps in this situation you need to use the IPv6-formatted IPv4
> addresses instead?  e.g. |:::127.0.0.1|

I agree this solves it. Since the socket is an IPv6 socket, the
addresses will be IPv6 addresses too even if they were in IPv4
packets on the wire.

You can use e.g. a hook like this to do some debugging:

ClientHook sub {my $p = ${$_[0]}; \
my ($client_port, $client_addr) =
Radius::Util::unpack_sockaddr_in($p->{RecvFrom}); \
main::log($main::LOG_DEBUG, "client_addr: " .
Radius::AttrVal::pclean($client_addr)); \
}

When BindAddress is set to ipv6::: and request comes in from an IPv4
address 172.20.3.170 you'll get this in the logs:

DEBUG: client_addr:
<0><0><0><0><0><0><0><0><0><0><255><255><172><20><3><170>

When BindAddress is commented out and defaults to IPv4 0.0.0.0 you'll
get this in the logs when using the same client 172.20.3.170

DEBUG: client_addr: <172><20><3><170>

The former needs:


and the latter can be caught with




Using the config below the requests from 127.0.0.1 and 172.20.30.170 hit
different Client clauses depending on the BindAddress value being
ipv6::: or 0.0.0.0

As mentioned before, this is only the case with IPv6 wildcard binding.
If you the address is not a wildcard, the IPv4 requests will never pop
up from that listen socket.


Identifier ipv6-mapped-ipv4-172.20.3.170
Secret  mysecret
DupInterval 0



Identifier ipv4-172.20.3.170
Secret  mysecret
DupInterval 0



Identifier ipv4-loopback
Secret  mysecret
DupInterval 0



Identifier ipv6-mapped-ipv4-loopback
Secret  mysecret
DupInterval 0



Identifier default-client
Secret mysecret
DupInterval 0


# The Reply-Message will show which client clause was selected


Filename%D/users
AddToReply Reply-Message=%{Client:Identifier}





-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Alan Buxey]

Clients are defined by their IP address (apart from RADSEC clients which come 
through the RADSEC clause). The server runs other services on v4 and v6 too.

alan!
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ipv6::: bind results in no match on IPv4 client

[Antonio Querubin]

On Thu, 27 Jun 2013, Mueller, Jason C wrote:

> It seems to me that this is an issue where Radiator does not match on 
> IPv4 client stanzas when specifying a bind of "ipv6:::", which is a 
> legitimate binding statement that results in IPv4 traffic also working.
>
> To summarize again, with my current config, IPv4 traffic works just 
> fine, only the matching for IPv4 clients doesn't work. This seems like a 
> bug in Radiator.

Have you tried using the mapped syntax instead of the dotted quad syntax?


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator