You can use Squid with Lightsquid to get a list of sites like that per internal IP.

Steve

Have you tried the commands in the "Update Troubleshooting" section of the release blog post(s)?

https://www.netgate.com/blog/pfsense-2-4-3-release-p1-and-2-3-5-release-p2-now-available.html

Okay thank you

@johnpoz said in One Update Time Per Day:

Cron package allows you to be very specific about when jobs run..

Okay, thank you, Johnpoz, I'll try that package.

Thank you for the replies. I was actually checking from my LAN. When I tried from outside, Firefox timed out; it wasn't able to connect.

Well, you might be closer to a solution as you think.
These Draytek router have Radius support, so, setup a centralized database - the one that among other captures the MAC - and your have what you want.
If the Draytel will consult this data base before login (on another portal device), that I don't know.

@harvy66 said in Disk Usage/ 100%:

I didn't know you could install pfSense on less than 1GiB of storage.

Missed that...per https://www.pfsense.org/products/ the requirement is a 1 GB drive, and "Note the minimum requirements are not suitable for all environments." I just looked at an SG-3100 that is not running any packages and it is using 13% of 7 GiB, or per quick math, is using 910 MiB. So yeah 908 MiB is probably too small considering there should be space for updates and logs.

@jknott said in New User... Slow Upload Speed:

@harvy66 said in New User... Slow Upload Speed:

My cats don't chew on braided cables

Are they named CAT 5, CAT 6 etc.? :-)

Coincidentally, we're one shy of our 7th cat... Even the braided cables will no longer be safe. Colored split-loom it is. They don't chew on split-loom, but I hate how it looks.

You can define the length of the beep, you can try to find a length that fits your needs!

The best thing to do is log to a remote log server.

If adjusting the number of log entries visible using the filter in that view is insufficient, you can use this command to save all IPsec logs:

clog /var/log/ipsec.log > /tmp/ipsec.log.txt

Execute that in Diagnostics > System Command

Then, on that same page, Download File /tmp/ipsec.log.txt

The logs kept on the firewall are circular, however, meaning old entries are overwritten by newer entries. The amount of logging kept is set in Status > System Logs, Settings, Log file size (Bytes). What you can do there depends on your disk size. I have mine set to 50000000 (50MB) on a system with a 30GB mSATA and it is still 90% free (about 3GB used Disk space currently used by log files is: 1.2G Remaining disk space for log files: 22G). You have to reset all logs further down on that page for this to take effect.

You can save a lot of the system state in a status output file. That is taken by navigating to https://firewall.address/status.php and downoading the resulting file. On busy firewalls that might take a moment to run. And for IPsec issues the logs saved there are often insufficient so the status output should be coupled with an ipsec.log.txt file as described above.

If you have more than one tunnel it is often beneficial to get the conXXXX number of the tunnel from ipsec statusall so you can filter on it (and filter out other tunnel logs) using grep, etc.

The cable from pfsense should be plugged into the "Internet" connection on the Linksys. A recommendation is to make sure the network name (ssid) and password in the Linksys is set to your preference before setting the type of internet connection to bridge.

Not sure what kind of Linksys router you have, but if it is any of the consumer products, you should log in to the interface of the linksys, go to "Connectivity" and then "Internet Setting". In that particular menu, you can edit the "Type of internet connection" from 'DHCP' to 'Bridge mode'. This mode disables everything except the wireless access point.

I have just done the same (setting up pfsense and re-configuring my linksys router to be an access point and switch only).

@jimp said in Pfsense restarting by itself - Fatal trap 12: page fault while in kernel mode:

ESX

Thanks for the information, I'll analyze this

There is no direct relationship between VIPs and aliases.

The aliases collect addresses to use in firewall/NAT rules and so on.

VIPs setup alternate addresses on the interface, for example to inform an upstream router on the same segment that the firewall will handle traffic for that address. See https://www.netgate.com/docs/pfsense/firewall/virtual-ip-address-feature-comparison.html

Greetings . Here is my Update.

I landed up replacing the HDD, All is now back up and running. Thank you once again.

Update: looks like that did the trick! My dhcp-lease-time is currently set for 7200 (so a renewal happens every hour) and so far it hasn't dropped the connection.

Been w/ pfSense since v2 went into beta. Sometimes I think I misunderstand this latest pfSense universe.

This thread helps a bit.

@thenarc Thanks. This is very useful information too. For now I have the configuration which was needed.

@johnpoz said in pfsense seems to delay loading websites after moving server:

Resolving is almost always going to be better option vs forwarding.

Your trying to say that is a blanket statement?

No I do not agree at all. I clearly put used the word "almost" on purpose. You make some very good points - which should of been in your first point vs telling the user to disable resolver and use forwarder without any actual info from the OP to their environment.

That is the point that rubbed me the wrong way to be honest. It screamed lack of understanding to me..

Your example of root server being 50-100 ms away as your saying reason for resolver to be "slower" points to not actually understanding how a resolver works.

The root only has to be queried to find the list of authoritative ns for the tld. Once that has gotten they ae all cached. Will not have to query for them again until the ttl expires. Then with prefetch user may never see this delay again.

Same goes for every ns down the tree to get to the authoritative ns for the domain in question.

My point was "overall" - looking at it from every aspect of dnssec being on by default, and not sending all your queries to some ISP for company like wanting your queries without providing any real benefit, etc. This has zero to do with using pfblocker or not..

Overall - no matter how you look at it, almost always resolver is a better choice for anyone wanting to turn a fqdn to an IP.. Be it your 1 user or 10,000.. The advantages of resolving are almost always going to be well worth the "possible" slight delay in looking up xyz the first time. Then just forwarding to abc and hoping they have it cached. And then having to ask them again as soon as that ttl expires, etc.

You brought up some valid discussion points about how to decide if forwarder "might" be better for some use case.. But your BLANKET statement and suggesting the user to turn off the resolver and forward for "performance" is just NONSENSE!!! And that was what I wanted to stop!!! Your not doing anyone any favors making such statements.

Yeah seems Comodo has some catching up to do.

If they don't like the SAN in the CSR they can always just ignore it and set their own before they sign.

There are also a myriad of CAs to choose from so...