Some of the pages were considered outdated, redundant, or misplaced and are still being manually organized and that might be one of them. We are still working on cleaning up everything from the move. Until then you may want to use the web archive: https://web.archive.org/web/20171205175929/https://doc.pfsense.org/index.php/PfSense_on_Watchguard_Firebox
Sure, the option is under ACLs in squid. If users do not want to use the WPAD (auto config proxy) then they should manually enter in the proxy settings in internet options (if using windows). Do not rely on SSL/MITM Mode splice all for all 443 traffic or else you will get connection errors. That is if you are blocking port 80 and 443 and forcing users to use the proxy.
Here is a .zip of 64bit scripts that have been updated for the new naming format. I used them to install 3.2.0 fresh on a 2.4.3_1 install of pfSense but I extracted the TAR and re-compressed it as a gz first, since I didn't want to mess with changing the un-compress command.
NOTE: THIS WILL CREATE A FILE THAT SAYS YOU ACCEPT TS'S LICENSE!
Please read and understand the license terms before using this script, it auto-generates a "License accepted" file.
We're in the process of changing the wiki over to a different setup that will make it easier to take contributions from anyone without having to worry about spam. We'll post more about that soon.
In the meantime, you can write something up as a forum post in the appropriate board and people can find it that way.
Thank you, jimp. I will follow your suggestions.
I've got a sg-4860 … the process doesn't work for me at all.
the setenv command doesn't work if I run it from the command shell - error message is "sh: setenv: not found"
I add setenv to /root/.tcshrc then save the file, reboot and the setenv line has disappeared
I have to admit to being inexperienced with bsd, I have run linux for quite a few years now …. can anyone point me in the right direction please? BTW, I have o/s 2.4.2_1
Reviving this older thread to ask two –almost certainly noob'ish --questions:
is it possible to find the pre-compiled kernel modules anywhere (IE: anywhere trusted)?
are kernel modules platform-specific? I assume so
2.5) assuming so - anyone know of a place to find them for the ARM chip used in the SG-1000? Or...
2.5.5) are there virtual platforms (like virtual box) where one could download the ARM compatible source for the kernel and compile the modules oneself?
edited to add - resolved for now :)
Got some good insight here https://www.reddit.com/r/PFSENSE/comments/7xtyo0/any_way_to_tether_an_iphone_to_a_sg1000_looking/
While I got gung-ho to learn some new BSD skills, it seems like the best move is to wait for a bit to see if this module makes it way into a stable build for the ARM platform.
Thanks everyone for the work you are doing!
This is broken. As soon as you background the openconnect process, there's a race condition where the interface may not be up yet when you attempt to rename it. Having a central script to do half of this stuff goes against the design principles of openconnect. This should be rewritten as a set of hook scripts in /etc/vpnc, particularly the IF renaming chunk.
Or, really, vpnc-script itself should be written to detect the presence of pfSense, and understand that tun devices need to be renamed.
Was always fighting with this "-x" stuff, which was added especially for "pfSense" or some one from the pfSense team was asking for it back then if memory serves me well.
Anyway : ipfw rules are looking better now … tables have names now : good !
After some reading I understood that OpenSSL does have AES-NI built in and it will try to use it when available on chip, it doesn't need any kernel module to be loaded.
I believe the documentation should include the above info, and clarify possible scenarios on Advanced - Miscellaneous - Cryptographic Hardware settings, for example:
With AES-NI chip
When "none" or "AES-NI CPU": OpenVPN will use OpenSSL built-in AES-NI support.
When "BSD cryptodev": OpenVPN will use ASE-NI trough BSD Cryptodev.
… that is if I actually understood correctly.
Thanks so much for bringing this up and posting it. Setting this up today for the first time (on 2.3.4-RELEASE-p1), I had the same hard time trying to figure out why deleting the variable or setting the value to yes/no wouldn't work. After some Googling I found this post, set it to 0 and now I'm getting my Config+RRD data in full.
This means that I am not alone with this issue and also that the solution I found works for more than one.
Jim, did you see this?
I followed this tutorial and have everything working including CID and remote DVR. The PFSense router is connected to the ONT with ethernet and the Actiontec is connected to the PFSense on it's own ethernet port separate from my LAN.
Any luck on finding a provider that will activate their network through a SIM card? We purchased a similar build that has a SIM card slot that I'd love to activate as a failover, but ran in to the same issue where Verizon won't talk to me if it doesn't have a IMEI number. I'm going to try a few different providers to see if I have any other luck, but I'd love to hear what you have found in your searching! This would be such a cool option if I could get it to work.
You could also look into this:
BTW, johnpoz, its grown immensely since you last saw it as well, checkout the static demo:
If your primary concern is that the hashes are on the same server as the files, then that isn't always the case: When you download a file from pfsense.org using the download selector it shows you the hash on that page, served from the web server and not the same server that is sending you the img.gz/iso.gz. That should be sufficient verification for the majority of cases.
There was one SSD which shall remain nameless, when TRIM was enabled it suffered complete filesystem failures 100% every time.
We aren't going to keep track of other vendor's hardware with any risk like that. If someone wants to track down the info, fine, but the moment we put something like that up and someone loses data it'll be on us. If someone wants to put together some info in a post, perhaps a sticky would be OK, but not on the wiki.
Without commenting on the architecture and reasons for it, your problem will be that Internal pfSense WAN will block traffic originating from outside it (i.e. trying to ping from external back to 192.168.20.2).
At the VM console of Internal pfSense you can use the developer shell and enableallowallwan (its called something like that). Then you can get into the webGUI from upstream of WAN and sort out a more restricted set of rules for access to the Internal pfSense webGUI from upstream.
I gave you the same answer last week on the other forum. Anyway… ::)
Oh, I thought you were referring to something else over there. You had mentioned ipfw and MAC based filtering causing multiple passes through the stack, and that confused me. So, are you saying that enabling bridging causes ipfw rules to be created and all traffic getting passed through ipfw AND pf even if there's only L3 rules involved?
If so, that'd be a bit more overhead than I thought!
Similar to your "What is wrong with bridging?" question, I would ask you "What is wrong with routing?"
In a general sense, or in the specific case I referenced?
For my specific, the issue with routing is that IPv4 network broadcasts aren't routed.