Port forward on dual WAN setup

I’ve run in to something I can’t figure out. I have a MAX BR1 MK2 set up with two WANs. Priority 1 Hardwired, Priority 2 Cellular. Both with static IPs. I have a port forward setup with both WANs and their interface IPs checked. The remote device is configured to connect to the Priority 1 static IP. The port forward works fine.

The issue: When the priority 2 connection becomes active, and I reconfigure the remote device to connect to the Priority 2 static IP. The port forward does not work. If I restart the Pepwave it will work. However when failing back to the priority 1 connection, it does not work till I restart it again… Not sure what I am missing when the port forward has both WANs and interfaces selected.

No one with any thoughts on what I am doing wrong here?

I don’t see anything particularly wrong, but I would start debugging with a packet capture, and with that evidence, open a ticket with Peplink, if you see the packets on the cell interface, but none translated to the lan.

You could also look at the Status->Active Sessions. Does the previous session sit around? Does the new TCP session change the Interface that is attached to that session?.. the IP’s would be similar.
Another test would be, is this behavior only limited to the single source->destination pairing.

For example you can connect to Static#1 from deviceA Then you fail WAN 1 and connect from Device B (different internet IP) to Static #2 etc. Does that have the same “needs a restart” behavior?
If you have both WAN’s up 24x7 can you randomly hit both inbound rules?.

You have a number of unique items (the static cellular sim) that preclude us from testing and verifying similar behavior on our systems. My cell is behind CGNAT, and I don’t have a second Wired WAN with an exposed IP.

Personally I use a Fusionhub to port forward into my network environment and rely on Speedfusion to handle the redundancy, and I would ask, if you control the remote device, I would rather bring it into a PepVPN/ipsec ecosystem rather than send random TCP connections over the internet.

1 Like

What sort of traffic / application is it? Is it VoIP or video streaming? Is it UDP or TCP based?
If you look at Status → Active sessions when its misbehaving do you see the old sessions listed still?

I love FusionHub for this kind of thing as it means you’re not exposing a cellular connection to the public internet for port scans and other nonsense that can consume bandwidth.

Thanks the the responses. I have also opened a ticket with Peplink. I do see the old session sticking around in Active Sessions, even after stopping the originating device and re-directing it to the static of the cellular sim. This is for an audio link, we had been using older cradle point devices for this with no issues. It’s an audio codec that’s UDP. The cellular device with the static is always in priority2 so it’s in standby for when the wired connection at the site either fails or is manually switched disabled.

As others have mentioned maybe sessions are sticky to the previous WAN if they don’t expire quickly, this may mess a bit with the conn tracking in the Peplink.

You could try the “Terminate Sessions on Connection Recovery” option on an outbound policy matching the traffic for your internal host and see if that helps?

1 Like

What it feels like is that Active session isn’t getting re-set by the new session. A failed interface should re-set all sessions, but there was a bug… if you have the time you could try the beta:

26376
[Beta 1] [System] Fixed: Remove sessions if the WAN is down or health check failed.

We understand that you use it with only one side switched, but testing with both up tells us if this is a category error. A proper firewall and ruleset should be able to track sessions across two different WAN systems at the same time. If it can’t do that, it will likely not work with one up one down, and still shows there could be a second bug.

are the source/destination UDP ports fixed? or is the source random?

There are corner cases that cannot be distinguished at the firewall level, where you would have to separate the two sessions by port, or some other item.

1 Like

Yes I would be willing to give the beta a shot. Yes, I was expecting that it would remove sessions on the failed/disabled WAN allowing a session on the same port forward on the second WAN. We are using UDP 9000-9001 in this case.