Same behavior related here. https://redmine.pfsense.org/issues/8512

First step is to see why this is happening to you. I agree it's most likely related to the configuration/local setup of the devices. Before you reboot the device, you should navigate over to Status, System Logs, take note of the information there, try expanding it to a few thousand entries, there will be something noted in this area about what is causing your lack of internet access. I would suggest getting a console session going, our SG-2440 Manual has a great guide on gaining access to the console. What packages do you have installed on your device? If you run from the command prompt df -h how much disk space is there? The more information you can get to us, the better someone can assist you.

@tejas said in High RTT latency on wan [SOLVED]: I am using Pfsense 2.3.5-release-p2(i386) on Intel Pentium G2020 @ 2.90GHz Why are you running 32bit on that CPU? You should be running 2.4.4 there really. About the only reason those interfaces would not show in the Firewall > Traffic Shaper > By interface tab is if they don't support ALTQ. You would have to check exactly what hardware they are to know for sure though. I would expect the Intel NIC to support it but their ix NICs do not. What are the actual port names listed? re0, re1, em0? pfBlocker and Squid do different things they should not interfere. But bare in mind connections coming from Squid will always have the default WAN as the source IP. pfBlocker can block connections on LAN before they reach squid if you have it configured to do so. Existing states are not removed when you change the ruleset. So if you want to move a client to use a different gateway you would have to kill any open states on the old gateway or just wait for them to timeout. Only new states will use the changed rule. It is accurate. If traffic is passing and you see no states there it is not being passed by that rule. If you want to do full SSL traffic inspection you have to install the generated CA on the clients there is no way past that. However you can do 'peek and splice' to filter by FQDN only. See: https://youtu.be/xm_wEezrWf4?t=637 If any of those alerts are against legitimate traffic you need to suppress them or disable the rule that is being triggered before you switch to blocking mode or you will block required traffic. https://www.netgate.com/docs/pfsense/ids-ips/setup-snort-package.html#alert-thresholding-and-suppression Steve

What other rules do you have on the LAN? Is the GUI running on port 443? Do you see blocked traffic in the firewall log after disabling the rule? Steve

A diagram showing what you want to do would help a lot here. Steve

It depends how restrictive you want to get. It can be difficult to impossible to completely eliminate that though. You can block all traffic except ports 80, 443 and 53. The Squid rules will redirect 80 and 443 to itself and you can add a port forward to to redirect all DNS to Unbound. You will break many things though and get a lot of complaints! Steve

I managed to make 2.2.6 detect my Realtek NIC by patching the driver. But just now realized that the PPTP feature on the pfSense is only for setting itself as a VPN server. Opposite of what I wanted

Ah, then you should update unbound: pkg upgrade unbound It will pull in a new strongswan version with that. Or try a 2.4.5 dev snapshot which contains that. Steve

Well, there's Packet Capture, built into pfSense, that can capture all the traffic on a pfSense interface. However, you'd have to manually start & stop it and then download the capture file. If an interface on another device, you'd also need a managed switch, configured to port mirror.

The Gateway logs does not show any logs during today's outage and also we were are not able to connect out from the firewall during the outage period. Thanks Tanner

Exactly! If the cat catches mice, then who cares what it looks like!

@steve_b okay, I'm seeing inconsistent behavior here and I haven't been able to pin down why. router 1 (the originally not working one): While looking for the debug logs, I noticed that the log entries for success had disappeared. I traced this to a check for boot completion that was failing, preventing the backup from starting (this is a different issue. I also don't know why the boot is no longer finishing). I manually deleted the booting file so that the backup would run, and it started working. I then walked back the firewall and DNS config (and the debugging stuff that I had added in acb.php) that I had done before to try to get it to fail again, and it would not fail. So, I don't know what changed to make it work. router 2 (the originally working one): This one started exhibiting the behavior seen before on router 1 (backups report success in web ui, but they are not occurring). This one does have a backupdebug.txt indicating a timeout on the save. I can still ping and curl acb.netgate.com.

Thanks for the hint. I think I got the issue resolved. I was trying to use the console to figure out which nic was active so I can assign my lan/wan to the nics i wanted. I was doing this by using option 1 (assign interfaces) and seeing which nic was showing as up in order to assign things before logging in for the first time. After going into Interfaces > assignments and adding the extra 4 nics and then clicking on each one and selecting enable, pfsense now seems to be detecting the interfaces as up.

I believed the maximum throughput was 42MBps for PPP lining up with HSDPA but I recently saw a report of >60Mbps so I guess it's possible if your carrier and hardware support it. I've personally seen ~32Mbps using a Sierra m.2 modem and PPP. Steve

What card are you taking out? What are you replacing it with? pfSense configures the network again interfaces detected by the OS at boot: em0 em1 igb0 re0 etc. The name given to it depends on the driver it uses and the order it is detected in. If you had those 4 NICs above and you removed igb0 and replaced it with another igb card then you would likely not have to change anything. The new card would also be named igb0 and the config would match it. If you replaced it with a different card, say a Broadcom card using the bge driver, then pfSense would stop part way through the boot and ask you to assign the interfaces because igb0 referenced in the config no longer exists. You would just assign the NICs at the console to the same interfaces and it will boot up with all the same settings as before. It gets more complex if you replaced igb0 with another em card because that new card might be detected it a different order so that while you would not have em0 em1 and em3 the new card could potentially be any of them. You can still assign it at the console in the same way but if you find things don't work as expected after booting you might need to re-assign the cards in a new order or swap the physical network connections. Steve

Hmm, no. Very odd. Glad you found it though. Might help someone else hitting that. Steve

Looks like you cross-posted here as well as Reddit, but I responded over there. For the benefit of others who may come across this: It's fixed in the most recent version of the OpenVPN Client Export package. It now forms the correct FQDN for Cloudflare hostnames when exporting.

Usually when you see that it's because you're using a bash script and pfSense does not use bash. Some commands do not work. Though here it looks like it's trying to run { as a command. Steve

Problem has been resolved. Since these units are MultiWan, we found that when the gateway changed, neither unit could resolve DNS internally, preventing them from reaching the ACB Servers. By adding gateways in the System > General Setup > DNS Server Settings and associating different DNS servers with each gateway, we were able to restore the connection and now all is working.

Not sure what PCIe devices might allow that. I've only ever used PPP with those. Why do you want to bridge this though? If you only have one public IP I'm not sure why you would. You could use that IP on the bridge interface and be able to access pfSense that way but then there seem little point in bridging. If you use the public IP on some downstream device you wouldn't be able to access pfSense without going through that device somehow. There is also the fact that most "modems" will want to use the IP themselves and run in router mode. Steve