Pfsense, No internet when it is said "You are connected".
-
@johnpoz said in Pfsense, No internet when it is said "You are connected".:
Well if you had dicked with outbound nat and turned if off automatic, then yeah you going to have all kinds of problems!! With no outbound nat..
Yeah, I had to switch to Manual Outbound NAT couple of yrs. ego, which I completely forgotten about it. Wanted to mentioned here just in case anyone else did the same mistake as me.
-S
-
@MacUsers said in Pfsense, No internet when it is said "You are connected".:
Yeah, I had to switch to Manual Outbound NAT couple of yrs. ego
Highly unlikely to be honest... Why did you have to switch to manual exactly? Because some vpn service guide said to? You were routing some network behind pfsense that didn't need nat at all?
Hybrid is normally better choice when you need to do something out of norm with outbound nat for some vpn client connection your routing traffic through.
-
@johnpoz, I'm actually now trying to think why did I do that. I don't use any external VPN service but that time I was new to pfSense and probably was following some of the guides.
Actually trying to clean up the collected junks from my config. So you saying just simply switch to Hybrid and remove all of the manually added rules?-S
-
You should be able to switch to just full auto.. If your not using a vpn connection to some vpn service - I to be honest off the top of my head can not think of why you would not just be full auto for outbound nat..
Do you have more than 1 wan connection, where you would want to determine which clients get natted to which wan?
Really if you are just plain jane out of the box type of setup, wan and lan(s) on your pfsense then yeah auto is all that would be needed, and is default out of the box.
Even if you were doing downstream router with transit to pfsense, etc. auto works there too, etc. It really should be rare that you need to switch from auto to hybrid, or even rarer manual.. There would have to be something unique to your network.
-
Yeah if you need to add custom rules switching to hybrid is generally better as you still auto rules to avoid exactly this sort of thing.
If it was a long while back there may not have been the hybrid mode option. At one time there was just auto or manual.Steve
-
@stephenw10 said in Pfsense, No internet when it is said "You are connected".:
At one time there was just auto or manual.
And what version was that, 1, 2.0 ?? I do not recall that at all.
-
It was added in 2.2 so it would have to be pretty old install. But possible!
-
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
