lstein
Recieving "Connection reset by Peer" when Wan1 goes down and Wan2 comes up.
Primarily using the brilliantly written program for failover between my primary wan and my backup.
Every time the primary wan goes down from loss of connectivity, which occurs fairly often due to geolocation, I receive the error that "The connection has been reset by the peer." Which is occurring often enough where it has become a real irritant. My previous router setup did not possess this problem, which was OPNsense. In order to mitigate this error from becoming to large of a problem, I have adjusted the setting to net.ipv4.tcp_keepalive_time, but this has had little effect on the issue.
Anyone know of some way to tweak some settings to prevent this from happening?
Assuming you are using the "failover" rather than "balanced" mode, I think that this reflects a fundamental problem with the way that Net-ISP-Balance works with TCP. Each packet from the same TCP session is assigned a firewall mark that routes it to one or the other of the WAN interfaces. This ensures that the source IP address doesn't change during the course of a session, which otherwise will cause problems at the remote end of the connection. When the primary WAN goes down, any existing TCP sessions that went through the interface will get reset.
I will test what happens when the firewall mark rules are removed and report back.
Were you using failover with OPENsense? If so were you using the "Sticky Connections https://docs.opnsense.org/manual/how-tos/multiwan.html#sticky-connection" option, which would cause it to behave similar to Net-ISP-Balance.
Lincoln
On Mon, Jul 26, 2021 at 5:10 AM Anoduck @.***> wrote:
Primarily using the brilliantly written program for failover between my primary wan and my backup.
Every time the primary wan goes down from loss of connectivity, which occurs fairly often due to geolocation, I receive the error that "The connection has been reset by the peer." Which is occurring often enough where it has become a real irritant. My previous router setup did not possess this problem, which was OPNsense. In order to mitigate this error from becoming to large of a problem, I have adjusted the setting to net.ipv4.tcp_keepalive_time, but this has had little effect on the issue.
Anyone know of some way to tweak some settings to prevent this from happening?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lstein/Net-ISP-Balance/issues/35, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3EVJV5MG7HRXG4632NBTTZUQ7NANCNFSM5A7V3QFA .
--
Lincoln Stein
Head, Adaptive Oncology, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto
Tel: 416-673-8514
Cell: 416-817-8240
@.***
E**xecutive Assistant (Interim)
Michelle Xin
Tel: 647-260-7927
@.*** @.**>
Ontario Institute for Cancer Research
MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G 0A3
Collaborate. Translate. Change lives.
This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
I was using failover with OPNsense, and I do not believe that I was using sticky connections. Although, I do have the setting <lb_use_sticky>1</lb_use_sticky> in my configuration file. I remember being afraid that this might interfere with the failover functionality. As you know, OPNsense has ended support of i386 architecture, which forced me to rebuild things.
I wouldn't belabor your inquiry too much, you have already built a wonderful solution for implementing load balancing and failover. I have also got to find a more permanent solution to my network connectivity issues. Reception has been the pits for months now, and I direly need to erect a powerful antenna to receive a better connection. I might even need to look at starlink and see what the musk can do for my internet connection.
Thanks.
Hi,
Just an update here. I tried undoing stickiness but it did not quite behave the way I expected. I'm continuing to work at this.
Lincoln
On Tue, Jul 27, 2021 at 1:32 AM Anoduck @.***> wrote:
I was using failover with OPNsense, and I do not believe that I was using sticky connections. Although, I do have the setting <lb_use_sticky>1</lb_use_sticky> in my configuration file. I remember being afraid that this might interfere with the failover functionality. As you know, OPNsense has ended support of i386 architecture, which forced me to rebuild things.
I wouldn't belabor your inquiry too much, you have already built a wonderful solution for implementing load balancing and failover. I have also got to find a more permanent solution to my network connectivity issues. Reception has been the pits for months now, and I direly need to erect a powerful antenna to receive a better connection. I might even need to look at starlink and see what the musk can do for my internet connection.
Thanks.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lstein/Net-ISP-Balance/issues/35#issuecomment-887222380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3EVILCBZBD3E4LVVR5UTTZZAFZANCNFSM5A7V3QFA .
--
Lincoln Stein
Head, Adaptive Oncology, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto
Tel: 416-673-8514
Cell: 416-817-8240
@.***
E**xecutive Assistant (Interim)
Michelle Xin
Tel: 647-260-7927
@.*** @.**>
Ontario Institute for Cancer Research
MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G 0A3
Collaborate. Translate. Change lives.
This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
I appreciate your concern and the effort. The Connection Reset by Peer errors persist, and has made performing tasks such as updating to a new snapshot of OpenBSD arduous.
Also, getting the script to load on startup in debian is another hurdle that needs to be overcome. I have tried adding it to local.rc without success, attempted to load it when the interfaces come up without success, and I have even attempted to write a startup script for systemd that I must have buggered up. I will try again to write a startup script for systemd, which appears like a more sure solution.