On Thu, Jan 26, 2023 at 9:29 PM Enrique Gross via PacketFence-users <
packetfence-users@lists.sourceforge.net> wrote:
> Hi Ian.
>
> Dont worry!, good luck on that!
>
We figured it out with some insights from Diego, who suggested we try
dropping Option 114 from the registration VLAN. iPhones that receive the
DHCP Option 114 from the packetfence registration VLAN will attempt to use
it for network detection when they land on the production network.
The ideal configuration seems to be one with Secure-Redirect enabled and
Option 114 disabled, which is a tricky state to get to using just the
configuration options and service restarts. You have to start PF with
Secure-Redirect disabled in configuration to signal Option 114 should not
be used, and then enable Secure-Redirect in the GUI after the registration
VLAN is running, restarting the haproxy-portal and portal.httpd services to
accomplish this. Secure-Redirect is not strictly required for iPhone, but
is likely a more compatible option in most other client scenarios.
You can easily verify Secure-Redirect by hitting your public portal
listener, which automatically redirects to the captive portal landing page
in the default configuration. If you see the lock, you know it is
enabled. Hitting this page before and after you restart the haproxy-portal
and portal.httpd services is a simple verification of the change that the
services restarts effect. On PF 11.0 the service restart option for
haproxy-portal is not presented at the bottom of the GUI page, so you need
to do it from the service maintenance page.
You can verify if the Option 114 is not present on the registration VLAN by
doing a quick tcpdump -vvv -i <RegistrationInterface> port 67 or port
68 registration
VLAN and observing the Option 114 is not present in the ACK message.
10:03:34.353144 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto
UDP (17), length 335)
10.2.2.2.bootps > 10.2.2.179.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
length 307, xid 0xe2d83b7, Flags [none] (0x0000)
Your-IP 10.2.2.179
Client-Ethernet-Address 92:a3:35:5f:4b:09 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 10.2.2.2
Lease-Time (51), length 4: 30
Subnet-Mask (1), length 4: 255.255.255.0
Domain-Name-Server (6), length 4: 10.2.2.2
Default-Gateway (3), length 4: 10.2.2.2
Domain-Name (15), length 31: "vlan-registration.domain.com"
END (255), length 0
There does not seem to be a simple way to persist Secure-Redirect and
excluding Option 114 over reboot, so we opened an enhancement suggestion to
handle the workaround until there is a more robust solution.
https://github.com/inverse-inc/packetfence/issues/7478
Additionally, IOS16 devices (and maybe fully uptodate IOS 15) have a quirk
not present in IOS 15.1, where they do not release their DHCP on the
registration VLAN, so your network re-evaluation delay has to outlast your
Registration VLAN lease time (30s by default), plus any fencing delays (we
need about 20s with hostapd to avoid race scenarios) which leaves us at 80s
minimum for the redirection delay (progress bar) on network re-evaluation
for the very latest iPhones to perform the change cleanly.
This new quirk, seems like a behaviour intended to smooth transitions on
buggy mesh networks, where an iPhone is moving between a base unit and an
extender with the same SSID and they want sessions to persist if the lease
is not expired AND the SSID is the same, which is the case for a captive
portal switching VLANs under the hood from the Registration to the
Production network.
The next part is purely a guess, but I think that IOS 16 is ignoring a
DHCP NACK, that IOS 15.1 does not, from the new DHCP server on the
production network, which otherwise would signal to grab a new IP from the
authoritative server. I am not fluent with the spec for this behaviour,
but it feels like a workaround for other device problems, like maybe when a
low cost wifi extender fires up a dhcp service for reconfiguration,
unexpectedly, when the base unit performs an auto-channel WiFi change that
caused a brief backhaul disconnect. It feels like a scenario that when
enough retail solutions cause one problem, they hack around it creating
another, rather than doing strict RFC compliance. Or maybe new mesh wifi
RFCs say do this. It sure does slow down the Captive Portal network
evaluation. Perhaps RFC 8908 has a feature that offsets this new behavior.
cheers,
Ian
> Enrique.
>
> El jue, 26 ene 2023 a las 13:25, Ian MacDonald (<i...@netstatz.com>)
> escribió:
>
>> Enrique,
>>
>>
>>> 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.
>>>
>>
>> Not sure I understand. I believe when you say "local" you mean on the
>> same subnet and router/firewall you mean the gateway for the
>> default/production network. This is not an inline configuration, so there
>> is no captive portal listener on the default/production 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]
>>>
>>
>> This looks like the set of variables from your connection profile to
>> match clients to a specific profile. I believe the Basic filters are just
>> OR operations. I am not really understanding how this relates to the
>> iPhone network detection issue we are trying to resolve. We have no
>> issues with client association to the correct networks; These evaluations
>> for devices on the Registration networks do not apply once devices are out
>> on the Production network, where our network detection issues apply.
>> Packetfence can not identify the MAC on Production networks in non-inline
>> setups, without pushing data back via DHCP connectors or otherwise.
>>
>> 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.
>>>
>>
>> I think you misunderstand our Captive Portal configuration, where clients
>> are granted only a few minutes of access, after which, if they do not click
>> the Activation link sent from the Packetfence server, they are booted back
>> to the Registration network.
>>
>> The activation link points directly to the portal listener page with a
>> client specific URL to both complete the registration for a longer access
>> period and display that information back to the client.
>>
>>
>>> *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
>>> <http://pf4.dotto-one.com> again hitting the "Your computer was not found
>>> on database"*
>>>
>>
>> Yes, the portal needs to be resolvable from the Production network in
>> order to use the Activation Link sent by email; Maybe for other reasons
>> too; We do not use like the Status page, and re-registration functions.
>> Like most things with PF, there is amost and endless amount of
>> configuration variations hooking into the various endpoints available.
>>
>>
>>> 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"*
>>>
>>
>> The redirection URL, which is passed to the client isn't always obeyed or
>> followed; It is very client specific. But yes, after network detection,
>> if the client can handle the redirection, it will execute it. For clients
>> that persist the network evaluation across the network change, when they
>> get to the end of the progress bar, generally the redirection works as they
>> are following the javacript page and its embedded functions exclusively.
>> On clients that close portal capture on network changes (like the iPhones
>> we are testing) as soon as they detect the network change, they may often
>> not perfom the redirection. YMMV here.
>>
>>
>>> 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.
>>>
>>
>> No problem Enrique. I would say if you have specific questions, fire up
>> a new thread.
>>
>> Even though I only pop up here every few years looking for a bit of help
>> on keeping this free public service wifi rolling, I am always concious of
>> keeping a balance between benefiting from free support and giving back to
>> the community, and helping offload Inverse/Akamai resources that might
>> otherwise be focused on paid engagements. Through this little iPhone
>> issue I have found some cycles to report some issues, enhacements and post
>> contributions. I would encourage anyone to do the same - and although I
>> believe you might be adding some cruft to my thread to resolve this iPhone
>> issue - I like that you are trying to jump in and offer some help based on
>> your own experience.
>>
>> Ian
>>
>>>
>>> El mié, 25 ene 2023 a las 11:27, Ian MacDonald (<i...@netstatz.com>)
>>> 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 <https://github.com/inverse-inc/packetfence/issues/7472>
>>>> 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
>>>> <https://github.com/inverse-inc/packetfence/issues/7040> but it seems
>>>> what used to work in IOS 13/14 using the RFC7710bis
>>>> <https://github.com/inverse-inc/packetfence/issues/5638> 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 (<i...@netstatz.com>)
>>>>> 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 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 (<packetfence-users@lists.sourceforge.net>)
>>>>> >> 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.
>>>>> >> >
>>>>> >> > Help on how to do either of these things in Packetfence config
>>>>> appreciated.
>>>>> >> >
>>>>> >> > Here is our lab v12.1 setup.
>>>>> >> >
>>>>> >> >
>>>>> >> > As we moved through our testing we have made a few changes, none
>>>>> of which seem to impact the expected outcome. We have enabled proxy
>>>>> interception, changed our network detection to a local IP, modified the
>>>>> detection delay (30s) so that it starts after the fencing delay (25s), and
>>>>> allow 60s for the re-evaluation on the portal page progress bar. We
>>>>> disabled CSP headers and secure_redirect in hopes of providing more
>>>>> information during packet captures. Passthrough during fencing is now
>>>>> disabled as well to keep traffic to a minimum. Our registration DHCP
>>>>> lease
>>>>> time was shortened to 15 seconds.
>>>>> >> >
>>>>> >> > [fencing]
>>>>> >> > wait_for_redirect=25
>>>>> >> > interception_proxy=enabled
>>>>> >> > [captive_portal]
>>>>> >> > network_detection_ip=104.244.196.157
>>>>> >> > network_detection_initial_delay=30s
>>>>> >> > network_redirect_delay=60s
>>>>> >> > request_timeout=5
>>>>> >> > secure_redirect=disabled
>>>>> >> > rate_limiting=disabled
>>>>> >> > [advanced]
>>>>> >> > portal_csp_security_headers=disabled
>>>>> >> >
>>>>> >> > [10.2.2.0]
>>>>> >> > dhcp_default_lease_time=15
>>>>> >> > dhcp_max_lease_time=15
>>>>> >> >
>>>>> >> > The iPhone in this latest scenario is an iPhone 7 Pro running IOS
>>>>> 15.
>>>>> >> > Registration has no issues, and VLAN switching occurs as expected
>>>>> at 25s on the "Enabling network access" portal page, placing the iPhone
>>>>> onto the Default network.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > When the iPhone is disconnected from the Registration network,
>>>>> the Log In page closes, and the wifi settings appear briefly.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > The iPhone then connects to the Default network, however it
>>>>> decides it must be still behind the packetfence captive portal, as it
>>>>> reloads the Portal Login page again, and the user is trapped, and can not
>>>>> escape except to hit Cancel and select "Use without Internet".
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > The iPhone is holding on to the captive portal page it learned on
>>>>> the Registration network, and when it gets to the Default network it fails
>>>>> at detecting it is on the Internet, it returns to the Captive Portal page,
>>>>> and is effectively trapped there. If it can see the Packetfence listener,
>>>>> it believes it is still captured.
>>>>> >> >
>>>>> >> > With this in mind, we decided to simply block traffic from the
>>>>> Default network to the Portal Page with a simple firewall rule to drop
>>>>> traffic to the packetfence public IP.
>>>>> >> >
>>>>> >> > And the iPhone detects Internet. That was it. The detection was
>>>>> not based on DHCP option 114, or reaching some other site, or the
>>>>> network-access-detection.gif It is based on reaching the Captive Portal
>>>>> URL, which is responding, as it is the same hostname where we expect our
>>>>> users to go for Email Activation Links.
>>>>> >> >
>>>>> >> > The problem with blocking the Portal listener on the Default
>>>>> network is that the user can not complete the email registration, as the
>>>>> same portal listener that serves up the Captive Portal service up the
>>>>> Registration Activation Link (/activation/email.html).
>>>>> >> >
>>>>> >> > It suggests we have to get the iPhone to ignore the Captive
>>>>> Portal URL it learned from the Registration VLAN? Is this a bug in
>>>>> implementation of the captive portal API usage in iPhones?
>>>>> >> >
>>>>> >> > Our Default network DHCP sees Option 114 requested, and provides
>>>>> the unrestricted value (shown below). Maybe somebody can confirm the
>>>>> format and content is correct so we can validate our assumption that the
>>>>> iPhone is just ignoring it. We also pass the same value in Option 160
>>>>> just
>>>>> in case it ever is requested by an old client.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > I have collected pCaps from the Registration VLAN (Interface
>>>>> 10.2.2.2 on our PF server) and from the Default Network (Interface
>>>>> 10.2.4.1) as well as the haproxy_portal.log and packetfence.log from the
>>>>> same time period. Nothing removed from those time periods, as there were
>>>>> no other devices on those networks. I will leave them up whilst we are
>>>>> working on this issue for anyone to inspect with Wireshark.
>>>>> >> >
>>>>> >> >
>>>>> https://drive.google.com/drive/folders/1NFuDqJIkPrsMWs_DXqIeY0l_TTLYkPpE?usp=share_link
>>>>> >> >
>>>>> >> > I suppose a workaround could be to change the [% activation_uri
>>>>> %] to a DNS hostname alias that is different than the captive portal
>>>>> hostname and override the Default Network DNS so that the captive portal
>>>>> URL goes nowhere (equivalent to our firewall block), allowing the users
>>>>> to
>>>>> still hit the activation link and block iPhones from getting trapped on
>>>>> the
>>>>> portal page at the same time.
>>>>> >> >
>>>>> >> > A follow-up question is does anyone know how to specify the
>>>>> activation URL as a configuration parameter? We couldn't find it, as it
>>>>> seems generated in the templates.
>>>>> >> >
>>>>> >> > It seems we are just down to configuration here; Getting close.
>>>>> >> >
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > PacketFence-users mailing list
>>>>> >> > PacketFence-users@lists.sourceforge.net
>>>>> >> > https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>>> >> >
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > PacketFence-users mailing list
>>>>> >> > PacketFence-users@lists.sourceforge.net
>>>>> >> > https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> PacketFence-users mailing list
>>>>> >> PacketFence-users@lists.sourceforge.net
>>>>> >> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PacketFence-users mailing list
>>>>> PacketFence-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>>>
>>>>
>>>
>>> --
>>>
>>> [image: Imágenes integradas 1]
>>> _______________________________________________
>>> PacketFence-users mailing list
>>> PacketFence-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>
>>
>
> --
>
> [image: Imágenes integradas 1]
> _______________________________________________
> PacketFence-users mailing list
> PacketFence-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
