Terminate Sessions On Connection Recovery

Product Discussion Peplink Balance
1

Hi everyone,

I’ve been running into an issue for years with the “Terminate Sessions On Connection Recovery” feature.

image
image533×495 16.3 KB

Here’s the situation:

  • If WAN1 fails, the sessions correctly move over to WAN2.
  • When WAN1 comes back online, the existing sessions remain on WAN2 — only new sessions are established on WAN1.

This has been the case for me across every firmware version I’ve tested. Each time, I end up receiving a special build from support, since apparently many other users either don’t use this feature or don’t notice the problem.

How about you? Do you actually not need this feature, or is it working differently in your setups?

For me, it’s a real issue, since WAN2 is a backup line with high per-volume costs.

Thanks in advance for your feedback!

1 Like
2

I guess no HTTPS Persistence option active in higher priority?

3

Hi!

Just a quick suggestion, have you tried this via IC2 outbound policies? Maybe its related to the webadmin version. Might just be a quick work around. I have my self not seen this before.

Do you have this issue when using a specific application or protocol? Or is it on general internet usage? And multiple applications or protocols behave like this?
And have you tested this if you create 2 different rules with another OBP algorithm and have them failover through the next rule? Does it then disconnect and uses the first rule?

Let me know. I’m interested to see if the above helps.

4

@PeterDedecker No, this is a confirmed issue and the rule is above “https-persistance”

@AstroJoe I am using local rules, as rules are quite different for every branch-office. The issue does only occure for priority-rules.

Very strange, that you do not see these issues.
It is easy to reproduce:

  • Cut WAN1 for one minute
    → Connections can be seen on WAN2
  • Reconnect WAN1
    → Connections are still on WAN2
5

Is the WAN2 interface (on the dashboard) at a lower priority?

6

No, they are both on priority 1 and the outbound policy does set the outbound-interface for that session

7

If you just want a hard failover/failback with destructive sessions, setting the interfaces at different priorities will achieve this, you don’t have to use an outbound policy for this specific case.

8

I am using different outbound-policies to steer traffic to different WANs, so this is not an option and WANs with lower priority cannot be monitored.

1 Like
9

We have seen this problem also, several times. Breaking WAN2 also to achive session movement back to WAN1. Problem with that, it is a manual human action.

Combined with the problem there is no option to disconnect a specific session or all sessions from a specific source or destination. Missing tools/options there.

10

Can’t you just disable interface 2 to terminate all sessions on it and then reenable it?

11

@Andrew_Fidel Sure, I can work “around” the bug and manually disable WAN2, but this is not a solution. There is a possibility to force a “failback”, but it is not working. So, If I do not SEE that there was a short interruption at night, the sessions are staying on the expense backup-WAN for weeks…

12

Does this happen with TCP, UDP or both? If I recall correctly, it only affected one of the two protocols.

13

I did test it for UDP and TCP.
Both are showing the same behaviour.

  • The “standard”-build does not fail back
  • The provided special build does fail back (and respect the setting)