Force a specific subnet to use only one WAN even while a failover HA

[Babine]

Hi,

My question is in the title :

Force a specific subnet to use only one WAN even while a failover HA.

I give you just some more information.

I have two internets connections configured on my MX, one main and the over one in backup.

My PBX needs the main connection to work. So when my main connection fall down and my second replace it my PBX stop working.

The thing is, when the main connection comes back, the PBX still doesn't work, i can't say why.

I have to unplug my second connection, reboot my PBX to make it work again ...

So that why i would like to know if there is a solution to force a specific subnet to always use the same connection even if a failover happen ?

Thank for your help !

[Bruce]

@Babine, I find it odd that your PBX should stop working just because you've failed over to the other internet connection. I'm assuming that you issue is a SIP trunk that uses your internet connection and that your SIP trunk provider will only accept requests from the IP address on your primary link.

All I can imagine is happening is that connection attempts are being made over the secondary link, when a failover occurs, but are never switching back to the primary.

A couple of things to try...

1. Assuming its a SIP trunk issue - if you can reconfigure your SIP trunk to use TCP instead of UDP (assuming that your provider supports SIP with TCP, and that you're currently using UDP), that may solve it. This will mean that you move to a connection-based transport, rather than connection-less which may aid in the system 'realizing' it can't get a connection on the secondary WAN link.
2. Ask Meraki Support to apply the Cellular Failover firewall rules on the MX to the WAN2 port (rather than the cellular modem). This will allow you to create a specific ruleset on WAN2 that specifically denies traffic between your PBX and the cloud service. Hopefully this will stop the issue you are seeing occurring as the traffic from the PBX won't be able to exit via WAN2.

Or you may find a combination of both are required. (Or that none of them work).

Hope this gives you a couple of options to try.

[Babine]

Hi Bruce,

Sorry for the delay.

I find it odd that your PBX should stop working just because you've failed over to the other internet connection. I'm assuming that you issue is a SIP trunk that uses your internet connection and that your SIP trunk provider will only accept requests from the IP address on your primary link.

Yes that's it !

Assuming its a SIP trunk issue - if you can reconfigure your SIP trunk to use TCP instead of UDP (assuming that your provider supports SIP with TCP, and that you're currently using UDP), that may solve it. This will mean that you move to a connection-based transport, rather than connection-less which may aid in the system 'realizing' it can't get a connection on the secondary WAN link.

I am don't know how to do that , and i don't really know how work a SIP trunk. I am not a guy from Telephony side 😅

Ask Meraki Support to apply the Cellular Failover firewall rules on the MX to the WAN2 port (rather than the cellular modem). This will allow you to create a specific ruleset on WAN2 that specifically denies traffic between your PBX and the cloud service. Hopefully this will stop the issue you are seeing occurring as the traffic from the PBX won't be able to exit via WAN2.

But it's not a Cellular connection, will it work ?

Thank you !

[Bruce]

@Babine, re. But it's not a Cellular connection, will it work?

Yes, contact support. They can make those rules apply to WAN2. It’s a back-end change - it doesn’t matter what the transport is, they just make the rules apply to WAN2 instead of the Cellular failover connection.

[Babine]

Hi,

But here i want to create a rule that deny the traffic between the PBX anb the WAN 1. Because WAN 2 is my SIP connection.

Sound good like this ?

[GregLiu]

Hi Babine,

you mean below traffic flow design:

Refer BRKCRS-2142 (ciscolive.com)

However you might need a support case to confirm.

[GregLiu]

You can using more than one SIP trunk if it is possible, depending the PBX you are using;

troubleshooting to find out why it is not working even the link failback, the phone or phone system may have log;

As for SBC you can enabled Active-Active I think, there is a call routing control, most of time, the Telco can re-route the incoming call, however, for outgoing call, it need enable Active-Active call control or Active-standby call control.

[Babine]

GregLiu,

I am not sure to understand what you mean.

I don't have access to the PBX. it's another society who manage it.

Best Regards,

[GregLiu]

Hi Babine,

In that case, and based on what you mentioned in the post;

The issue might be the failover did not work, and the challenge is it is not working even you failback to primary connection; you may need baseline your normal primary connection telephone traffic then comparing it with the failover one.

It could be same issue on below post in 2019, and it is stateful firewall related; it could be already be addressed in the new code, not sure yet; for the time being, you can try 'disable/enable BACKUP interface' 🙂 

VoIP problem with stack SIP with the MX WAN connectivity failover - The Meraki Community

My understanding is you may need a support ticket when the failback reconverge did not work.

Happy to help!

Best Regards,

[PhilipDAth]

This happens because existing established connections are not failed back until those connections stop.  In the case of SIP/UDP, those streams can be long-lived because of SIP keepalives.  If you use SIP/UDP, you are probably going to need to reboot the MX to resolve this (or unplug the second WAN circuit briefly to force all connections to fail back).

For our clients, we only use SIP/TLS.  Rock-solid.

Second choice, SIP/TCP.

Both of these options use TCP - a connection orientated protocol with connection tracking.

[Babine]

So, if we use a SIP/TCP, when the connection failover, it  will bring down telephony, BUT if the connection comes back up the PBX should be able to function again ?

[Bruce]

Yes, that’s the idea. SIP/TLS (as Philip suggests - which is better since it’s secure) or SIP/TCP use a reliable connection methodology (rather than send and forget like UDP), and so are more likely to detect a link failure/change.