Re: [PacketFence-users] iPhones trapped on reload of Captive Portal Log In Page after switch to Default network

[Ian MacDonald via PacketFence-users]

Hi Enrique,


> Regarding error "Your computer was not found in the database"
>

This is presented to anyone hitting the portal from the public Internet.
For instance if you went to http://pf4.dotto-one.com/ right now, you should
see it, as the listener is active, for other client activities like email
link activation, pre-registration (we do not use) and the default captive
portal landing page will not find you in the database, because it can only
do MAC based identification on the registration and isolation networks
where it can see that L2 information.   Traffic from the Internet is
routed, and will show as MAC:0 and the current client public IP at the
bottom of the page.

On the iPhone, once network detection is complete, it shouldn't be talking
the user back to the captive portal, but it is.  Just blocking this traffic
would force the client into believing it was no longer captive, but this
would prevent access to the listener for email activation.


> Have you tried local DNS resolution for the captive portal domain on
> the default network, applying firewall rule to secure access to the
> portal listener interface
>

I am not sure what you are asking me here.  The DNS server on the Default
network is on the local subnet, and is the gateway.  It resolves the same
public DNS as the link above to the portal listener.   The firewall in
front of the portal listener has firewall rules, and only Port 80/444 are
allowed and forwarded on to the packetfence server portal listener.  I
believe this is standard routed topology;  It has been setup this way since
our first routed captive portal on Packetfence 5.

- And I'll throw this unrelated comment in. ** We only use the captive
portal functionality for free public wifi;  though I am keen to find some
clients that need a full NAC. The fact that we have been able to evergreen
some circa Packetfence 5/7 instances across Debian upgrades is impressive
and speaks to the Inverse team's platform commitment. The new docker model
reduces cross-platform complexity even further.   The GUI is so
functional;  In my recent sessions, I stumbled across the netflow
renderings; The lease timelines;  It is sharp; Bien fait.   I posted modified
hostapd.sh  for
recent OpenWRT releases which will hopefully show up in Add-ons.  It makes
it straightforward to turn any supported OpenWRT hardware into a captive
portal for anyone wanting to get familiar with Packetfence, radius, vlan
switching, isolation, authentication, etc. without any enterprise gear in
their home lab.
 **

>
> When the client lands on the default network, resolving the external
> IP address for the captive portal domain, that "Nating" presents “as
> computer not found on database”,  I remember also adding a "network"
> filter to the connection profile for routed networks that need to
> access captive-portal.
>

I am not sure I understand what you are suggesting;  The "computer not
found on database" is the expected result - we just do not want iPhones
getting there once they are connected to the Internet.  They should just
detect Internet and move on without returning to the portal.  If we block
it using the firewall, detection is fine.  If you know how to create a
filter for the /captive-portal on the public facing portal listener, that
would  be one way to workaround our iPhone network detection problem.

All our other clients that we have tested seem to be okay with the current
javascript implementation.  We just need to get the iPhones fixed until
RFC8908 is supported. I can see it has been discussed
 but it seems what
used to work in IOS 13/14 using the RFC7710bis
 introduced in PF10
isn't working any longer.   The clients do not use the network detection IP
or image embedded in the captive portal javascript as seen in the captures
we posted.   They simply 'test' if they are still trapped based on
reachability to the captive portal URL.

I believe if we can somehow separate the ConfNet.PortalFQDN  used by the
captive portal redirect from the one used in email activation, we can use
our Default network local DNS to make the current RFC7710bis implementation
work with iPhones.  If you know how this could be done, it would be a
second to workaround our iPhone network detection problem.


> El mar, 24 ene 2023 a las 19:59, Ian MacDonald ()
> escribió:
> >
> > Quick inline response to your questions;  Thank you for having a peek.
> >
> > On Tue, Jan 24, 2023 at 5:45 PM Enrique Gross via PacketFence-users <
> packetfence-users@lists.sourceforge.net> wrote:
> >>
> >> Regarding DNS, domain resolves to your public address? is that
> >> correct? And that is the same domain as captive portal?
> >
> > Yes, as seen from the Default network, and the Internet, the packetfence
> server hostname resolves using public DNS, and lands on the portal listener
> 

Re: [PacketFence-users] iPhones trapped on reload of Captive Portal Log In Page after switch to Default network

[Enrique Gross via PacketFence-users]

Hi Ian

If you need to access portal services from the default network, i think you
don't really need to resolve pf4.dotto-one.com to your public address, you
can add a static record on your DNS server on your default network,
pointing pf4.dotto-one.com to your local captive-portal listener address,
then config your router/firewall so you can reach portal listener address
from the default network.

I'm not really sure this is the "right" way to configure this, but I manage
to access portal services this way from routed networks, changing
connection profile filter. I had to do this to access self-service
registration from a remote network.

[image: imagen.png]

Also, once a client lands on the default network there is no need to access
the portal, as registration is done, and the client is placed on the
desired VLAN.

*But if client lands on the default vlan and gets new DNS server from DHCP
maybe will still intend to resolve pf4.dotto-one.com
 again hitting the "Your computer was not found
on database"*

I understand that when RADIUS disconnect is done, the client reconnects,
gets a new VLAN, new IP and maybe a new DNS server. *What happen next is
that client should be redirected to the "Redirection URL" *

I'm new to packetfence, i don't want to mislead you on your config, I have
found your setup interesting and your troubleshooting is super good to keep
on learning on this.

Enrique


El mié, 25 ene 2023 a las 11:27, Ian MacDonald ()
escribió:

> Hi Enrique,
>
>
>> Regarding error "Your computer was not found in the database"
>>
>
> This is presented to anyone hitting the portal from the public Internet.
> For instance if you went to http://pf4.dotto-one.com/ right now, you
> should see it, as the listener is active, for other client activities like
> email link activation, pre-registration (we do not use) and the default
> captive portal landing page will not find you in the database, because it
> can only do MAC based identification on the registration and isolation
> networks where it can see that L2 information.   Traffic from the Internet
> is routed, and will show as MAC:0 and the current client public IP at the
> bottom of the page.
>
> On the iPhone, once network detection is complete, it shouldn't be talking
> the user back to the captive portal, but it is.  Just blocking this traffic
> would force the client into believing it was no longer captive, but this
> would prevent access to the listener for email activation.
>
>
>> Have you tried local DNS resolution for the captive portal domain on
>> the default network, applying firewall rule to secure access to the
>> portal listener interface
>>
>
> I am not sure what you are asking me here.  The DNS server on the Default
> network is on the local subnet, and is the gateway.  It resolves the same
> public DNS as the link above to the portal listener.   The firewall in
> front of the portal listener has firewall rules, and only Port 80/444 are
> allowed and forwarded on to the packetfence server portal listener.  I
> believe this is standard routed topology;  It has been setup this way since
> our first routed captive portal on Packetfence 5.
>
> - And I'll throw this unrelated comment in. ** We only use the captive
> portal functionality for free public wifi;  though I am keen to find some
> clients that need a full NAC. The fact that we have been able to evergreen
> some circa Packetfence 5/7 instances across Debian upgrades is impressive
> and speaks to the Inverse team's platform commitment. The new docker model
> reduces cross-platform complexity even further.   The GUI is so
> functional;  In my recent sessions, I stumbled across the netflow
> renderings; The lease timelines;  It is sharp; Bien fait.   I posted modified
> hostapd.sh  for
> recent OpenWRT releases which will hopefully show up in Add-ons.  It makes
> it straightforward to turn any supported OpenWRT hardware into a captive
> portal for anyone wanting to get familiar with Packetfence, radius, vlan
> switching, isolation, authentication, etc. without any enterprise gear in
> their home lab.
>  **
>
>>
>> When the client lands on the default network, resolving the external
>> IP address for the captive portal domain, that "Nating" presents “as
>> computer not found on database”,  I remember also adding a "network"
>> filter to the connection profile for routed networks that need to
>> access captive-portal.
>>
>
> I am not sure I understand what you are suggesting;  The "computer not
> found on database" is the expected result - we just do not want iPhones
> getting there once they are connected to the Internet.  They should just
> detect Internet and move on without returning to the portal.  If we block
> it using the firewall, detection is fine.  If you know how to create a
> filter for the /captive-portal on the public facing portal listener, that
> would  be one way to workaround our iPhone 

Re: [PacketFence-users] Eduroam port 11812 not working

[Zammit, Ludovic via PacketFence-users]

Hello Anne,

When you are connecting from another University / Eduroam SSID, the incoming 
connection would come from the Eduroam servers so, you will need to have a 
public IP address that sent out the radius authentication to your PF on port 
1812 and not 11812.

Local SSID radius -> 11812
Eduroam online servers -> Public IP:1812 -> PacketFence management:1812

Create a connection profile with a realm eduroam.

Thanks,

Ludovic Zammit
Product Support Engineer Principal Lead

Cell: +1.613.670.8432
Akamai Technologies - Inverse
145 Broadway
Cambridge, MA 02142
Connect with Us:   
    
  
  


> On Jan 25, 2023, at 8:10 AM, Anne Dijkstra  
> wrote:
> 
> Hi Ludovic,
> 
> Thanks, that was the trick  I accidentally configured the internal eduroam 
> source instead of the exclusive source haha.
> 
> I have only 1 issue for now:
> The domain is ubboemmius.net , and is configured in 
> the realm default. This realm is added to the eduroam ' exclusive source'. 
> That means when I connecting to eduroam as an AD user (local user), they use 
> the default realm. That is working for now.
> 
> But when I connecting with an account from an other organization to our 
> eduroam SSID, the logging has error with reason 'chrooted_mschap: Program 
> returned code (1) and output 'The attempted logon is invalid. This is either 
> due to a bad username or authentication information. (0xc06d)'
> It looks like the Radius request does not proxy to eduroam.
> The name of the SSID is "UE-eduroam" because It's a test SSID and when I set 
> the name of the SSID to 'eduroam' everyone is connecting ;p
> 
> This is the log:
> 
> 
> 
> This is the eduroam connection profile:
> 
> 
> 
> And this is the exclusive authentication source:
> 
> 
> 
> So:
> 
> AD user on our eduroam: Works
> AD user @ another school: Works
> User from another school on our eduroam: Not working
> 
> 
> Any ideas? 
> 
> Met vriendelijke groet,
> 
> 
> 
> Anne Dijkstra 
> 
>  
> Noorderpoort
> Dienst Facilities
> Postbus 169
> 9700 AD Groningen
> Muntinglaan 3
> 9727 JT Groningen
> 
> T
> +31 88 230 9204
> E
> ab.dijks...@noorderpoort.nl 
> I
> www.noorderpoort.nl 
> 
> Van: Zammit, Ludovic
> Verzonden: Dinsdag, 24 Januari, 2023 18:06
> Aan: PacketFence-users
> CC: Tomasz Karczewski; Anne Dijkstra
> Onderwerp: Re: [PacketFence-users] Eduroam port 11812 not working
> 
> Hello Anne,
> 
> Make sure you configured the Eduroam source in PF and attached it to a 
> connection profile.
> 
> https://www.packetfence.org/doc/PacketFence_Installation_Guide.html#_eduroam 
> 
> 
> Don’t to forget to restart radiusd so all services would be there to listen 
> on 11812
> 
> /usr/local/pf/bin/pfcmd service radiusd restart
> 
> Thanks,
> 
> Ludovic Zammit
> Product Support Engineer Principal Lead
> 
> Cell: +1.613.670.8432
> Akamai Technologies - Inverse
> 145 Broadway
> Cambridge, MA 02142
> Connect with Us:     
>   
> 
>   
> 
>   
> 
>   
> 
> 
>> On Jan 24, 2023, at 7:08 AM, Anne Dijkstra via PacketFence-users 
>> > > wrote:
>> 
>> Hi Tomasz,
>> 
>> Thank you for your reply.
>> Now the eduroam ext source is configured with port 11812 and I set port 
>> 11812 in our WiFi controller.
>> But as I mentioned in my previous e-mail, when I make an authentication 
>> request from the WiFi controller to Packetfence on port 11812, it does 
>> nothing. The WiFi controller has error "Connection time out". 
>> When I start TCPdump on the Packetfence server I only see incoming packets 
>> from the WiFi controller, but no reply.
>> So it looks like Packetfence does not reply on port 11812.
>> 
>> Thank you!
>> 
>> Met 

Re: [PacketFence-users] iPhones trapped on reload of Captive Portal Log In Page after switch to Default network

[Enrique Gross via PacketFence-users]

Hi Ian

Regarding error "Your computer was not found in the database"

Have you tried local DNS resolution for the captive portal domain on
the default network, applying firewall rule to secure access to the
portal listener interface

When the client lands on the default network, resolving the external
IP address for the captive portal domain, that "Nating" presents “as
computer not found on database”,  I remember also adding a "network"
filter to the connection profile for routed networks that need to
access captive-portal.

Enrique



El mar, 24 ene 2023 a las 19:59, Ian MacDonald () escribió:
>
> Quick inline response to your questions;  Thank you for having a peek.
>
> On Tue, Jan 24, 2023 at 5:45 PM Enrique Gross via PacketFence-users 
>  wrote:
>>
>> Regarding DNS, domain resolves to your public address? is that
>> correct? And that is the same domain as captive portal?
>
> Yes, as seen from the Default network, and the Internet, the packetfence 
> server hostname resolves using public DNS, and lands on the portal listener 
> attached to the management network interface on the server.
>
>>
>> On your topology, port 80/443 redirected to “PF redirection URL”?
>
>
> Yes, in hindsight, that detail should have been removed, as it is confusing 
> in that it is unrelated to the issue, and that redirection rule is not active 
> in this test environment.
>
> In production, there was a redirection URL in the Captive Portal 
> configuration that goes to a web site;  Provided by the ISP that is providing 
> the free Internet.
> A similar redirection, if you happen to point your web browser at the Default 
> network gateway, also goes to that same location.  The thinking here was if 
> you are surfing in the Public space, and get curious and do a myipaddress.com 
> look up and then go to that IP in your browser, you hit the same landing page 
> as the captive portal redirection.
>
> It is not active in this environment, so I should have purged it from the 
> topology snapshot
>
>>
>> Enrique
>>
>> El mar, 24 ene 2023 a las 8:19, James Andrewartha via
>> PacketFence-users ()
>> escribió:
>> >
>> > Hi Ian,
>> >
>> > So looking through the registration PCAP, one thing I notice is that 
>> > there's three requests for http://captive.apple.com/hotspot-detect.html 
>> > before it tries to follow the redirect that page returns. Also your DNS is 
>> > returning the same IP (66.70.255.147) for captive.apple.com as for 
>> > pf4.dotto-one.com. Are you doing DNS enforcement on the portal? Then on 
>> > the default network, you return 104.244.196.73 for pf4.dotto-one.com. I 
>> > don't think that's wrong per se but just wanted to be clear.
>> >
>> > I see some accesses to https://pf4.dotto-one.com/rfc7710 after it joins 
>> > the default network, can you see what content is returned? Since it tries 
>> > that first before going to the captive portal URL on the default network. 
>> > Short of that, could you remove option 114 and 160 from both registration 
>> > and default network DHCP scopes? My feeling is that it's holding onto the 
>> > URL from the registration network and re-using that on the default network 
>> > instead of looking at the cappport:unrestricted value returned on the 
>> > default network.
>> >
>> > So was the iPhone not re-DHCPing problem solved by very short lease times 
>> > on the registration network?
>> >
>> > Thanks,
>> >
>> > --
>> > James Andrewartha
>> > Network & Projects Engineer
>> > Christ Church Grammar School
>> > Claremont, Western Australia
>> > Ph. (08) 9442 1757
>> > Mob. 0424 160 877
>> >
>> > On 24/1/23 06:53, Ian MacDonald via PacketFence-users wrote:
>> >
>> > Okay,
>> >
>> > We have, again, scoped down our issue further to iPhones not properly 
>> > detecting they are no longer behind the Packetfence Captive Portal.  I am 
>> > going to frame it up once again to see if anyone has any new insights.
>> >
>> > Problem:  The iPhone is holding on to the captive portal page it learns on 
>> > the Registration network, and when it gets to the Default network, it 
>> > fails at detecting it is on the Internet, and it returns to the Captive 
>> > Portal page and traps the user there in the iphone's Log In interface.
>> >
>> > If we block the iPhone from the Packetfence portal listener, after it is 
>> > on the Default network, it works and believes it is no longer Captive.  
>> > Unfortunately this also blocks registration activation links sent via 
>> > Email, so it doesn't quite qualify as a workaround unless we can separate 
>> > the hostname used for Email Activation from the hostname used for the 
>> > Captive Portal and block the latter with DNS overrides on our Default 
>> > network.
>> >
>> > It seems like the correct configuration would have Packetfence instruct 
>> > the iPhones to not use the Captive Portal URL reachability as network 
>> > detection, and possibly we have no control over this OR possibly it can be 
>> > done somehow through the Captive Portal API TBD.
>> >
>>