Pfsense, No internet when it is said "You are connected".
-
Yeah would of been over 5 years ago to be pre 2.2..
That there are still copies out there running such old versions is on one a good testimony to pfsense... On the other hand - WTF people!!! And we wonder why people have issues when they don't update their security software in over 5 years ;)
-
I think I started using pfSence on WatchGuard around 2014 and I do recall there was no hybrid option during that time; probably that config is hanging around since then. The thing I can remember, all of my devices (TV, AV receivers etc.) in a separate VLAN and I didn't want outbound connections for those devices - I think that was main reason
-S -
anyway, going back to captive-portal thing again, is there a way to allow
fonts.googleapis.comfrom the portal, before logging in? I'm working on a custom login page and wish to use some fonts from there in the CSS (i.e.@import url(//fonts.googleapis.com/css?family=Open+Sans);). So I allowed fonts.googleapis.com in theAllowed Hostnamesbut it's not being imported. Anything else I need to do to make it working? Or is it possible at all?
-S -
@MacUsers font.googleapis.com itself is calling other domains
-
@free4 said in Pfsense, No internet when it is said "You are connected".:
@MacUsers font.googleapis.com itself is calling other domains
Interesting!! Haven't noticed that at all.
It started working straight away the moment I also allowedfonts.gstatic.com. Thanks a lot for pointing out!!
-S -
Yes you should be able to define hosts that are allowed before logging in there.
Can you reach
https://fonts.googleapis.com/css?family=Open+Sansdirectly from a client before logging in?Edit: Missed replies on next page.
Steve
-
Hello,
I don't know if my problem is the same as that being listed on this list but ...
I'm having it when pfsense returns from a restart. Users who had authenticated before the restart cannot navigate or authenticate after the restart of the restart pfsense ...
I performed the patch above but nothing
Debug:
[2.4.4-RELEASE][root@pfSense.localdomain]/root: ipfw table portal_test_auth_up list
--- table(portal_test_auth_up), set(0) ---
[2.4.4-RELEASE][root@pfSense.localdomain]/root: ipfw table portal_test_auth_down list
--- table(portal_test_auth_down), set(0) ---sqlite3 /var/db/captiveportalportal_teste.db --line "select * from captiveportal"
allow_time = 1579787905
pipeno = 2000
ip = 10.2.0.4
mac = a1:dd:aa:6b:bb:cc
username = helmet
sessionid = b4d27f77b0c2b79a
bpassword =
session_timeout =
idle_timeout =
session_terminate_time =
interim_interval =
traffic_quota =
authmethod = Local Auth
context = firstPatch can NOT be applied cleanly (detail):
/usr/bin/patch --directory=/ -t -p2 -i /var/patches/5e29a0f922717.patch --check --forward --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:|diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc
|index 453b4f02950..152effd9243 100644
|--- a/src/etc/inc/captiveportal.inc+++ b/src/etc/inc/captiveportal.inc Patching file etc/inc/captiveportal.inc using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 235. Hunk #2 ignored at 600. Hunk #3 ignored at 645. Hunk #4 ignored at 697. Hunk #5 ignored at 747. Hunk #6 ignored at 755. Hunk #7 ignored at 786. Hunk #8 ignored at 1310. Hunk #9 ignored at 1441. Hunk #10 ignored at 1924. Hunk #11 ignored at 1941. Hunk #12 ignored at 1981. Hunk #13 ignored at 1992. Hunk #14 ignored at 2003. Hunk #15 ignored at 2014. Hunk #16 ignored at 2450. 16 out of 16 hunks ignored while patching etc/inc/captiveportal.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc
|index 6d6f33161cb..7e4deb8b326 100644
|--- a/src/etc/inc/system.inc+++ b/src/etc/inc/system.inc Patching file etc/inc/system.inc using Plan A... Hunk #1 succeeded at 2180 with fuzz 2 (offset 60 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/src/usr/local/captiveportal/index.php b/src/usr/local/captiveportal/index.php
|index d5459a80976..44bf0879b32 100644
|--- a/src/usr/local/captiveportal/index.php+++ b/src/usr/local/captiveportal/index.php Patching file usr/local/captiveportal/index.php using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 198. 1 out of 1 hunks ignored while patching usr/local/captiveportal/index.php done Patch can be reverted cleanly (detail):
/usr/bin/patch --directory=/ -f -p2 -i /var/patches/5e29a0f922717.patch --check --reverse --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:|diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc
|index 453b4f02950..152effd9243 100644
|--- a/src/etc/inc/captiveportal.inc+++ b/src/etc/inc/captiveportal.inc Patching file etc/inc/captiveportal.inc using Plan A... Hunk #1 succeeded at 235. Hunk #2 succeeded at 573 (offset -27 lines). Hunk #3 succeeded at 618 (offset -27 lines). Hunk #4 succeeded at 670 (offset -27 lines). Hunk #5 succeeded at 716 (offset -27 lines). Hunk #6 succeeded at 724 (offset -27 lines). Hunk #7 succeeded at 755 (offset -27 lines). Hunk #8 succeeded at 1298 (offset -4 lines). Hunk #9 succeeded at 1406 (offset -27 lines). Hunk #10 succeeded at 1912 (offset -4 lines). Hunk #11 succeeded at 1906 (offset -27 lines). Hunk #12 succeeded at 1965 (offset -4 lines). Hunk #13 succeeded at 1953 (offset -27 lines). Hunk #14 succeeded at 1987 (offset -4 lines). Hunk #15 succeeded at 1975 (offset -27 lines). Hunk #16 succeeded at 2421 (offset -17 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc
|index 6d6f33161cb..7e4deb8b326 100644
|--- a/src/etc/inc/system.inc+++ b/src/etc/inc/system.inc Patching file etc/inc/system.inc using Plan A... Hunk #1 succeeded at 2126 with fuzz 2 (offset 6 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/src/usr/local/captiveportal/index.php b/src/usr/local/captiveportal/index.php
|index d5459a80976..44bf0879b32 100644
|--- a/src/usr/local/captiveportal/index.php+++ b/src/usr/local/captiveportal/index.php Patching file usr/local/captiveportal/index.php using Plan A... Hunk #1 succeeded at 198. done -
@andresense 2.4.4-RELEASE?
The patch is designed to be applied to the 2.4.4-p3
-
@free4 Sorry
The version I'm using is 2.4.4-p3
-
@Gertjan said in Pfsense, No internet when it is said "You are connected".:
https://github.com/pfsense/pfsense/compare/RELENG_2_4_4...Augustin-FL:fix-reconfig-for-2-4-4.diff
I just installed that patch on my Home pfSense :
Fill in the minimal patch info : a description and the URL - nothing more :
The hit the Save at the bottom of the page.
Do what must be done : Hit Fetch.
The patch is loaded :
Now hit Test :
As you can see : the pachh can be applied.
So, hit Apply.
This works for a clean :
If it can't be applied : one or more files are NOT original 2.4.4-p3 .....
-
Sorry for the delay in replying
I solved the problem in another way. I created a script that inserted users back into the portal at boot time.
Thanks for the feedback
-
So, as this issue becomes a nightmare for us and wasn't fixing by any patch :(
now, what the case with 2.4.5 ? I can hit the same issue after every reboot.
I can't apply the patch to 2.4.5, and not sure what to do now to keep using the pfsense CP !!Any help please?
Thanks -
Try:
https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diffThat will apply against 2.4.5 and looks exactly the same patch. I have no way to test it here though right now.
Steve
-
@stephenw10 said in Pfsense, No internet when it is said "You are connected".:
Try:
https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diffThat will apply against 2.4.5 and looks exactly the same patch. I have no way to test it here though right now.
Steve
I'm still using this patch as of today - now running 2.4.5. - it auto applied itself right after updating.
The patch applies well because the files changed by the patch were not modified since 2.4.4-p3.@michaeleino said in Pfsense, No internet when it is said "You are connected".:
I can't apply the patch to 2.4.5,
Make sure the original files (edit : 2.4.4-p3 or 2.4.5) are in place.
@michaeleino said in Pfsense, No internet when it is said "You are connected".:
and not sure what to do now to keep using the pfsense CP !!
Don't forget the most easy solution : don't edit portal settings while users are connected.
And if you have to edit settings, disconnect them all right afterwards. -
well,
thanks Steve, Gertjan
now I can patch 2.4.5,
Now should I change any settings in the CP ?
as after each reboot, I still hit the "You are connected" :(@Gertjan said in Pfsense, No internet when it is said "You are connected".:
Don't forget the most easy solution : don't edit portal settings while users are connected.
And if you have to edit settings, disconnect them all right afterwards.the issue doesn't happen if i modify the CP configuration... it happens after every reboot.
-
@michaeleino said in Pfsense, No internet when it is said "You are connected".:
as after each reboot, I still hit the "You are connected" :(
The patch enforces that the database with connected users is deleted at boot time.
The related pipe-rule list is also deleted.
See /etc/inc/system.inc - lines 21345-2137 after the patch is applied.The GUI Status > Captive Portal > YOURZONE should be empty after a pfSense rebooting.
Right ?Now, you enter a user on the portal.
You are connected - right ? The user shows up in the GUI Status > Captive Portal > YOURZONE, right ?
Is that the moment you see You are connected", right after identification ? -
Hello, i was just unable to reboot the firewall since last time :)
the issue has been magically gone, the captive portal status page is empty after reboot, so the users is able to re-authenticate again.Hope this patch be included in the next release!
Thanks all -
Hi All!
got the magic...
reboot/halt from pfsense GUI is OK,
The GUI Status > Captive Portal > ZONE is empty after a pfSense rebooting.but reboot/shutdown from acpi is NOT OK
The GUI Status > Captive Portal > Old auth sessions are still there... very weird, as acpi should trigger the same runtime cycle!VM hosted on bhyve/freenas 11.3U2.1
Virtual CPUs:8
Memory Size:8.00 GiB
Boot Loader Type:UEFI
System Clock:UTCthe issue originally, when we suffer a power outage and the UPS will not survive anymore, the Host OS is doing a clean shutdown for VMs then to itself, and after power return everything should come back again...
except this captive portal :(any help ? Does it clean sessions on startup or shutoff ?
-
@michaeleino said in Pfsense, No internet when it is said "You are connected".:
the Host OS is doing a clean shutdown for VMs then to itself,
The question is : is it halting ?
See /etc/inc/system.inc - aroujd lin e2094 : on system_halt() system_reboot_cleanup() is called.
An that function, a couple of line further bellow, will delete the portal session database(s).It plays also the shutdown notification sound
mwexec("/usr/local/bin/beep.sh stop");If the host puts the VM in some sort of suspended or sleep mode, all this might no happen.
Check the logs if it really shuts down.Put a log line in the function system_reboot_cleanup() so you can check if it is reached, if the database is wiped, etc.
-
Hi all!
I have tried to add echo message inside each function, to see it while execution .. but i can't see them on any shutdown procedure neither "acpi" nor "pfsense halt"
for ex:function system_halt() { global $g; echo "Hey, This is a system halting process"; system_reboot_cleanup(); mwexec("/usr/bin/nohup /etc/rc.halt > /dev/null 2>&1 &"); }should I redirect it to console like this or what?
>/dev/console
something to note, "acpi" or "pfsense halt" is showing this on the console:
and pfsense is starting cleanly after both shutdowns ... can we execute this cleanup during Bootup ? is it better idea ?
