Re: [PacketFence-users] [Packetfence] AD authentication with FreeRadius: "reading winbind reply failed!"

[E.P. via PacketFence-users]

Hi Jimmy and Fabrice,

I would like to report the same experience. I have a realm
(OPTIONS-AD-REALM) and it is associated with the AD domain (optionsad), i.e.


 

[OPTIONS-AD-REALM]

domain=optionsad

options=strip

 

I had similar problems with winbind, same errors in the output of RADIUS
debug. Moreover, my attempt to test authentication from the command line was
successful:

 

[root@PacketFence-ZEN bin]# ./pftest authentication it.tech X

 

Authenticating against OPTIONS-AD-SOURCE

  Authentication SUCCEEDED against OPTIONS-AD-SOURCE (Authentication
successful.) 

  Matched against OPTIONS-AD-SOURCE for 'authentication' rules

set_role : Staff

set_unreg_date : 2019-12-31

 

Go figure what’s wrong, permissions, bugs or a lack of understanding from my
side as what I see as the result of ntlm_auth query drives me mad:

 

[root@PacketFence-ZEN bin]# ntlm_auth --request-nt-key --domain=optionsad
--username=it.tech

Password: 

could not obtain winbind separator!

Reading winbind reply failed! (0x01)

:  (0x0)

 

So, here I would like Fabrice comment on this, specifically bearing in mind
that it all works if I use only the default realm and link it to the AD
domain.

What’s the point of having named realms ?

Moreover, if I test my authentication source with the authentication realm
pointing to default the test fails. If I remove it then the test goes
through ?

What’s the point of having the realm here, Fabrice ?

Moreover, if I use FQDN for the host that acts as the windows domain
controller my test also fails but if I use the IP address it is all good. 

I know and I swear that PF can resolve the name normally.

There are more questions that I’d like to ask strongly believing there’s
faulty code or missing documentation or a combination of both.

 

Eugene

 

From: Durand fabrice via PacketFence-users
[mailto:packetfence-users@lists.sourceforge.net] 


Sent: Tuesday, March 06, 2018 6:26 PM
To: packetfence-users@lists.sourceforge.net
Cc: Durand fabrice 
Subject: Re: [PacketFence-users] [Packetfence] AD authentication with
FreeRadius: "reading winbind reply failed!"

 

Hello Jimmy,

create the realms associated to your domain, like you have a user like
ACME\bob and b...@acme.com   then create the 2 realms
and associate them to your AD.

Regards

Fabrice

 

 

Le 2018-03-06 à 07:14, Jimmy Claes via PacketFence-users a écrit :

I’ve been trying to figure out this problem for days, whenever I try to
authenticate a user on Windows, I get the following error while the login is
correct:



 

‘wbinfo –p’ fails aswell:



 

Winbind service is running:



 

Freeradius service is running:



 

The permissions on winbindd_privileged are properly set:



 

Result of running ‘freeradius –X’ attached.

 







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot






___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
 
https://lists.sourceforge.net/lists/listinfo/packetfence-users

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] Hostapd causing duplicate Sign-Into-Network prompts intermittently

[Durand fabrice via PacketFence-users]

Hello Ian,

there is a configuration parameter that can be change to raise the time 
between the deauth order and the CoA request.


It's Config{'fencing'}{'wait_for_redirect'} , so in pf.conf:

[fencing]
#
# fencing.wait_for_redirect
#
# How many seconds should the WebAPI sleep before actually triggering 
the VLAN change.
# This is meant to give the device enough time to fetch the redirection 
page before

# switching VLAN.
wait_for_redirect = 31

Regards

Fabrice



Le 2018-03-06 à 13:54, Ian MacDonald via PacketFence-users a écrit :

Well,

We easily narrowed this down to a timing issue related to the 
Access-Accept(2) messages and how long an authorization is considered 
valid by hostapd.


In short, we need to make sure that the CoA from portal activation is 
NOT sent to the AP within 30 seconds of the initial connection to the 
registration VLAN.


We don't think the redirect or network_detection delay is suitable for 
this as that happens after the CoA.


*How do we bake in a delay between Access-Accept and CoA messages from 
the radius server for speedy WISPr clients? *

*
*
Is there a portal setting that can help us here?

Ideally, a "minimum_coa_delay" setting could allow packetfence to only 
issue a CoA after a minimum time period since the last Access-Request 
or Access-Accept was processed.


Additionally, we are going to investigate configuration of hostapd to 
change the 30s to something smaller (which would solve most our use 
cases) and/or, having the 30s timer reset on receipt of a CoA.  Both 
these seem non-trivial vs adding this intelligence to packetfence 
which may solve similar race conditions in the wide variety of radius 
clients supported.


Details follow,

cheers,
Ian


Hostapd considers the last authorization valid for 30 seconds, and if 
a host disconnects and reconnects within that window, it does not 
check back with the radius server for a new authorization.   This 
holds true even if a CoA is received from the radius server;  The 
latter which I think is a behavior that could be enhanced by hostapd - 
after all it is called "Change of Authorization" request.


How this is resulting the double prompt for some users, is that if a 
user is able to complete the portal activation within 30 seconds of 
the device connecting to the registration VLAN, hostapd does not issue 
another Access-Request, but instead considers the current 
authorization to be valid, and the devices remain on the registration 
VLAN evem after the CoA is sent  that should switch them to the Normal 
VLAN.


This means you can actually re-Sign-In multiple times within that 30 
second window if you are quick (my email auto-populates on my phone 
making this easy). Each time the portal generates a CoA but returns 
the device to the registration VLAN.  At 31 seconds after the initial 
device connnection to the registration VLAN, any subsequent CoA 
results in the correct VLAN being assigned.


The 30s authorization sort of makes sense in order to deal with a 
client that is authorized and disconnects and reconnects quickly a 
bunch of times, you avoid some unnecessary radius requests back and 
forth, but the benefit is minimized since the Radius-Accounting 
packets are still processed with each disconnect.


This 30 second delay also impacts de-registration.  We were able to 
confirm that if we try and de-register a client from the PF GUI within 
30 seconds of them being activated, they remain on the Normal VLAN.  
 So there is some impact here as well -> And we remember seeing this 
little bug a long time ago, so we think this has always been there.  
Often testing the captive portals we de-register devices quickly to 
"try them again" and we used to have to hit "re-evaluate" after save 
.. but it turns out, only if we do it under 30 seconds.





On Mon, Mar 5, 2018 at 9:21 PM, Ian MacDonald > wrote:


We have packetfence 7.4 instances out-of-band running on Debian 8,
and use the captive portal with hostapd for WiFi client access.

Our clients register using an email source for activation.

Our configuration uses all captive_portal defaults except for the
network detection IP, shown below.

network_detection_initial_delay = 5s
network_detection_retry_delay = 2s
network_redirect_delay = 20s
secure_redirect=enabled
detection_mecanism_bypass = disabled
wispr_redirection = enabled

At some point in the past I recall our mobile clients used to see
the scrollbar for many seconds (10+?), which I believe was
redirect_delay being interrupted by network_detection; this would
occur immediately after submitting an email for activation.

Now on PF 7.4.0, hostapd 17.01.4 and with Samsung S8 clients, the
delay between submitting the email and activation onto the
user/normal VLAN is instantaneous (about 2 seconds according to
our logs).   I suspect this speedy interaction has something to do
with 

Re: [PacketFence-users] CoA on EX2200

[Durand fabrice via PacketFence-users]

Hello Sergio,


Le 2018-03-06 à 11:54, Sergio Rizzi via PacketFence-users a écrit :

Hi,
 i'm using PF 7.3.0 with active cluster and i have some trouble using 
CoA deauth.


These are the code changes to make it works (sorry for a non 
patch-like code):




lib/pf/accounting.pm: on clusters, cache seems not to work

[...]
+use pf::cluster;
[...]
sub node_accounting_current_sessionid {
    my ($mac) = @_;
    if(my $entry = pf::accounting->cache->get($mac)){
    +if (!$cluster_enabled){
   return $entry->{'Acct-Session-Id'};
    +}

Do a : bin/pfcmd cache accounting dump @mac
to see if the cache is correct for the mac address.

    }
    my $query = db_query_execute(ACCOUNTING, $accounting_statements, 
'acct_current_sessionid_sql', $mac) || return (0);

    my ($val) = $query->fetchrow_array();
    $query->finish();
    return ($val);
}
[...]




lib/pf/Switch/Juniper/EX2200.pm: Juniper (and RFC) wants mac addresses 
delimited by "-", not by ":"


[...]
    my $acctsessionid = node_accounting_current_sessionid($mac);

    +my $sburomac = $mac;
    +$sburomac =~ tr/:/-/;

$mac =~ tr/:/-/; is enough.
btw if you can do a Pull request on github it will be really appreciated.


    +$logger->warn("Using mac $sburomac to perform 
Disconnect-Request for Acct-Session-Id $acctsessionid to 
NAS-IP-Address $send_disconnect_to");


    # Standard Attributes
    my $attributes_ref = {
    -'Calling-Station-Id' => $mac,
    +'Calling-Station-Id' => $sburomac,
    'Acct-Session-Id' => $acctsessionid,
    'NAS-IP-Address' => $send_disconnect_to,
    };
[...]



Sergio.



Regards
Fabrice


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] Unknown Switch - Rejected User

[Durand fabrice via PacketFence-users]

Hello Ebrar,

This should work:

[192.168.56.100]
description=IOUvL2
type=Cisco::Catalyst_2960
radiusSecret=useStrongerSecret
deauthMethod=RADIUS

Regards

Fabrice




Le 2018-03-06 à 08:49, ebrar via PacketFence-users a écrit :


Hi All,

I have set up PF on a virtual machine whose OS is Centos and i have 
set up a switch on GNS3 by using the image below :


i86bi-linux-l2-adventerprisek9-15.1a

This SW lets me do all the configurations mentioned on PacketFence 
Out-of-Band Deployment Quick Guide. You can see the related 
configurations on the SW below :


username ebrar privilege 0 password 0 eleb
aaa new-model
!
!
aaa group server radius packetfence
 server name pfnac
!
aaa authentication login default local
aaa authentication dot1x default group packetfence
aaa authorization network default group packetfence
!
!
!
!
aaa server radius dynamic-author
 client 192.168.56.101 server-key useStrongerSecret
 port 3799
!
aaa session-id common
no ip icmp rate-limit unreachable
!
ip cef
!
!
no ip domain-lookup
no ipv6 cef
ipv6 multicast rpf use-bgp
!
!
dot1x system-auth-control

interface Ethernet0/0
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 2,3,10
 switchport mode trunk
 duplex auto
!
interface Ethernet0/1
 switchport access vlan 10
 switchport mode access
 duplex auto
 authentication order mab dot1x
 authentication priority mab dot1x
 authentication port-control auto
 authentication periodic
 authentication timer restart 10800
 authentication timer reauthenticate 10800
 authentication violation replace
 mab
 no snmp trap link-status
 dot1x pae authenticator
 dot1x timeout quiet-period 2
 dot1x timeout tx-period 3
!
interface Ethernet0/2
 switchport access vlan 20
 switchport mode access
 duplex auto

snmp-server community public RO
snmp-server community private RW
snmp-server host 192.168.56.101 version 2c public
!
radius-server vsa send authentication
!
radius server pfnac
 address ipv4 192.168.56.101 auth-port 1812 acct-port 1813
 automate-tester username ebrar ignore-acct-port idle-time 3
 key useStrongerSecret

When I connect a client to Ethernet 0/1 and try to connect to internet 
(www.google.com) It responds "Page Not Found" and nothing is being 
changed on the SW.


You can see the errors in the log files below :

packetfence.log :

[root@localhost logs]#  tail -f packetfence.log
Mar  6 19:26:03 localhost packetfence_httpd.aaa: httpd.aaa(2123) 
ERROR: [mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:26:03 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:29:02 localhost packetfence_httpd.aaa: httpd.aaa(2123) 
ERROR: [mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:29:02 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:31:51 localhost packetfence_httpd.aaa: httpd.aaa(2123) 
ERROR: [mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:31:51 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:34:49 localhost packetfence_httpd.aaa: httpd.aaa(2123) 
ERROR: [mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:34:49 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:37:37 localhost packetfence_httpd.aaa: httpd.aaa(2123) 
ERROR: [mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:37:37 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)


radius.log :

Mar  6 19:37:37 localhost auth[2284]: (552) rest: ERROR: 
{"control:PacketFence-Authorization-Status":"allow","Reply-Message":"Switch 
is not managed by PacketFence"}
Mar  6 19:37:37 localhost auth[2284]: Need 2 more connections to reach 
min connections (3)
Mar  6 19:37:37 localhost auth[2284]: rlm_rest (rest): Opening 
additional connection (1099), 1 of 63 pending slots used
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Closing 
connection (1097): Hit idle_timeout, was idle for 168 seconds
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Closing 
connection (1098): Hit idle_timeout, was idle for 168 seconds
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Opening 
additional connection (1099), 1 of 64 pending slots used
Mar  6 19:37:37 localhost auth[2284]: Need 2 more connections to reach 
min connections (3)
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Opening 
additional 

Re: [PacketFence-users] So is support for Meru dead now on 7.4 ?

[Arthur Emerson via PacketFence-users]

Considering that Meru as a company is 404 and the brain-drain following
the Fortinet acquisition essentially put the whole product line into
life support mode in terms of customer support, I would not hold my
breath waiting for someone to fix any Meru problems in PF.

We are running PF 5.x with two Meru controllers and 600+ AP's.  The
de-associate thing has been a pain point for quite some time.  Unless
I'm going crazy, ancient versions of PF used to even write log entries
for every de-associate asking users to pressure Meru to add the proper
de-associate support instead of requiring the ssh/telnet kludge.  They
supposedly did add the procedure, but I don't know if PF's Meru code
was ever updated to use it.

Long story short, our de-associate seems to be hit-or-miss with PF 5.x.
I think that we had set some sort of station timeout in the Meru
controllers, which causes them to re-query PF every few minutes to
decide if they should still be connected and to what VLAN.  Tradeoff
PF server load for more frequent queries versus user inconvenience having
to wait longer for a de-associate/re-associate after registration.

One piece of debugging advice that I will offer is to make sure that
you run ssh once AS THE USER RUNNING THE PF SERVICE to automatically
add the controller's certificate into the ssh config as a known host.
I don't know if PF is calling out to ssh or using some perl function
to do the connection, but have seen that pesky certificate prompt
break plenty of automation routines that use ssh over the years.

So, as is the case with anything in the open-source community or with
volunteer organizations, I suspect that the only way this will ever get
fixed is if someone who hasn't moved away from Meru/Fortinet takes the
lead and figures out what is needed to do the native de-associate without
ssh/telnet.  Everyone that I knew from Meru moved on a long time ago,
so I have no resources to tap outside of the same Fortinet support
department that everyone else has available...

-Arthur

-
Arthur Emerson III Email:  
emer...@msmc.edu
Network Administrator  InterNIC:   AE81
Mount Saint Mary College   MaBell: (845) 561-0800 Ext. 3109
330 Powell Ave.Fax:(845) 562-6762
Newburgh, NY  12550SneakerNet: Aquinas Hall Room 008-A


From: Derek Brabrook via PacketFence-users 

Reply: packetfence-users@lists.sourceforge.net 

Date: March 6, 2018 at 12:20:42 PM
To: packetfence-users 

Cc: Derek Brabrook 

Subject:  [PacketFence-users] So is support for Meru dead now on 7.4 ?

seeing as packetfence won't connect to the meru controller either via telnet or 
ssh to de-associate
macs ?

(see previous posts on this issue Meru 3200)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] Hostapd causing duplicate Sign-Into-Network prompts intermittently

[Ian MacDonald via PacketFence-users]

Well,

We easily narrowed this down to a timing issue related to the
Access-Accept(2) messages and how long an authorization is considered valid
by hostapd.

In short, we need to make sure that the CoA from portal activation is NOT
sent to the AP within 30 seconds of the initial connection to the
registration VLAN.

We don't think the redirect or network_detection delay is suitable for this
as that happens after the CoA.

*How do we bake in a delay between Access-Accept and CoA messages from the
radius server for speedy WISPr clients? *

Is there a portal setting that can help us here?

Ideally, a "minimum_coa_delay" setting could allow packetfence to only
issue a CoA after a minimum time period since the last Access-Request or
Access-Accept was processed.

Additionally, we are going to investigate configuration of hostapd to
change the 30s to something smaller (which would solve most our use cases)
and/or, having the 30s timer reset on receipt of a CoA.  Both these seem
non-trivial vs adding this intelligence to packetfence which may solve
similar race conditions in the wide variety of radius clients supported.

Details follow,

cheers,
Ian


Hostapd considers the last authorization valid for 30 seconds, and if a
host disconnects and reconnects within that window, it does not check back
with the radius server for a new authorization.   This holds true even if a
CoA is received from the radius server;  The latter which I think is a
behavior that could be enhanced by hostapd - after all it is called "Change
of Authorization" request.

How this is resulting the double prompt for some users, is that if a user
is able to complete the portal activation within 30 seconds of the device
connecting to the registration VLAN, hostapd does not issue another
Access-Request, but instead considers the current authorization to be
valid, and the devices remain on the registration VLAN evem after the CoA
is sent  that should switch them to the Normal VLAN.

This means you can actually re-Sign-In multiple times within that 30 second
window if you are quick (my email auto-populates on my phone making this
easy). Each time the portal generates a CoA but returns the device to the
registration VLAN.  At 31 seconds after the initial device connnection to
the registration VLAN, any subsequent CoA results in the correct VLAN being
assigned.

The 30s authorization sort of makes sense in order to deal with a client
that is authorized and disconnects and reconnects quickly a bunch of times,
you avoid some unnecessary radius requests back and forth, but the benefit
is minimized since the Radius-Accounting packets are still processed with
each disconnect.

This 30 second delay also impacts de-registration.  We were able to confirm
that if we try and de-register a client from the PF GUI within 30 seconds
of them being activated, they remain on the Normal VLAN.   So there is some
impact here as well -> And we remember seeing this little bug a long time
ago, so we think this has always been there.  Often testing the captive
portals we de-register devices quickly to "try them again" and we used to
have to hit "re-evaluate" after save .. but it turns out, only if we do it
under 30 seconds.




On Mon, Mar 5, 2018 at 9:21 PM, Ian MacDonald  wrote:

> We have packetfence 7.4 instances out-of-band running on Debian 8, and use
> the captive portal with hostapd for WiFi client access.
>
> Our clients register using an email source for activation.
>
> Our configuration uses all captive_portal defaults except for the network
> detection IP, shown below.
>
> network_detection_initial_delay = 5s
> network_detection_retry_delay = 2s
> network_redirect_delay = 20s
> secure_redirect=enabled
> detection_mecanism_bypass = disabled
> wispr_redirection = enabled
>
> At some point in the past I recall our mobile clients used to see the
> scrollbar for many seconds (10+?), which I believe was redirect_delay being
> interrupted by network_detection; this would occur immediately after
> submitting an email for activation.
>
> Now on PF 7.4.0, hostapd 17.01.4 and with Samsung S8 clients, the delay
> between submitting the email and activation onto the user/normal VLAN is
> instantaneous (about 2 seconds according to our logs).   I suspect this
> speedy interaction has something to do with WiSPr and CoA working together
> quickly, whereas previously we were maybe only doing captive portal.
>
> The problem is that intermittently, the Android clients, after activation,
> are returned to the Registration VLAN instead of the Normal/User VLAN,
> which causes those clients to pop up the "Sign Into Network" WiSPR prompt a
> second time.  Clicking on it again loads a quick PF Network Error page
> which disappears as quickly as it appears, and a second later the client is
> dumped onto the Normal/User VLAN as it should have been originally.
>
> This is confusing for end users, and most make it through. But not
> everyone is happy.
>
> Below is the 

[PacketFence-users] CoA on EX2200

[Sergio Rizzi via PacketFence-users]

Hi,
 i'm using PF 7.3.0 with active cluster and i have some trouble using 
CoA deauth.


These are the code changes to make it works (sorry for a non patch-like 
code):




lib/pf/accounting.pm: on clusters, cache seems not to work

[...]
+use pf::cluster;
[...]
sub node_accounting_current_sessionid {
my ($mac) = @_;
if(my $entry = pf::accounting->cache->get($mac)){
+if (!$cluster_enabled){
   return $entry->{'Acct-Session-Id'};
+}
}
my $query = db_query_execute(ACCOUNTING, $accounting_statements, 
'acct_current_sessionid_sql', $mac) || return (0);

my ($val) = $query->fetchrow_array();
$query->finish();
return ($val);
}
[...]




lib/pf/Switch/Juniper/EX2200.pm: Juniper (and RFC) wants mac addresses 
delimited by "-", not by ":"


[...]
my $acctsessionid = node_accounting_current_sessionid($mac);

+my $sburomac = $mac;
+$sburomac =~ tr/:/-/;
+$logger->warn("Using mac $sburomac to perform 
Disconnect-Request for Acct-Session-Id $acctsessionid to NAS-IP-Address 
$send_disconnect_to");


# Standard Attributes
my $attributes_ref = {
-'Calling-Station-Id' => $mac,
+'Calling-Station-Id' => $sburomac,
'Acct-Session-Id' => $acctsessionid,
'NAS-IP-Address' => $send_disconnect_to,
};
[...]



Sergio.


--
Sergio Rizzi
Network Management and Security
Senior Account

Laboratori Guglielmo Marconi
Via Porrettana 123
40037 Pontecchio Marconi (BO) - Italy
Phone +39 051 6781944
Mobile +39 349 8073882

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

[PacketFence-users] So is support for Meru dead now on 7.4 ?

[Derek Brabrook via PacketFence-users]

seeing as packetfence won't connect to the meru controller either via telnet or 
ssh to de-associate 
macs ? 

(see previous posts on this issue Meru 3200) 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] Access to PF captive portal is blocked

[Ian MacDonald via PacketFence-users]

Eugene,

I think a good old fashioned network diagram could be of help here.  I am
not sure which linux flavour your running, but I can see one problem that
might be confusing your forwarding/arp/iptables.

You have two IP addresses on the same subnet configured both on the raw
device (eth0) and a tagged trunk interface (eth0.1).  I don't think your
intent was to have packets on one of these interfaces coming and going on
the raw interface without tags (eth0) and the other being tagged (eth0.1),
especially if the interfaces are on the same subnet.  It just so happens
the default PVID on eth0 would be 1, making this sort of setup a bit more
confusing and maybe possibly sorta work strangely.

An alias for eth0 would be eth0:1 (note the ":" instead of ".").  This is
what you would use to put multiple IPs on the same subnet. i.e. eth0:1,
eth0:2 and eth0:3 are all on the same vlan, the native vlan for eth0.

eth0.1 is a trunked interface for VLAN1 on eth0.   If you had an 802.11q
trunk connected to your eth0 with tagged VLANS 10,11 and 12 they could have
interfaces on eth0.10, eth0.11 and eth0.12 respectively.  And if you wanted
multiple IPs on each subnet, you could have aliases even still, like
eth0.10:1 and eth0.10:2 on the VLAN10 subnet for example.

I only have experience with out-of-band setups with separate subnets for
management, registration and isolation.   My minds eye doesn't quite
understand your goals for the configuration for two interfaces on the same
subnet with an out-of-band wifi authenticating via captive portal.
Describing the packet flow /subnets for your client before authorization
and afterwards might help with some of the next steps once you nail down
the network topology.

cheers,
Ian

On Mon, Feb 19, 2018 at 3:29 AM, E.P. via PacketFence-users <
packetfence-users@lists.sourceforge.net> wrote:

> And my further attempts to put two and two together and look back in time
> into this mailing list showed that Fabrice already answered this question
> before 
>
> Yes, I’d create an alias, e.g. eth0.1
>
> So, under Configuration-Networks-Interfaces I click  “ADD VLAN”  and then
> add VLAN 1, add a new IP address to belong to the same subnet and then
> select type “portal”
>
> New interface eth0.1 gets created with IP address 172.16.0.223, I can
> reach it via IP and my interfaces and networks look like this:
>
>
>
>
>
> What else am I doing to enable captive portal? I thought that it is
> enabled by default and I see httpd.portal is UP and running but I don’t see
> anything ports open on 172.16.0.223
>
> And iptables allow all HTTP and HTTPS for input-portal-if chain
>
>
>
> Eugene
>
>
>
>
>
> *From:* E.P. [mailto:ype...@gmail.com]
> *Sent:* Sunday, February 18, 2018 11:14 PM
> *To:* 'packetfence-users@lists.sourceforge.net'  sourceforge.net>
> *Cc:* 'Durand fabrice' 
> *Subject:* RE: [PacketFence-users] Access to PF captive portal is blocked
>
>
>
> I think it is slowly coming to me, Fabrice.
>
> My PF is pure for RADIUS enforcement and PF has only one IP address of
> management type.
>
> Now if I want WebAuth enforcement I would need to create one more
> interface of portal type
>
> The question is can I create this portal type interface in the same subnet
> as the management interface ?
>
> I would want to have them both in the same VLAN
>
>
>
> Eugene
>
>
>
> *From:* E.P. [mailto:ype...@gmail.com ]
> *Sent:* Sunday, February 18, 2018 7:20 PM
> *To:* 'packetfence-users@lists.sourceforge.net'  sourceforge.net>
> *Cc:* 'Durand fabrice' 
> *Subject:* RE: [PacketFence-users] Access to PF captive portal is blocked
>
>
>
> Here it is, Fabrice
>
> 10.0.254.3 is the WiFi client and 172.16.0.222 is PF.
>
> Tcpdump.pcap is attached and it is made right on PF
>
> The second capture is made on the laptop connected to guest WiFi.
>
> It contains pings to PF but all TCP SYN requests all are answered with RST.
>
>
>
> Eugene
>
>
>
> *From:* Durand fabrice via PacketFence-users [mailto:packetfence-users@
> lists.sourceforge.net ]
> *Sent:* Sunday, February 18, 2018 10:51 AM
> *To:* packetfence-users@lists.sourceforge.net
> *Cc:* Durand fabrice 
> *Subject:* Re: [PacketFence-users] Access to PF captive portal is blocked
>
>
>
> Hello Eugene,
>
> do you have the capture ?
>
> Regards
> Fabrice
>
> Le 2018-02-15 à 23:12, E.P. via PacketFence-users a écrit :
>
> Hi Fabrice,
>
> I dare sending it again believing my previous email fell into cracks.
>
> Can you please advise what could be wrong (see below)
>
>
>
> Eugene
>
>
>
>
>
> *From:* E.P. [mailto:ype...@gmail.com ]
> *Sent:* Wednesday, February 14, 2018 1:08 AM
> *To:* packetfence-users@lists.sourceforge.net
> *Subject:* Access to PF captive portal is blocked
>
>
>
> Hello folks,
>
> I really hope someone who ran into a similar problem will shed some light.
>
> 

[PacketFence-users] [Packetfence] AD authentication with FreeRadius: "reading winbind reply failed!"

[Jimmy Claes via PacketFence-users]

I've been trying to figure out this problem for days, whenever I try to 
authenticate a user on Windows, I get the following error while the login is 
correct:
[cid:image001.png@01D3B54D.1667FFA0]

'wbinfo -p' fails aswell:
[cid:image002.png@01D3B54D.1667FFA0]

Winbind service is running:
[cid:image003.png@01D3B54D.1667FFA0]

Freeradius service is running:
[cid:image004.png@01D3B54D.1667FFA0]

The permissions on winbindd_privileged are properly set:
[cid:image005.png@01D3B54D.1667FFA0]

Result of running 'freeradius -X' attached.



freeradius_debug.log
Description: freeradius_debug.log
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

[PacketFence-users] Unknown Switch - Rejected User

[ebrar via PacketFence-users]

Hi All,

I have set up PF on a virtual machine whose OS is Centos and i have set 
up a switch on GNS3 by using the image below :


i86bi-linux-l2-adventerprisek9-15.1a

This SW lets me do all the configurations mentioned on PacketFence 
Out-of-Band Deployment Quick Guide. You can see the related 
configurations on the SW below :


username ebrar privilege 0 password 0 eleb
aaa new-model
!
!
aaa group server radius packetfence
 server name pfnac
!
aaa authentication login default local
aaa authentication dot1x default group packetfence
aaa authorization network default group packetfence
!
!
!
!
aaa server radius dynamic-author
 client 192.168.56.101 server-key useStrongerSecret
 port 3799
!
aaa session-id common
no ip icmp rate-limit unreachable
!
ip cef
!
!
no ip domain-lookup
no ipv6 cef
ipv6 multicast rpf use-bgp
!
!
dot1x system-auth-control

interface Ethernet0/0
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 2,3,10
 switchport mode trunk
 duplex auto
!
interface Ethernet0/1
 switchport access vlan 10
 switchport mode access
 duplex auto
 authentication order mab dot1x
 authentication priority mab dot1x
 authentication port-control auto
 authentication periodic
 authentication timer restart 10800
 authentication timer reauthenticate 10800
 authentication violation replace
 mab
 no snmp trap link-status
 dot1x pae authenticator
 dot1x timeout quiet-period 2
 dot1x timeout tx-period 3
!
interface Ethernet0/2
 switchport access vlan 20
 switchport mode access
 duplex auto

snmp-server community public RO
snmp-server community private RW
snmp-server host 192.168.56.101 version 2c public
!
radius-server vsa send authentication
!
radius server pfnac
 address ipv4 192.168.56.101 auth-port 1812 acct-port 1813
 automate-tester username ebrar ignore-acct-port idle-time 3
 key useStrongerSecret

When I connect a client to Ethernet 0/1 and try to connect to internet 
(www.google.com) It responds "Page Not Found" and nothing is being 
changed on the SW.


You can see the errors in the log files below :

packetfence.log :

[root@localhost logs]#  tail -f packetfence.log
Mar  6 19:26:03 localhost packetfence_httpd.aaa: httpd.aaa(2123) ERROR: 
[mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:26:03 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:29:02 localhost packetfence_httpd.aaa: httpd.aaa(2123) ERROR: 
[mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:29:02 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:31:51 localhost packetfence_httpd.aaa: httpd.aaa(2123) ERROR: 
[mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:31:51 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:34:49 localhost packetfence_httpd.aaa: httpd.aaa(2123) ERROR: 
[mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:34:49 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)
Mar  6 19:37:37 localhost packetfence_httpd.aaa: httpd.aaa(2123) ERROR: 
[mac:[undef]] WARNING ! Unknown switch(es) 192.168.56.100 
(pf::SwitchFactory::instantiate)
Mar  6 19:37:37 localhost packetfence_httpd.aaa: httpd.aaa(2123) WARN: 
[mac:[undef]] Unknown switch (192.168.56.100). This request will be 
failed. (pf::radius::switch_access)


radius.log :

Mar  6 19:37:37 localhost auth[2284]: (552) rest: ERROR: 
{"control:PacketFence-Authorization-Status":"allow","Reply-Message":"Switch 
is not managed by PacketFence"}
Mar  6 19:37:37 localhost auth[2284]: Need 2 more connections to reach 
min connections (3)
Mar  6 19:37:37 localhost auth[2284]: rlm_rest (rest): Opening 
additional connection (1099), 1 of 63 pending slots used
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Closing connection 
(1097): Hit idle_timeout, was idle for 168 seconds
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Closing connection 
(1098): Hit idle_timeout, was idle for 168 seconds
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Opening additional 
connection (1099), 1 of 64 pending slots used
Mar  6 19:37:37 localhost auth[2284]: Need 2 more connections to reach 
min connections (3)
Mar  6 19:37:37 localhost auth[2284]: rlm_sql (sql): Opening additional 
connection (1100), 1 of 63 pending slots used

Mar  6 19:37:37 localhost auth[2284]: [mac:] Rejected user: ebrar
Mar  6 19:37:37 localhost auth[2284]: (552) Rejected in post-auth: 
[ebrar] (from client 192.168.56.100/32 port 0)


And 

[PacketFence-users] Hostapd causing duplicate Sign-Into-Network prompts intermittently

[Ian MacDonald via PacketFence-users]

We have packetfence 7.4 instances out-of-band running on Debian 8, and use
the captive portal with hostapd for WiFi client access.

Our clients register using an email source for activation.

Our configuration uses all captive_portal defaults except for the network
detection IP, shown below.

network_detection_initial_delay = 5s
network_detection_retry_delay = 2s
network_redirect_delay = 20s
secure_redirect=enabled
detection_mecanism_bypass = disabled
wispr_redirection = enabled

At some point in the past I recall our mobile clients used to see the
scrollbar for many seconds (10+?), which I believe was redirect_delay being
interrupted by network_detection; this would occur immediately after
submitting an email for activation.

Now on PF 7.4.0, hostapd 17.01.4 and with Samsung S8 clients, the delay
between submitting the email and activation onto the user/normal VLAN is
instantaneous (about 2 seconds according to our logs).   I suspect this
speedy interaction has something to do with WiSPr and CoA working together
quickly, whereas previously we were maybe only doing captive portal.

The problem is that intermittently, the Android clients, after activation,
are returned to the Registration VLAN instead of the Normal/User VLAN,
which causes those clients to pop up the "Sign Into Network" WiSPR prompt a
second time.  Clicking on it again loads a quick PF Network Error page
which disappears as quickly as it appears, and a second later the client is
dumped onto the Normal/User VLAN as it should have been originally.

This is confusing for end users, and most make it through. But not everyone
is happy.

Below is the working scenario, as seen in terms of tcpdump of radius
packets on hostapd.

PF server is 10.2.1.2 and the hostapd daemon is 10.2.1.11

Client Connects to WiFi Network and Prestented with Email Activation in
Portal
12:03:58.157726 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
12:03:58.211386 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
12:03:58.279846 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:03:58.325525 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
~30s later Client hits Activation button after entering email
12:04:28.735459 10.2.1.2.60410 > 10.2.1.11.3799: Disconnect-Request (40)
12:04:28.736847 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:04:28.737166 10.2.1.11.3799 > 10.2.1.2.60410: Disconnect-ACK (41)
12:04:28.762991 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
12:04:30.717764 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
12:04:30.782158 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
12:04:30.906401 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:04:30.943903 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
~2s later Client is on normal/user VLAN with "Connected" message.

Corresponding log entries from the pf radius log showing Registration (81)
and Normal (76) vlans in concert with the Access-Request packets:

Mar  5 12:03:58 pf4 auth[1284]: [mac:a0:cc:2b:15:20:97] Accepted user:  and
returned VLAN 81
Mar  5 12:03:58 pf4 auth[1284]: (89) Login OK: [a0cc2b152097] (from client
10.2.1.11 port 0 cli a0:cc:2b:15:20:97)
Mar  5 12:04:30 pf4 auth[1284]: [mac:a0:cc:2b:15:20:97] Accepted user:  and
returned VLAN 76
Mar  5 12:04:30 pf4 auth[1284]: (90) Login OK: [a0cc2b152097] (from client
10.2.1.11 port 0 cli a0:cc:2b:15:20:97)

The hostapd radius logs align with PF and show the disconnect is followed
by the new vlan received in the Access-Accept (2) message

Mon Mar  5 12:03:58 2018 daemon.info hostapd: wlan0: STA a0:cc:2b:15:20:97
RADIUS: VLAN ID 81
Mon Mar  5 12:03:58 2018 daemon.info hostapd: wlan0: STA a0:cc:2b:15:20:97
RADIUS: starting accounting session 628C7DBAF341039F
Mon Mar  5 12:04:28 2018 daemon.info hostapd: wlan0: STA a0:cc:2b:15:20:97
RADIUS: stopped accounting session 628C7DBAF341039F
Mon Mar  5 12:04:30 2018 daemon.info hostapd: wlan0: STA a0:cc:2b:15:20:97
RADIUS: VLAN ID 76
Mon Mar  5 12:04:30 2018 daemon.info hostapd: wlan0: STA a0:cc:2b:15:20:97
RADIUS: starting accounting session 628C7DBAF341039F


Here is what it looks like in the buggy scenario where the user is prompted
twice to "Sign into Network".  It looks like after the Disconnect-Request
(40) to change to the normal VLAN, the hostapd does not send the
Access-Request (1) but just uses the VLAN from the previous
Access-Accept(2).

Client Connects to WiFi Network and Prestented with Email Activation in
Portal
15:11:35.269960 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
15:11:35.326104 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
15:11:35.386984 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:11:35.427652 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
~22s later Client hits Activation button after entering email
15:11:57.417798 10.2.1.2.58842 > 10.2.1.11.3799: Disconnect-Request (40)
15:11:57.420730 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:11:57.424759 10.2.1.11.3799 > 

Re: [PacketFence-users] Wrong language after upgrade to 7.0.4

[Ian MacDonald via PacketFence-users]

Hubert,

I would assume you mean upgraded from 7.3.0 to 7.4.0;

I think by default, connection profiles support whatever locale your
browser requests.   Maybe confirm your local setup using mybrowserinfo.com
and make sure you are requesting the language you want.

Using locale= will let your browser select the locale.

You should probably just start with a clone of the default connection
profile with no languages specified and see if the problem occurs there
with the correct browser locale, both in the Preview from the admin GUI as
well as when you hit the captive portal directly.

Compare different devices with your desired locale setting set to rule out
the client.

If the problem goes away with a clone of the default connection profile,
you can focus on your profile configuration and files, opting to find the
difference by direct comparison.

I am not sure, but your locale setting may also require subtags;  I'm not
sure the "de" language identifier will actually match one of the German
locales. Check the notation is correct
https://www.w3.org/TR/ltli/#language-terminology

I don't use the locale setting myself.

cheers,
Ian



On Wed, Feb 28, 2018 at 3:26 AM, Hubert Kupper via PacketFence-users <
packetfence-users@lists.sourceforge.net> wrote:

> Hello,
>
> I did a upgrade from 7.0.3 to 7.0.4. After the upgrade, the profile
> language is english while in pf.conf and profiles.conf the language is
> already set to "de".  Any ideas?
>
> Best regards,
> Hubert
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> PacketFence-users mailing list
> PacketFence-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users