I'm sittin' on the dock of the bay
Watchin' the tide, scroll away
I'm sittin' on the dock of the bay
Wastin' time
Songwriters: Otis Redding / asdffdsa6131

yepp, that I've been using. Also discovered the apple configurator that seems interesting. I will come back after I recreate the whole ipsec stuff, as i tried few of them and need to take it from scratch.

Should not need anything special on the firewall, other than static outbound on UDP 500 which is the default configuration. Your phone should make an OUTBOUND IPsec connection and do all the wifi calling bits over that.

Loading the configuration from USB during the installer requires using DOS/FAT32 formatted USB media, thus the Windows-style path in that specific instance. It's the odd one, otherwise we prefer to use UNIX-style paths.

I was looking the other day. Seems to have gone away.

Id just ask as you go.

Sure. If you'd like something at a higher resolution let me know.

It's sourced in Omnigraffle so I could probably do 600 dpi PDF or something.

We do not control that log output, it's from ISC DHCPD, they may have documentation for it that you can use.

@jimp:

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 try to update it and get better.

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

thank you

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.

Can you please submit a ticket to our support? https://customercare.netgate.com/

Humm.
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 !

You should see a link as soon as you login to the pfSense Portal.

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.

Cheers

fixed…

@Higgiefresh:

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?

Best regards
Dan Lundqvist
Stockholm, Sweden

Actually I would like to help with documentation :)

–-
akita inu
dog photos

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.
https://nguvu.org/pfsense/verizon/pfsense-verizon/

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:

https://forum.pfsense.org/index.php?topic=120972.0

BTW, johnpoz, its grown immensely since you last saw it as well, checkout the static demo:
http://black-knights.org/pfmonitor/demo/index.php?task=home

Thanks
Get

Thanks, it should be fixed now.

I had pointed it to a saved 2.3.3 report that I deleted yesterday when cleaning up things post-release.

there is no "free' book.

https://doc.pfsense.org/index.php/Main_Page

I should point out that I'm happy to be proven wrong on this, and hopefully this post will show up on a few searches in the future for others that are having a similar issue.  :)

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.

Depends on what you look for in the book, but most of the content is outdated.
Better sources:
-> https://doc.pfsense.org/index.php/Main_Page
-> the new pdf / online book (requires subscription)

@Nullity:

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!

@Nullity:

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.

Thanks for pointing out and fixing, looks good to me!

I've pushed a fix for that or 2.3.2-devel snapshots