"Waiting for your comments."

I have a comment - use something that is current and supported..  2.0.1 released end of 2011, shoot its not even the latest version in that line. 2.0.3 was..  The version of freebsd it was on 8.1 was EOL July 31, 2012..

The OLDEST pfsense you could be running is 2.2.6, with even the resemblance somewhat close to being in the area of dragging your feet..

Ashima has the fix.  I tried a bunch of stuff to get this fixed AND NONE OF IT WORKED until I patched the boot loader!

https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING

"The kern.ipc.somaxconn sysctl limits the size of the listen queue for accepting new TCP connections. The default value of 128 is typically too low for robust handling of new connections in a heavily loaded web server environment. For such environments, we recommend increasing this value to 1024 or higher. The service daemon may itself limit the listen queue size (e.g. sendmail(8), apache) but will often have a directive in its configuration file to adjust the queue size up. Larger listen queues also do a better job of fending off denial of service attacks."

Thank you Ashima!  I gave you a thank you bump too…if that matters, 5 gold stars, best in class, grade A <-- whatever nice things you can think of.

This was driving me friggin crazy!!!  :-)

I seem to have found my solution

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

Step 9 seems to have done the trick:

Check Clear invalid DF bits instead of dropping the packets on System > Advanced, Firewall/NAT tab

Jason

@motific:

Just start with the basic tests - HTTP/500 is an error in the code of the page you're accessing rather than a communication issue.

Can you reach the page that generates the http 500 response from a browser?

Since there's only 1 machine behind squid right now, what happens if you bypass/disable them (first squidguard, then squid)…

does kodi work then? can you use curl to pull down the zip file? can you get to the URL from a browser?

Once you have those answers it ill narrow down what you need to look at next and you should be able to follow the path logically to get to the root of the problem.

Also, why do you believe you need a DMZ for those devices?

I will try this  and  get back to you.

Really the best thing is to set up your hardware like this:-

Modem - pfSense - Lan & wireless router

Personally, I agree with JKnott - unless you have a very good reason for keeping DHCP/DNS on the Linksys then you'd be better off keeping pfSense visible and reconfiguring the Linksys as a dumb access point.  Giving the Linksys less work to do helps mitigate some of the many security holes present in SoHo routers.  Once set up, you can also pretty much forget about it apart from changing the wifi key every so often.  Since the main interface for what's going on in your network will be pfSense it doesn't make a great deal of sense to separate the responsibilities.

That should be ok.
Use "machine.mydomain.com" in your mail client and you'll be fine from the 'inside'.

Your domain registrar should also contain "machine.mydomain.com" and point to your WAN IP, where you forward your mail ports to your "machine".

^^^^
That's impossible to answer without knowing the hardware.  I suppose really anemic hardware might have problems.

Oh my Gawd dude…  You stated you were going here

I would just go directly to the host/service on the LAN: https://nas1:port.

That is not a FQDN so how could you be going to your wan IP…  And you stated your were just directly going to the host..

Yes if your going to your WAN your going to get reflected back in via your proxy or your nat... Dont DO THAT....  Just setup a host override so s1.nas1.domain.net or whatever fqdn you want to hit resturns the correct rfc1918 address..

What are you putting in your browser when your on your PC behind pfsense??  What does it return for an an IP...

In your reverse proxy setup your putting in what??  Some other fqdn or hostname - how is pfsense resolve that, some other dns that you have setup??  If pfsense forwards or resolves a FQDN somewhere and it returns rfc1918 then that is a rebind..

How is the OpenVPN server supposed to know which server to send the traffic to?

Post your rules. Be sure it isn't TCP-only.

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

I found my solution, FYI: https://serverfault.com/questions/886071/pfsense-load-balancer-access-virtual-server-from-lan

@Gertjan:

something's up with your system.

I think you are probably correct. Not sure, but I suspect that an incorrect password wouldn’t result in a terminated connection but rather an error about invalid password and a prompt for another one. I also can’t receive Growl notifications on the same system even though pfSense shows that they are being sent successfully.

I’ve installed a public key on the system and we’ll see how that works. So far no problems.

I installed a shellcmd

php -r 'require_once("shaper.inc"); require_once("filter.inc"); interface_ppps_configure('opt2');'

to fix this issue.

Replace opt2 with the optx you are using.

What cron jobs do you have running? (can install cron package to look that up) Seems like one of them is creating a little output that cron wants to mail..

Can you perhaps try running them one by one from a ssh console manually and see if any produce 'output' ?

Quick update: I manage to do what I was looking for using OpenVPN server as a gateway for the tunnels. and doing NAT with pfsense public IP address. but still have some unanswered questions.

I don't see how Site B can connect via OpenVPN to Site A unless Site A has an OpenVPN interface?How did you build these connections, with wizard or manually?

Manually. Apparently pf sense does create the tunnel without the interface. Obviously there's no traffic without it, but since I saw the status of the tunnel up, I mistakenly thought that was enough. So all sites has interface and there's traffic in it.

2. Yes, the general technique is to specify all the possible external networks the OpenVPN server will pass to various clients (the "Remote Networks" in the server's config).
Then you specify which of that set will be routed to each client in the client's specific CSO.  Obviously it works best if there's no possible overlap, thus my question 3.

This one I still have some doubts. For example. Stie B-D are regular clients. they only need access to certain services to perform their duties. So I believe is ok that they all share the same routes and rules for them. Now since there's just one site where the admins will be (Site E), I created another vpn server on site A as remote access since we could be at the office, or working remotely, without all the restrictions needed for the rest of the sites.

One thing its annoying me a little is the following:
If Site B-D share the same private ip block (ie.10.10.10.0/24) I could access pfsense webgui on Site A using its tunnel ip address (ie. 10.10.10.1). Obviously this can't happen, so I just restricted with a rule, and they can't see each other cause im using net30 topology. But from Site E (the admins) I have any-any rule at the tunnel's interface and Im not able to ping it using site E tunnel's ip. (10.10.20.1) I still can access all site's pfsense webgui from the admin site via lan ip or the other tunnel ip, but not the actual tunnel ip where im connected to. And I can see the servers behind it.  this is not too much of a concern for me. But at the same time, I want to understand why I can't ping the tunnel's gateway, even thought the interface has any-any rule.

Not currently, the certificates are not in a section that can be restored on their own.

We need more information to make some conclusions.
I think you need to configure two interfaces the one you have already configured (WAN DHCP) and next you should go to    Interfaces>Interface Assignments and then to PPPs tab, add new PPPoE, select same physical interface you have used on WAN and configure all you have there with information provided by ISP, save, go back to Interface Assignments tab, select your newly created PPPoE in drop-down menu and add new interface, name it whatever you want and go to    Interfaces->"younewlycreatedinterfacename", enable it and then check if it is working already and IP already received, if it does not, then you need really "hack" mpd config. :(
If it's not acceptable for you then you need to create feature request for PPPoE IP configuration via GUI.  ::)