Sounds like an OpenVPN setup issue. Perhaps try over in the OpenVPN forum with some more details of your setup.

It only restores the section you request.

@jbhowlesr: I would suggest that if you send a request to be delisted from the blocked list, that you include some data about your network to include any finding of infected machine, hijacks etc and exactly what you did to fix the problem and steps taken to ensure it doesn't happen again. Typically when providing this level of detail, companies who list spam offenders will give extra consideration since you put in the effort on your end to solve any issue. Considering working with them to get off the list. Otherwise, if you only ask to be removed with as little or few words as possible; your request will sound less than genuine. The problem in this case has nothing to with sending spam. The blacklist in question is for sites with botched MX records that fail to for example to provide A records for hosts listed in the MX records for the domain.

Hy! Only thing I know: https://forum.pfsense.org/index.php?topic=99938.msg556842#msg556842 …so: apparently not at that time...

When you ssh from pfSense to a remote system over an IPsec tunnel, the connection is sourced from the firewall itself. Your IPsec tunnel has a phase2 entry that declares certain traffic interesting to IPsec and thus "routed" over the tunnel. Try using the -b IP-Address option to ssh with IP-address being an address on the firewall that is included in the phase 2 entry. If you have a LAN interface of 192.168.1.1/24 and a remote network of 172.16.1.1/24 and a phase 2 between those networks try ssh -b 192.168.1.1 172.16.1.1 I do not know if this will work. I have never tried it. I generally have a management workstation on the network that is included in the IPsec Phase 2 entries from which I do these things. Doing it from the firewall can be problematic. Linux and FreeBSD are free. So is XenServer and ESXi.

We don't test each release on all available hardware.  That would be a LOT of work.

I'm pretty sure that RRD still handles the logging side of the monitoring graphs… it's just that it doesn't handle the graphing side of it anymore. I think an external service would be the best way to go, and might provide more flexibility in the data it gives. vnstat is a package that many used under earlier versions of pfSense. It's still under construction for 2.3, but many are awaiting its return. Lots of users who have ISPs with data limits use it to keep track of their usage. The vnstat service that does the monitoring can be installed via pkg in the shell... you just won't have a pretty GUI to show graphs.

@Phereal: Hi, solved this issue by killing the PHP-FPM process by selecting point "16) Restart PHP-FPM" in the ssh menu. Afterwards navigate directly to the address -> https://<ip_address:port>/system_update_settings.php and disable the automatic dashboard auto-update check. Save settings and return to the dashboard. Now again kill the PHP-FPM process via ssh and reload the page. Afterwards remove the "traffic-graph" widget from the dashboard. Reboot the system to verify your changes. Now everything should working fine again. Seems like an PHP-module causing trouble. EDIT: other posts mention problems with some widgets [IP-SEC], if your problems remain, the solution might be to remove all your widgets and then perform a restart. Afterwards it might be possible to add the widgets again.</ip_address:port> Had the same issues and followed the solution proposed by Phereal and it worked. Just wanted to say that if at some point you feel your pfsense is stuck just use 16 on console (obviously not when you will be saving your settings). Thx,

The real issue is getting your untagged traffic off VLAN1. Or at least only using VLAN1 for trusted traffic. Some switches treat VLAN1 as special. Some can only be managed on VLAN1. And if you are going to do that, you might as well just tag it. Tagged and untagged traffic on trunk ports can be problematic as well. Many people try to "tag" VLAN1. That's an oxymoron. It's messy so why do it?

Argh, I just found out that I myself put the immutable flag on for this config file. After turning this off, everything behaves again as expected…..

I can confirm that this works. Just updated to 2.3, and had the same problem, so this is apparently a long-running issue.

@shak2300: I will let you know my result when i get off from work So what were the results if I may ask? ;)

Thanks so much! Somehow the package escaped my quick inspection of available packages. [image: notices.png] [image: notices.png_thumb]

Same problem, and I never fix it, every time I change globals.inc it make some permission errors. Can anyone help us to grant right permisions again ?

@vbentley: Do you have a public or private IP address on your WAN interface now? It is usual to have to configure the ADSL router to change from routing to bridging before PPPoE will work. I now have a public IP on the WAN interface, apparently these devices are configured in 'DHCP Passthrough' mode so it acts as a modem and then passes the connection specific configuration (IP, GW, DNS etc) through to the 'cable' router via DHCP.