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...

thanks for the reply. I was losing all network traffic, internet and traffic going to an IPSEC tunnel to another location I am running OpenBGPD to have BGP on top of my IPSEC I managed to fix the problem upgrading to latest 2.4.3 p1 Seems to be stable since then

Even though it's "working", you should still re-visit your design. I wouldn't plug your server directly into your firewall.

@stephenw10 Thank you for your reply

Is it possible you're using an on-board switch in the ISP router as the layer 2 between the HA nodes? I can see how that would be tempting but it would certainly cause a problem if powered off entirely. Steve

@stephenw10 said in 2 Single port ethernet cards: How low are the speeds you're seeing? What do you expect to see? How are the NICs connected? To what hardware? If the speeds are very slow indeed I'd be looking at the negotiated link speed on each NIC. Check for errors on Status > Interfaces. Steve I was expecting 11mpbs and I was getting 2-3. The hardware is a quad core pavilion with 4gb of ram. It was a defective nic.

You can't run Squid transparently on a bridged firewall so you can't put it in between the switch and Zyxel and maintain the same layer 2. However you shouldn't need to. When you configure Squid in transparent mode in pfSense it adds port forwards to the LAN side interface to redirect all incoming traffic on port 80 (and 443) to the Squid process running on local host. You can replicate that to Squid running on a different host easily enough. Just add port forwards in the Zyxel to forward traffic from the LAN side clients to the pfSense IP running Squid. Some things to consider: You may not want to forward all http/s traffic as you will need to reach the Zyxel interface and possibly upstream routers etc and that's probably better to do without using the proxy. If you can you should put the Squid box on a different subnet to the LAN clients otherwise you will have an asymmetric routing situation with reply traffic going back dirrectly to clients. No idea how the Zyxel would react to that but it should block the out of state TCP traffic be default. If you are running only Squid on that box pfSense may not be the best solution there. Though it is very easy to setup. Steve

I don’t know their MAC addresses to add them, so I turned on dhcp to add them. They are listed in the dhcp leases. Thank you!