Firmware is SonicOS Enhanced 6.5.4.5-53n
The HTTPS management over 4343 is coming direct through the original WAN IP.
Peplink Balance 20x is 8.2.0 build 5141
I’m confused by this thread.
Is the OP trying to do
+<-> Fixed-line Internet
LAN <-> Sonicwall -+
+<-> Balance 20x <-> LTE Internet
(which would be the way I’d be inclined to do it) or is he trying to do
+<-> LTE Internet
LAN <-> Balance 20x -+
+<-> Sonicwall <-> Fixed-line Internet
When the OP talks about “a /30 from the provider” is he talking about from the cellular provider, the fixed-line provider, or different public static IPs from each?
Hi James,
Fixed line sharing same WAN IP address. Shared IP.
Drop in mode connected to LAN 1 of Peplink going to WAN of Sonicwall
Ok, so my 2nd diagram.
Your public, static IP address is not going to be “shared” between the hardwired Internet connection and the LTE Internet connection. Short of an ISP that can perform that service for you, there’s no way to do that.
E.g.: If you were to fire-up a browser on the LAN and go to any “what’s my IP?” web site while you were connected to only the hardwired Internet provider, it would tell you whatever public, static IP that ISP gave you. Then, if you were to take down the hardwired connection so the Internet access was via LTE, then went to that same site, you’d see a different IP address. (One that would almost certainly change from time-to-time and would likely not be the one the Balance claims is your public IP address, because cell providers nearly always do CG NAT.)
Now, a consumer on the LAN side wouldn’t notice the difference. But if the LAN has services running on it the router has port-forwarded, say a mail or web server: Those will no longer be accessible, because the Internet connection with the static, public IP simply won’t “be there.”
Nope.
We’re using Drop In Mode so its:
Sonicwall → Balance 20x → Fixed line internet
With the Balance 20X set to share the same public ip as the Sonicwall WAN.
Inbound port forwarding then hits the ISP gateway → balance 20X → then Sonicwall WAN.
1 Like
@DarrylP
Use this guide and see if you can fix the issue with those changes:
https://www.sonicwall.com/support/knowledge-base/dropped-packets-because-of-invalid-tcp-flag/170504420448221/
Then we can work out why they are happening. Its likely something to do with the way drop in mode is sharing the IP…
1 Like
Ok, but, still: The goal was “Public IP for LTE backup.” “LTE backup” implies “for when the primary WAN goes down,” does it not? In such a case: The static, public IP “goes away.” That’s true regardless of in which order one connects hardwired ISP’s modem/router, Sonicwall, and 20x.
Btw: This: What is Drop-In Mode? suggests drop-in mode has the Peplink device between the ISP’s modem/router and the firewall. I wonder if we’re not having a terminology problem?
To be fair you are right. I’ve been so focused on the drop in mode shared IP bit of this problem that I’ve largely ignored the LTE side.
Drop in mode lets the balance 20x be inserted between a customer firewall and the ISP router to provide seamless failover of outbound services if the primary ISP were to fail.
Inbound traffic is not seamless failover and the easiest way to use the cellular in bound is with double NAT, but IP passthrough is possible on the cellular if not ‘officially supported’ in that Drop in Mode and IP Passthrough is a complex config.
So what we can have is this:
Where is the inbound traffic flow (Assuming IP#4 is a public IP on the LTE WAN) which has double NAT on the LTE WAN:
And then this is the ‘unsupported’ approach where IP Passthrough is enabled on the LTE WAN:
2 Likes
Hi Martin,
I have tried the Sonicwall article and it didn’t work. At the moment, I’m not concerned with inbound forwarding on the LTE failover. We just want to get the inbound ports working on the primary connection.
I’ve had a ticket open as well. They made a change over the weekend and I didn’t see their response. It’s now working. I have asked them to provide some details on what they changed. I will follow up.
Good to hear! Post the ticket number here at we’ll ask them to update us too.
1 Like
Still waiting on a response.
Ticket # 22041114
I checked the settings. They changed the management IP address in the Peplink from the 169.254.0.1 to an IP on the WAN that is routable. For instance, shared IP is 10.12.20.2/24 the management IP would be 10.12.20.1/24. Is this how it would work in a shared IP environment? What IP would I use if it’s a /30 from the ISP provider? The gateway IP?
I did change the LAN IP to the same IP as the gateway on ISP 1. Seems to still be working as well. I still haven’t gotten a clear answer on if this is the right way to do it if the client only has 1 IP address available with their ISP. Support is slow to respond and seems to be a different time zone.
@DarrylP ,
I have checked your ticket. Suspect that the unwanted port forwarding rules cause the drop in mode shared IP access issue. In drop in mode, we don’t require to define port forwarding/NAT mapping rules. I have give some suggestion in the ticket and do let us know if you still need any help ^^.
Thank you
1 Like
Hi Sit Loong,
TK at Peplink added the port forwarding rules. I have removed the forwarding rules and changed the mangement IP to the same as the shared IP, the gateway IP, and also tried a LAN IP on the SonicWALL LAN without any luck. I have enabled logging as you suggested to check. I don’t see anything in the log specifically from our source IP.
@DarrylP, I am handling your ticket but it is related to the inquiry about WAN Quality report. Mind sharing which ticket I am working on with you and adding the port forwarding rule? It is important to sync with each other (between technical support engineers) on the settings we advised.
You may continue working with Sit Loong on the current ticket.
Thanks.
1 Like
My apologies. It was Manuel that originally handled the ticket.
Peplink has confirmed that they reproduced the issue and engineering is trying to find a root cause.
2 Likes