Yes - everything is working for all clients on LAN - I am just not able to open the HTTP or HTTPS on the Comcast box.

validate the fqdn your trying to go to resolves to what its suppose to resolve too server.domain.local simple ping, nslookup, dig, drill whatever your fav dns query tool is so you can see the answer.  Ping works in a pinch to what the name resolves too.  Be it answers or not.

Thanks. The install, then upgrade to 2.3_1 went off without a hitch. I previously had pfSense installed onto a very, very old and cheap SSD and it ran without issue for 2 years, right up until the drive failed. Then I switched to Live CD, which was just fine for my use, then that was discontinued, so I tried nano, that was miserable. I'll see how long this cheap SanDisk SSD lasts. I've had a lot of their flash media over the years, and nothing has ever failed. Still even use my 15 year-old 256 MB flash drive for transferring small files.

@johnpoz: You mean you didn't have to leave it off and unplugged from power and ethernet for 15 minutes??  You don't freaking say.. wTF… And what you don't have UPnP enabled -- no shit, clearly mister expert was sure that xbox and ps4 both require UPnP to even get on the internet..  Just flabbergasted he didn't have clue one to what he was talking about ;) heheheh LOL!

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]