@stephenw10 said in LAGG interfaces help: r Yes the reason I need to do Failover is because the two switches that are connected one to each interface don't stack and don't know each other. Had a switch failure and I'm trying to make an HA scenario so we don't have this happen again.

see https://redmine.pfsense.org/issues/10836

Then enable pfscrub. That is required for fragment re-assembly. Steve

Well normally a device switching to an AP shouldn't cause a problem with connectivity.. Unless your AP are actually natting.. Since your device would still have the same IP just roaming between AP. Unless sure it was having connectivity issues.

HI Gertjan, Thanks for the pointer, I am just a tech enthusiast running pfSense at home. I did some Google search on setting up gateway monitoring and stumbled upon lots of literature on SNMP, NRPE as well. As of now this is way over my head but let me read a bit and come back here with results and/or questions Thanks again

Thanks guys for chiming in and suggesting VPN; however, the idea isn't about connecting to one's home network ... the idea assumes that one doesn't have a home network at all ... the only assumptions are that one has a laptop and one is traveling as well as the laptop has limited RAM (16 or less). One avenue that looks very promising is pfSense cloud and I will look into it this week: https://www.netgate.com/solutions/pfsense/index.html#cloud

Hi again After about 40 min all network stats was suddenly there. I have no idea what made it work. Regards Henning

restart it and connect to any low ping server.

@Impatient said in "Strange"? Memory Pattern Since Snort Migration: Could it be that suricata doesn't load some of the snort rule's? That could be a portion of the difference, but it's mainly just in how the internal code of the binary handles setting things up as it reads in the configuration and acts upon it. Snort and Suricata are completely different animals in terms of their internal coding.

@kapvcop said in help help to block anydesk: I have created blocks to the ports that the anydesk help page says but it does not work, that is, it continues to work, Show what you've done (screenshots)

@Raffi_ said in How do I debug frequent Gateway alarms: I meant to give it a tug when hooked up to your Ethernet tester, not pfSense. The tester could give a you the false sense that the cable is good when it's actually not. Therefore, stressing the cable a bit might put it in a failing state and give you a more accurate test result. If you're still having issues, it might be easier to replace the cable. That might be worth a try anyway if you have an extra cable around. Yea, I think those hotplug events were you disconnecting the cable when you were testing. Never did I think it could be the cables. With my short runs I assumed cables either worked or they didn't. Not a single error after I replaced all the cables.

There are another informations from log and time when problem starts: Aug 13 22:30:14 kernel em2: link state changed to DOWN Aug 13 22:30:14 kernel em2: RX Next to Refresh = 1023 Aug 13 22:30:14 kernel em2: RX Next to Check = 0 Aug 13 22:30:14 kernel em2: RX discarded packets = 0 Aug 13 22:30:14 kernel em2: hw rdh = 0, hw rdt = 1023 Aug 13 22:30:14 kernel em2: RX Queue 0 ------ Aug 13 22:30:14 kernel em2: Tx Descriptors avail failure = 0 Aug 13 22:30:14 kernel em2: TX descriptors avail = 886 Aug 13 22:30:14 kernel em2: Tx Queue Status = -2147483648 Aug 13 22:30:14 kernel em2: hw tdh = 0, hw tdt = 138 Aug 13 22:30:14 kernel em2: TX Queue 0 ------ Aug 13 22:30:14 kernel Interface is RUNNING and ACTIVE Aug 13 22:30:14 kernel em2: Watchdog timeout Queue[0]-- resetting Aug 13 22:30:14 check_reload_status Linkup starting em2 Aug 13 22:28:04 dhcpleases /etc/hosts changed size from original! Aug 13 22:28:04 php-fpm /rc.newwanip: rc.newwanip: on (IP address: xxx.xxx.xxx.xxx) (interface: WAN[wan]) (real interface: em2). Aug 13 22:28:04 php-fpm /rc.newwanip: rc.newwanip: Info: starting on em2. Aug 13 22:28:03 check_reload_status Reloading filter Aug 13 22:28:03 check_reload_status rc.newwanip starting em2 Aug 13 22:28:03 php-fpm /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx ) Aug 13 22:28:02 kernel em2: link state changed to UP Aug 13 22:28:02 check_reload_status Linkup starting em2 Aug 13 22:28:01 php-fpm /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_IP_ADD. Aug 13 22:28:00 check_reload_status Reloading filter Aug 13 22:28:00 check_reload_status Restarting OpenVPN tunnels/interfaces Aug 13 22:28:00 check_reload_status Restarting ipsec tunnels Aug 13 22:28:00 check_reload_status updating dyndns WAN_IP_ADD Aug 13 22:28:00 rc.gateway_alarm 41570 >>> Gateway alarm: WAN_IP_ADD (Addr:8.8.8.8 Alarm:1 RTT:9.184ms RTTsd:.778ms Loss:21%) Aug 13 22:27:59 check_reload_status Reloading filter Aug 13 22:27:59 php-fpm /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx ) Aug 13 22:27:58 kernel em2: link state changed to DOWN Aug 13 22:27:58 kernel em2: RX Next to Refresh = 1023 Aug 13 22:27:58 kernel em2: RX Next to Check = 0 Aug 13 22:27:58 kernel em2: RX discarded packets = 0 Aug 13 22:27:58 kernel em2: hw rdh = 0, hw rdt = 1023 Aug 13 22:27:58 kernel em2: RX Queue 0 ------ Aug 13 22:27:58 kernel em2: Tx Descriptors avail failure = 0 Aug 13 22:27:58 kernel em2: TX descriptors avail = 989 Aug 13 22:27:58 kernel em2: Tx Queue Status = -2147483648 Aug 13 22:27:58 kernel em2: hw tdh = 0, hw tdt = 35 Aug 13 22:27:58 kernel em2: TX Queue 0 ------ Aug 13 22:27:58 kernel Interface is RUNNING and ACTIVE Aug 13 22:27:58 kernel em2: Watchdog timeout Queue[0]-- resetting Aug 13 22:27:58 check_reload_status Linkup starting em2 Aug 13 22:27:53 check_reload_status Reloading filter Aug 13 22:27:53 dhcpleases /etc/hosts changed size from original! Aug 13 22:27:53 php-fpm /rc.newwanip: rc.newwanip: on (IP address: xxx.xxx.xxx.xxx) (interface: WAN[wan]) (real interface: em2). Aug 13 22:27:53 php-fpm /rc.newwanip: rc.newwanip: Info: starting on em2. Aug 13 22:27:52 check_reload_status Reloading filter Aug 13 22:27:52 check_reload_status rc.newwanip starting em2 Aug 13 22:27:52 php-fpm /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx ) Aug 13 22:27:51 kernel em2: link state changed to UP Aug 13 22:27:51 check_reload_status Linkup starting em2 Aug 13 22:27:49 check_reload_status Reloading filter Aug 13 22:27:49 php-fpm /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx ) Aug 13 22:27:48 kernel em2: link state changed to DOWN Aug 13 22:27:48 kernel em2: RX Next to Refresh = 733 Aug 13 22:27:48 kernel em2: RX Next to Check = 734 Aug 13 22:27:48 kernel em2: RX discarded packets = 0 Aug 13 22:27:48 kernel em2: hw rdh = 734, hw rdt = 733 Aug 13 22:27:48 kernel em2: RX Queue 0 ------ Aug 13 22:27:48 kernel em2: Tx Descriptors avail failure = 0 Aug 13 22:27:48 kernel em2: TX descriptors avail = 961 Aug 13 22:27:48 kernel em2: Tx Queue Status = -2147483648 Aug 13 22:27:48 kernel em2: hw tdh = 70, hw tdt = 133 Aug 13 22:27:48 kernel em2: TX Queue 0 ------ Aug 13 22:27:48 kernel Interface is RUNNING and ACTIVE Aug 13 22:27:48 kernel em2: Watchdog timeout Queue[0]-- resetting Aug 13 22:27:48 check_reload_status Linkup starting em2 We have more public addresses. Cisco routers on other address seems works OK. So you think, that replace Intel card is the solution? But after restart it work ok. :-/

There are no options to control which events generate e-mail notifications. The only one of the items you listed that is somewhat possible is the interface one, though that is only possible via gateway monitoring, not from the interface event itself.

Don't forget to set the default gateway in the routing section. I recently had a similar problem with the WAN being shown as up, but LAN clients being unable to connect to the internet. It was because I had migrated the router from a different location and the old default gateway was still set.

@jhunt Certain models of TP-Link switches, including your don't handle VLANs properly, in that they allow multicasts to leak. There are apparently issues with VLAN 1 appearing on all VLANs. This may have been fixed with an update.

@ntranx /var/db

Hmm, how about snort and the openappid-vpn_tunneling.rules. ruleset? If you do go through with locking down VPN, please do your users a solid and make sure your Wireless environment is secure and users aren't at risk of packet sniffing or MiTM attacks.

@user_three $15 a month with ATT.

@pfguy2018 Yes, that appears to come from the first server tried. However, it also seems to have a bad checksum, so it would be discarded.