On 2017-05-19 08:33 AM, Angel Rengifo Cancino wrote:
On Fri, May 19, 2017 at 6:55 AM, Ugo Bellavance <[email protected]> wrote:
Hi,
We sometimes experience what looks like service interruptions on our
pfSense firewall. The first symptom was that we came in the office in the
morning and found that all the ssh sessions that were opened and going
through the firewall would be disconnected.
I searched the pfsense logs and I found that:
May 19 04:35:48 fw1 dpinger: ISP 206.55.90.97: Alarm latency 2231us
stddev 1209us loss 21%
May 19 04:36:01 fw1 dpinger: ISP 206.55.90.97: Clear latency 2253us
stddev 1266us loss 15%
May 19 04:54:24 fw1 dpinger: ISP 206.55.90.97: Alarm latency 2021us
stddev 1042us loss 22%
May 19 04:54:39 fw1 dpinger: ISP 206.55.90.97: Clear latency 2564us
stddev 6028us loss 19%
May 19 05:13:05 fw1 dpinger: ISP 206.55.90.97: Alarm latency 2203us
stddev 1345us loss 21%
May 19 05:13:17 fw1 dpinger: ISP 206.55.90.97: Clear latency 2044us
stddev 870us loss 17%
I opened a ticket with mi ISP, but I don't think that they'll find
anything. I must say they they're not the most knowledgeable.
I've experienced such packet loss before and it was always ISP's fault. If
your bandwidth usage is not full then there should not be a reason for
lossing so many packets.
Our bandwidth usage is quite high when it happens.
According to the logs, everytime that happens, pfSense tries to do a few
things:
- Update dyndns
- Restart VPN tunnels
- Reload filters
I'll keep on searching but I really wonder wether the post-clear-latency
actions cause the SSH disconnects (and possibly other network cuts) or if
it's the firewall that is too busy to receive the ICMP packets.
Once I had the same problem with 2 ISPs configured in my pfSense box and
disabling this option helped me to avoid such disconnection behavior:
System -> Advanced -> Miscellaneous -> State Killing on gateway failure
Interesting. Why would it be a good idea to kill the states on a gateway
failure?
You can try it.
The firewall runs on a VMWare VM,
Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
3 CPUs: 1 package(s) x 3 core(s)
1 GB RAM
The host is not cpu-bound.
Make sure VMware is not part of the problem. If possible, use a physical
server to start a basic monitoring using continuous ping to see if packet
loss also occurs on this host. If it doesn't happen the same loss of
connectivity then maybe your VMware infrastructure might be part of the
problem.
That's not really feasible, unfortunately, but it's good advice.
Thanks,
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
