Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

[Diego Garcia del Rio via PacketFence-users]

Hi Bill

I haven't installed pf10 yet. But I think the key item is the fact that the
registration vlan DNS is not resolving to the correct PF address. Do you
have any nic or vlan configured with that IP?

You mention replacing the fqdn for that of the registration vlan. Is that
provisioned on your own DNS server ? Cause in my case I only have a DNS
entry for the "management" interface and packetfence uses the same name but
spoofs the DNS with with registration vlan IP

Maybe you have more than one registration vlan?



On Wed, Apr 29, 2020, 09:23 Bill Handler  wrote:

> Diego,
>
>
>
> Ran some packet captures on Monday and every time the end-system was
> looking for the IP of the packetfence host – DNS lookup – it was returned
> as a 192.0.2.1.  This is some sort of internal IP that PF is using for the
> portal, as it is the default response no matter what is requested.  I
> checked this via NSLookup on the end-system.
>
>
>
> Thinking I had messed something up in the initial config/deployment (this
> is still as test environment), I re-built/deployed with a fresh install.
>
>
>
> Once everything was built-out, I had the same results.  After entering the
> credentials for Google login, I get the browser window stating that I need
> to log into the network with a ‘connect now’ button.  The address within
> the browser shows:  https://pf428.pcsknox.com/oauth2/callback?code=...
>
>
>
> pf428.pcsknox.com is the hostname/FQDN of the PacketFence server.  In the
> capture I see the DNS request for this, but as I said it is returned as
> 192.0.2.1.  If I replace the FQDN of the PF server with the Registration
> VLAN interface IP on the PF server, the authentication goes through and I
> get the screen showing that the role has been assigned, and am flipped to
> the correct VLAN.  The packet capture shows a DNS query from the end-system
> for “dl.google.com”, which is answered with the correct info.  About 2
> seconds later there is a DNS Query from the end-system for “
> passwordsleakcheck-pa.googleapis.com” which is also answered correctly.
> This is the last DNS request on this VLAN for the end-system.
>
>
>
> So for whatever reason, the system is not authenticating the
> response/token from Google when it is presented from the end-system – I
> think this is what is happening.  It seems the process is breaking down
> between the end-system and the FP server when Google sends the token.  I’m
> not sure where to look to see where the 192.0.2.1 address is coming from,
> or how to put an ‘A’ record in to the registration vlan dns to point the
> FQDN to the interface’s IP, or what is needed here.  To me, it seems like a
> DNS issue on PF.
>
>
>
> Is this possibly a bug in the code?  I do have packet captures from the
> end-system, the PF server on the registration vlan interface, and on the
> data vlan interface.
>
>
>
> Just to go over the setup, in case that is part of the issue…
>
>
>
> Hypervisor – Hyper-V 2019
>
> Centos7 VM with PF 10 installed using documentation from
> https://packetfence.org/doc/PacketFence_Installation_Guide.html .  802.1x
> working fine tied to our AD server; using machine auth and user auth, SMS
> authentication works without issue.  The only issue seems to be with
> Oauth.  The PF server has 2 NICs, NIC 1 is for the data vlan untagged
> (eth0), NIC 2 is for the other vlans, registration, and isolation (eth1)
> tagged.  PF is handing out DHCP on registration/isolation vlans.
>
>
>
> Any help is appreciated.
>
>
>
> Thanks,
>
>
>
> Bill
>
>
>
> *From:* Bill Handler
> *Sent:* Friday, April 24, 2020 4:40 PM
> *To:* Diego Garcia del Rio 
> *Cc:* Jonathan Nathanson ;
> packetfence-users@lists.sourceforge.net
> *Subject:* RE: [PacketFence-users] Google oauth2 -
> Behavior/Troubleshooting
>
>
>
> Diego,
>
>
>
> Thanks for your help and guidance on this…  The end-system is getting the
> reply from Google with the authorization code – the Portal URL in the
> config that ends in ‘/callback’.  However, the hostname of the pf server is
> not being resolved.  If I replace the hostname.domain with the IP address
> of the registration VLAN interface on the PF server (the end-system’s
> gateway), the authentication proceeds and the end-system authenticates.
>
>
>
> Weirdness abounds…  I’ll perform a packet capture on Monday when I’m back
> in the office to see if I can tell what the end-system is requesting for
> ‘website’ that google returns.
>
>
>
> Have a good weekend, and thanks again for your assistance.
>
>
>
> Thanks,
>
>
>
> Bill
>
>
>
> *From:* Diego Garcia del Rio 
> *Sent:* Friday, April 24, 2020 10:29 AM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> packetfence-users@lists.sourceforge.net
> *Subject:* Re: [PacketFence-users] Google oauth2 -
> Behavior/Troubleshooting
>
>
>
> Hi.. those errors are not errors. They are jus the logs of pfdns and its
> still related to the user trying / reaching google.
>
>
>
> you should look at the logs (especially packetfence.log) for any other
> 

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

[Bill Handler via PacketFence-users]

Diego,

Ran some packet captures on Monday and every time the end-system was looking 
for the IP of the packetfence host – DNS lookup – it was returned as a 
192.0.2.1.  This is some sort of internal IP that PF is using for the portal, 
as it is the default response no matter what is requested.  I checked this via 
NSLookup on the end-system.

Thinking I had messed something up in the initial config/deployment (this is 
still as test environment), I re-built/deployed with a fresh install.

Once everything was built-out, I had the same results.  After entering the 
credentials for Google login, I get the browser window stating that I need to 
log into the network with a ‘connect now’ button.  The address within the 
browser shows:  https://pf428.pcsknox.com/oauth2/callback?code=...

pf428.pcsknox.com is the hostname/FQDN of the PacketFence server.  In the 
capture I see the DNS request for this, but as I said it is returned as 
192.0.2.1.  If I replace the FQDN of the PF server with the Registration VLAN 
interface IP on the PF server, the authentication goes through and I get the 
screen showing that the role has been assigned, and am flipped to the correct 
VLAN.  The packet capture shows a DNS query from the end-system for 
“dl.google.com”, which is answered with the correct info.  About 2 seconds 
later there is a DNS Query from the end-system for 
“passwordsleakcheck-pa.googleapis.com” which is also answered correctly.  This 
is the last DNS request on this VLAN for the end-system.

So for whatever reason, the system is not authenticating the response/token 
from Google when it is presented from the end-system – I think this is what is 
happening.  It seems the process is breaking down between the end-system and 
the FP server when Google sends the token.  I’m not sure where to look to see 
where the 192.0.2.1 address is coming from, or how to put an ‘A’ record in to 
the registration vlan dns to point the FQDN to the interface’s IP, or what is 
needed here.  To me, it seems like a DNS issue on PF.

Is this possibly a bug in the code?  I do have packet captures from the 
end-system, the PF server on the registration vlan interface, and on the data 
vlan interface.

Just to go over the setup, in case that is part of the issue…

Hypervisor – Hyper-V 2019
Centos7 VM with PF 10 installed using documentation from 
https://packetfence.org/doc/PacketFence_Installation_Guide.html .  802.1x 
working fine tied to our AD server; using machine auth and user auth, SMS 
authentication works without issue.  The only issue seems to be with Oauth.  
The PF server has 2 NICs, NIC 1 is for the data vlan untagged (eth0), NIC 2 is 
for the other vlans, registration, and isolation (eth1) tagged.  PF is handing 
out DHCP on registration/isolation vlans.

Any help is appreciated.

Thanks,

Bill

From: Bill Handler
Sent: Friday, April 24, 2020 4:40 PM
To: Diego Garcia del Rio 
Cc: Jonathan Nathanson ; 
packetfence-users@lists.sourceforge.net
Subject: RE: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Diego,

Thanks for your help and guidance on this…  The end-system is getting the reply 
from Google with the authorization code – the Portal URL in the config that 
ends in ‘/callback’.  However, the hostname of the pf server is not being 
resolved.  If I replace the hostname.domain with the IP address of the 
registration VLAN interface on the PF server (the end-system’s gateway), the 
authentication proceeds and the end-system authenticates.

Weirdness abounds…  I’ll perform a packet capture on Monday when I’m back in 
the office to see if I can tell what the end-system is requesting for ‘website’ 
that google returns.

Have a good weekend, and thanks again for your assistance.

Thanks,

Bill

From: Diego Garcia del Rio mailto:garc...@gmail.com>>
Sent: Friday, April 24, 2020 10:29 AM
To: Bill Handler mailto:bhand...@pcsknox.com>>
Cc: Jonathan Nathanson mailto:jmhnathan...@gmail.com>>; 
packetfence-users@lists.sourceforge.net
Subject: Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Hi.. those errors are not errors. They are jus the logs of pfdns and its still 
related to the user trying / reaching google.

you should look at the logs (especially packetfence.log) for any other messages 
around the time. Most of the log messages SHOULD have the mac address of the 
device trying to connect so you can grep for those

(you can also use grep -i to make grep case insensitive, so "grep -i oauth" 
should find... all variations of oauth..

also try to set the debug level for the portal module to dEBUG or TRACE:

like this:


conf/log.conf.d/pfqueue.conf



Change to following line from this



log4perl.rootLogger = INFO, PFQUEUE



To this



log4perl.rootLogger = TRACE, PFQUEUE



Then you can either wait 5 minutes (that is the time it takes for the

logging level to be updated)



Or restart the service if you do not want to wait.

But adapt it to the