Hi Folks,

hope you can help me solve the challenge I've been tasked with, when my old LTE-Router (serving WAN2) blew up two week ago.

In short: I need to find a way to provide WAN redundancy for my PBX/SIP System but avoid Dual NAT at all cost, to get a good availability of the voice-call service to the family.
Especially incoming calls would often not pass, when the PBX is connected via a double NAT (SIP-ALG helpers would not improve this, to my experience).

Where to start: I do run a Dual WAN setup (ISP1 - cable, ISP2 - LTE/4G) since a couple of years and it serves me well.
Both ISPs provide their Routers (so I have no right of way in terms of hardware and firmware choice).
As I was not able to switch off the firewalls in the ISP-Routers anyway, I decided to disable srcnat/masquerading rule/action in the firewall of my central home Router (a RB4011).
This left me in the position to run my central PBX from inside my home LAN and switching default gateways for WAN1 and WAN2 was transparent to the PBX (and that enabled the PBX to pass one NAT only for outbound internet traffic, to my SIP providers this way). My PBX is a standard device, providing DECT/SIP/analog/ISDN Telephony to the home (no Asterisk like PBX, no full blown OS)

The root cause of the new problem: The LTE-Router died two weeks ago. The replacement model, although having a new, superior 4G performance, is not able to accept an additional static route, pointing back to hosts (and the PBX hence) of my other home network(s). Thus I am left with/forced to enable NAT in my RB4011 for the default route using WAN2 as gateway (the new LTE Router).
This would end in a double NAT situation, once WAN2 takes over....which is not acceptable for SIP services used by my PBX.

Where I am now: I now did place the PBX, along with both ISP Routers inside a dedicated VLAN, as a WAN zone on a single network (remember, both Routers do provide NAT, so the PBX inside that zone is still safe).
This would allow me to at least switch the default gateway inside the PBX manually to either WAN and maintain the single NAT status for each WAN Route.
For traffic from my home (V)LANs, I enabled NAT towards the LTE/WAN2 gateway in my RB4011, accepting double NAT for this route for other hosts (which do not have a problem with double NAT).

This scenario technically works and is depicted below.

The challenge: How can I enable the PBX, now in the WAN zone, to

• avoid dual NAT scenario when either WAN1 or WAN2 is active
• use one default gateway, enabling the switchover of either WAN, transparently/without need for manual intervention

...just like it was, before WAN2 required an additional NAT layer.

I am willing to redesign my network layout as needed, as per your suggestions, but am hoping that there is just some additional magic to add. ;-)
Many thanks in advance for your time and feedback!

Hi,

Since you don't have a choice of equipment like what you have mentioned, you are left with a couple of options with varying degrees of annoyance, #1 you could ask both provider to route additional public ip at least /30 on your existing connection for the pbx and put a firewall upfront #2, established a vpn connection on both your provider but this will surely add latency #3 force them to provide the same LTE modem to you and explain you can't add static route going back to your pbx, choose your pain :p just kidding

...thanks.
The old router model is no longer available.
Since I am not on a business plan with both ISPs, I simply doubt that there is the slightest chance to solve my case from their side.
Maybe there will be a future upgrade of the firmware for LTE-router, but this will take some time at best.

Maybe I can do a destination 1:1 NAT/port forwarding from PBX traffic, coming in via interface defined on PBX default gateway, to the active WAN-Gateway that is set/changed based on a script?
Probably would need a 3rd Router inside WAN zone just for that purpose ... or dedicating two more interfaces on RB4011 to that purpose, with a separate routing mark?
Such NATing should not do harm to the SIP traffic, I think

I'm still waiting for someone to explain me where is the difference in impact on SIP&RTP between a single NAT and a multiple NAT, except where SIP ALGs make things worse because they are either broken or people expect them to work beyond what is actually possible.

Since you mention a PBX, do your family members register their phones to this PBX while they are outside home (or at home but connected using 3G/4G), or does the PBX just register itself to the SIP provider's exchange and all phones register to it via your home LAN?

You can bridge the two WANs of the 4011 together with the port where the PBX is connected if both ISP's routers use the same IP subnet. Then you would assign different IPs in that subnet to each of the ISP's routers and also to the 4011. The 4011's IP address would be set as the default gateway for the PBX.

Now you would place the following rules to /interface bridge nat:
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip dst-address=10.0.0.0/8 action=accept
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip dst-address=172.16.0.0/12 action=accept
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip dst-address=192.168.0.0/16 action=accept
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip action=dst-nat to-addresses=mac:add:ress:of:gw:1
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip action=dst-nat to-addresses=mac:add:ress:of:gw:2

A script would disable and enable the last-but-one rule depending on the transparency of WAN1 all the way to the internet.

The point is that the 4011 would respond with its own MAC address to ARP requests sent by the PBX, but frames towards this MAC address carrying IP packets would be diverted to the currently preferred gateway unless their destination IP addresses would be private ones.

Just bear in mind that there will always be a lag between the start of WAN1 outage and the time the PBX re-registers to the public exchange.

I'm still waiting for someone to explain me where is the difference in impact on SIP&RTP between a single NAT and a multiple NAT, except where SIP ALGs make things worse because they are either broken or people expect them to work beyond what is actually possible.

True...my reasoning is based on experience. When I introduced VLANs in my setup same years ago I had a time where I used everything in a double NAT situation. The original ISP Routers still are not capable using VLANs and everyone just stated, that double NAT would not impose an issue.
However, I found this wrong, especially for SIP connections. Outgoing calls were always fione, but sometimes inbound calls would not even ring / reach my local PBX.
I don't have these kind of problems, when I switched away from double NAT.

Since you mention a PBX, do your family members register their phones to this PBX while they are outside home (or at home but connected using 3G/4G), or does the PBX just register itself to the SIP provider's exchange and all phones register to it via your home LAN?

Only the latter...using the PBX to register with several service providers and phones registering via home (V)LAN.

You can bridge the two WANs of the 4011 together with the port where the PBX is connected if both ISP's routers use the same IP subnet.

Yes, from inside the WAN zone/VLAN i created, all use the same IP net.
I did not create a separate bridge for these ports yet, but yes I see where this is going.

Then you would assign different IPs in that subnet to each of the ISP's routers and also to the 4011. The 4011's IP address would be set as the default gateway for the PBX.

OK, understood

Now you would place the following rules [...]
The point is that the 4011 would respond with its own MAC address to ARP requests sent by the PBX, but frames towards this MAC address carrying IP packets would be diverted to the currently preferred gateway unless their destination IP addresses would be private ones.

OK, got it....

chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip action=dst-nat to-addresses=mac:add:ress:of:gw:1
chain=dstnat in-interface=pbx-port dst-mac-address=mac:add:ress:of:the:4011 mac-protocol=ip action=dst-nat to-addresses=mac:add:ress:of:gw:2
A script would disable and enable the last-but-one rule depending on the transparency of WAN1 all the way to the internet.

Uhmmm, not quite clear what you are saying...sorry, but english is not my native tongue.
either enable or disable one of these two last rules, based on WANx availability...is this what you mean by your statement?

Just bear in mind that there will always be a lag between the start of WAN1 outage and the time the PBX re-registers to the public exchange.

Yes, this is clear. An active call will also drop, when WAN changes over

Many thanks for your help!
I'll try to set this up during the weekend.

english is not my native tongue

Can you reveal the native one?

either enable or disable one of these two last rules, based on WANx availability...is this what you mean by your statement?

Correct. It is enough to disable and enable the one for WAN1, because if both WANs are available and thus the rule for WAN1 is enabled, the packet never reach the rule for WAN2, and if both are down, it makes no difference whether the rule for WAN2 handles the packet or not.

Can you reveal the native one?

I am from Germany

Correct. It is enough to disable and enable the one for WAN1, because if both WANs are available and thus the rule for WAN1 is enabled, the packet never reach the rule for WAN2, and if both are down, it makes no difference whether the rule for WAN2 handles the packet or not.

Ah, true, now I understand...thank you.
I think I will use the script to also toggle the port of the PBX when WANx drop is detected....since this is also the (WAN-)port, where the PBX will receive the IP via DHCP from, this should force the PBX to reconnect, thus speeding up the process a bit.

Thank you very much again, for your help!