SIP and Meraki MX issue with invite '"via" going out as private IP and rejected by carrier 1

[trinetintl]

We replaced a very old Juniper firewall with a new Meraki MX67 firewall, when we repalced the firewall we did not know we were going to have issues particularly with the SIP trunks, we were expecting a simple equipment replacement but apparently this particular SIP trunk carrier requires ALG and it seems Meraki does not support ALG functionality. We have tried every configuration under the sun without any success, we are really hoping somebody out there has the magic key that can help us unlock this door.

Can the IP Office be programmed to force the invite via with the correct IP without having to put the IP office LAN2 port with a public IP and having to bypass the firewall? As a side note, the SIP trunk is currently unregistered, will it make any difference if we ask the provider to switch the SIP trunk to a registered SIP trunk? In other words, will the "via" private IP on the invite issue go away if the SIP trunks is registered instead of unregistered? This particular IPO is currently on release 8.0.

The SIP Invite reaches the MX from the client with the "via" source of 192.168.1.200. In the screenshot titled "wan_sip_invite.png", you'll see that the MX NAT's the source IP address of the packet to the WAN IP of the MX to route it across the public internet, however, the MX does not alter the "via" source that the client sent, as we do not expect the MX to alter the data within the actual SIP invite.

The failed cal issue the invite as "Via: SIP/2.0/UDP 192.168.1.200:5060;rport;branch=z9hG4bK107c414cb9d122120aafc9a7a1ef6128". Correct invite should include the public IP instead of the private IP (highlighted in bold) that the carrier is expecting, when the Juniper is on, it works fine.

Any help will be greatly appreciated.

RE

http://www.trinet-intl.com

APSS, AIPS

 

[TheSmash]

Pff, release 8.0? That's going back some way...

Yes you can probably do something buts as it's such an old version I'm not sure it'll be the same.

On the SIP Trunk, on the transport TAB, set it to Use Network Topology Info of Lan1/2 appropriately.

On LAN1 or 2 (whichever you are using), on the System > LAN > Network Topology set a STUN server (like 146.101.248.221), Firewall/NAT type to Unknown, Binding 60 seconds, and enter your Public IP that your SIP provider is expecting. Fill in the public Ports UDP 5060. Don't set STUN on Startup for now. Save and reboot and it should use that IP now in the SIP packets.



ACSS (SME)

 

[trinetintl]

TheSmash, I was reading and wondering about the Network Topology Info but I was having some doubts because the site only has 1 public IP address. Will the communication work if I configure the LAN2 IP address with the one the carrier is requesting even tough from a network configuration point of view the setting that will be on LAN2 is not going to work? Can LAN2 be simply used to supply the invite source or via but keep traffic flowing through LAN1?

Is the STUN server a separate second option or does it have to be combined with the transport configuration?

How much of a security risk, safe or unsafe is it to use a public STUN server? I have never had to use a STUN server before and I have never taken the time to research the topic in order to understand what it is and how it works. We are somewhat skittish about using anything public particularly when it comes to voice calls because we have been badly hacked in the past.

RE

http://www.trinet-intl.com

APSS, AIPS

 

[TheSmash]

You won’t be able to split the traffic like that.

Setting the Network topology doesn’t mean that the IP is on that interface, it just instructs the IP office how the network is configured and how to format the SIP packets. The traffic is still NAT’ed by the firewall from its internal IP.

STUN is an automatic way to discover this and there is no security risk you need to concern yourself when using one. It just generates UDP packets which are formatted in different ways and listens for the responses. From that it tries to work out what kind of NAT is being used. However it’s not a perfect tool as it doesn’t know what your ITSP is expecting so doesn’t always help. Manually setting the topology (as I instructed above) is a way of getting what you want when you know both the NAT and ITSP requirements, which you do.

If you are concerned about security and having experienced being hacked, then I’d suggest you seriously consider deploying SBCs. That will sort out the NAT issue for you and provide an additional layer of security.

ACSS (SME)

 

[trinetintl]

TheSmash, I went digging in a bit more and I went onsite to try to figure it out by myself and many of the questions I posted I was able to clarify with the help of the IP office that didn't stop popping up configuration warnings until I finally got it right. The tips you posted seemed to work right out of the box, I used the STUN IP you suggested and I could see the invite via properly formatted however the carrier continued to reject the call with a 403 Forbidden.
I made a couple of changes to the configuration; the first one was to add the port forwarding on the Meraki MX that was previously removed, after that change was unsuccessful, I clicked on the "Run STUN" button just for kicks, after it finished running, the Firewall/NAT Type changed to "Full Cone NAT" and all of a sudden I noticed that the 403 Forbidden in system status was not showing up any more and started noticing inbound calls that used to ring but without audio being parked. Run some inbound and outbound test and everything worked OK.
I saved the configuration in order to keep the new network topology/STUN setting and so far we are good to go. Do you know if I need to check the Run STUN box on startup or we are good to go the way we are?

RE

http://www.trinet-intl.com

APSS, AIPS

 

[TheSmash]

As long as you don’t make any network changes you are good to go. Glad my suggestions helped.

ACSS (SME)

 

[sizbut]

Star for you Smash. And whilst we're in the area, an excellent page for how to turn of alg on a range of common routers (

https://www.voicehost.co.uk/help/sip-alg-and-why-it-should-be-disabled-your-router).

Stuck in a never ending cycle of file copying.

 

[trinetintl]

Thanks for the link, I glanced at it and it looks very informative, I will keep it in mind as a future reference. Unfortunately and to my bewilderment Meraki does not support SIP ALG and the issue we encountered was reported on a post I found back in 2016 and they did not do anything about it. We like Meraki, it has made our deployments much easier to mange and troubleshoot, we also understand that it is expensive but we expect good quality, service and reliability from premium equipment.

Thank you for providing the update from the VoIP provider. Can you confirm if they are looking for Application-Level Gateway (SIP ALG) functionality? It would appear that they are expecting the MX to alter the data within the actual SIP packet from the client on the LAN, however, we do not support ALG functionality. Please see the following documentation for further information regarding this feature and compatibility with the MX:

https://documentation.meraki.com/zG...X_to_meet_my_voice_provider's_requirements.3F

RE

http://www.trinet-intl.com

APSS, AIPS

 

[sizbut]

The gist of the web link is all ALG is a pain because every manufacturer's version of ALG is different.

Certainly when you have something like an IP Office, you need to be able to set what the box at your public/private border does to the traffic with a bit more control than a simple ALG on/off. If your router/firewall/SBC doesn't allow more than that then it really isn't up to the job for a business server unless, as fortunately has worked for you, STUN has provided a workaround.

It gets harder at the user end if you have remote extensions since there you'll typically encounter a variety of domestic internet routers. Usually that's okay when its just one remote extension behind the domestic router but the real pain can start when a customer tries to have multiple remote extensions behind a domestic router that an ISP has provided since if issues start to occur you'll rapid find that whatever router it is it won't provide many options to fix the issue (the ISPs choice having been mainly driven by can I rebrand it, does it work for me and is it cheap) and you're stuck trying to persuade the customer to install some replacement that you hope both works with the ISP and fixes the issue. If you have any inklings that you may have a customer who's inclining towards having any office of remote users separate from the switch, you need to insist on your preferred router (or one from a list of preferred routers) at the remote site. And I need to stop wittering, especially since its only Tuesday and I've clearly already drunk enough coffee.

Stuck in a never ending cycle of file copying.

 

[trinetintl]

I agree with you but we never had any issues with Meraki and ALG in the past and we have deploy sites under Meraki control with all sorts of SIP trunks from Internet based to national carriers with SBC and without. This carrier is a local carrier, their corporate office is just a few blocks away from our office but they really do not like to do SIP that much, this customer had SIP and they kind of had to do it in order to close the fiber optic sale. I have a feeling that if we can have them switch their SIP trunk from unregistered to registered the ALG issue with the Meraki will probably go away.

Now that you mention remote extensions, this is why we like Meraki so much, they have an appliance/firewall designed for remote sites that even comes with a PoE port and WiFi ready to go, you ship it to the remote site with the phone, user plugs it in like a PC to the network, plug in the phone to the PoE port of the appliance and with 2 clicks you configure the VPN-to-VPN tunnel and you are off to the races, voice VLAN or no VLAN, remote extension turns in to a regular extension, no complex VPN tunnels between the phone and the firewall to configure, easy-peasy.

I do appreciate the help, thanks!!

RE

http://www.trinet-intl.com

APSS, AIPS

 

[TheSmash]

That’s the thing with Meraki, they trade configurability for simplicity. A bit like Android vs Apple iOS. Meraki with Meraki works like a charm, but try and get it working with other Standards based systems and you quickly find your options runnng out. Just a basic IPSEC VPN you quickly find that you are asking, “OK, what CAN the Meraki do and we’lol strip it back to that”

ACSS (SME)

 

[trinetintl]

Yes sir, you are correct, been there, we have not been able to spin a IPSEC VPN tunnel directly between an Avaya phone and the Meraki MX the same way you can do it with SonicWALL, Juniper and other firewalls, and like you say, if you use another Meraki such as the Z3, like I said on a previous post, literally with 2 clicks you are set and ready to go, helps to avoid having to spend the time to read through all sorts of documentations half explaining how to setup the firewall.

RE

http://www.trinet-intl.com

APSS, AIPS