squid is http proxy, while I am guessing you were using Srelay on openwrt which is socks - completely different. There is a Srelay for freebsd - if you really want support you could install the freebsd package - ask to get it added to the pfsense repo. http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/srelay-0.4.8b6.txz

@phil.davis: The only reason I went with the second method is because the screenshot matched the version of pfSense I'm using so I figured it was the way to do it now? The second method does mean that if someone tries to (or accidentally) sets their client to use some other DNS, that it will be "silently" redirected to use pfSense anyway. So I guess that is convenient for clients. The first method makes clients not work if they do not "obey the rules". I guess it depends if you are a kind-hearted soul or "the network admin from hell". Hehe… yah... I get it now, I think I'll stick with the kinder option for the time being ;)

More user friendly to use screen pkg install -y screen rehash screen /dev/cuaU0.3 9600

@kpa: I agree that the checkmark should have the same function regardless of the interface type, be it enabling/disabling the interface completely or just enabling filtering/NAT on the interface. Neither the GUI or the existing documentation give you any hints of different semantics of the checkmark's function depending on the type of interface now. On Reddit I discussed in more detail other problems of the "pfSense Interfaces" architecture, such as different meanings of "IPvX Configuration Type" depending on the corresponding FreeBSD interface and on the selected field value itself. Right now pretty much nothing is consistent, it's a bunch of hacks to make common (and less than common to some extent) scenarios work. I hope they will fix it soon. It is, imho, one of the worst downsides of pfSense in comparison with major commercial solutions (e.g. Cisco).

Looks like you have 512MiB of memory and it tried to allocate ~64MiB but there was not enough free. Add more memory? Possibly disable additional services that you may have enabled, like Snort or squid.

@jimp: The login beep is not done with a call to the beep command, but a byproduct of that login log message being printed to the console. Did you password protect the console, perhaps? I don't think that would suppress the message but it's the only thing I can think of that might be even remotely relevant. Beep still works fine at login on the two boxes I have here which still have a speaker. I had the same problem.  Deselecting Password protect the console menu in System → Advanced → Admin Access → Console Options resolved it for me on pfSense 2.3.4.

Fantastic workaround!  Thanks for the idea.

@iska: @jimp: https://doc.pfsense.org/index.php/Why_was_FreeBSD_chosen_instead_of_another_OS I know OpenBSD is aimed for maximum security, and FreeBSD is for maximum performance, while PfSense is for security or firewall/router, why don't they chose OpenBSD. Because Theo.

Ok, if you insist, and will assume the liability  :) "Put it" at "/usr/local/www"  (or in a "new directory/folder"  /usr/local/www/XXXX )

Thank you, that did the trick.

I agree with you - but you stated this "they don't understand the underlying plumbing going on." So unless you do, you have no idea what they are doing - right?  You say it works when both on the same lan.. So look to see what is going on when on the lan, then you can make your firewall rules to allow this, etc. You for sure would not need to do any sort of natting here - since local networks to pfsense do not nat between each other.

Depends what is more important to you, you say it not too slow. Keep in mind that the vast majority of net traffic not static any more - most everything is dynamic.  So your cache is not going to buy you much.. Browsers cache most of their own static stuff anyway. Using explicit vs transparent would be better, since now your not forwarding all your 80 traffic to your proxy port and just hitting the proxy port directl.  Also what hardware are you running this on?  How exactly are you benchmarking your slowdown? Have your users actually complained about the performance hit?

I have no experience with NtopNG - anyone else feel free to jump in…

I am not sure this is the correct answer but I would test: Define a DMZ with the public pool. Add a gateway with  185.81.117.97 in pfsense in the rules allowing outbound traffic from the DMZ select in the advance option the gateway you have defined above. It should work but it might not be the best answer.

no.. i don't want assign a public ip behind the pfsense . i want simulate isp's reaction  how i assign an ip block over a line with a pfsense (isp simulator). there is end of this line my pfsense fw simulater (and then it is going to use 1:1 nat - this part is not problem , i will handle) the problem is how can i simulate isp's reaction (assign an ip block to my customer :) )

Wow. I don't know what is wrong. I spent several hours trying to get the CD to work for rebuilding the firewall and nothing worked. I used a USB CD Drive to burn and read, but the boot up took forever. I transferred the ISO to my main computer and burned it on the internal CD Drive. This made it better. The firewall doesn't have a CD-ROM, but it is a computer so I hooked one up to the SATA port and it would not load the CD. So I went back to the USB CD-ROM and it booted, right up until it detected the USB CD-ROM then errors with mount issues (error 19 or 16, don't remember). I don't remember it being this hard to install pfSense. I had several issues just getting a working copy of the software from the sites (ended up downloading it on my Linux laptop and the hashes matched finally). In case you want to try calling me stupid or something for not using the USB installer, I already tried that. It was my first set of attempts before going to the CD-ROM. The BIOS doesn't detect the USB Boot Drive.

Ok 'default_backend majesty' is probably the reason it ends up there.. could be that none of the acl's matched.. The current acl might not always match.: acl        OWA  req.ssl_sni -i mail.mydomian.com Could you add also a: acl        OWA  req.ssl_sni -i mail.mydomian.com:443 So including the port? that might solve something.. p.s. it seems you have to many 'default_backend' configured anyhow. but if the acl's pick up the traffic you shouldnt end up on majesty. (when requesting mail.mydomian.com)