SIP and NAT in MX

[Kave]

Hi everyone.

i can not understand how it is possible SIP/RTP packet comes to my MX  without any Firewall rule/NAT rule.

MX suppose to be designed to prevent inbound unknown communications, and NAT stops users on a LAN from being addressed.

but now in my network SIP Trunk carried by my public IP and access to MX's inbound without any rule, how it is possible?

[PhilipDAth]

If you create a NAT rule to allow the traffic inbound it silently creates a rule to allow that traffic. 

[Kave]

Thanks, Philip, but as I said I have no NAT rule in MX, how SIP can see my phone?

My question is how it is work without any NAT rule?

[PhilipDAth]

Any chance it is not in fact a SIP trunk but using SIP registration instead?

We only use SIP registration ourselves because it does not require any NAT configuration.  It's just a simpler config.

[Kave]

What is the difference between SIP trunk and registered SIP?

[ww]

when the client inside your network initiates the session there can be active communication.

when a outside pbx try to initiate a session to a device on your local network it is blocked.

so (i assume) you configured or you got a pre-configured phone that registers to a public voip solution?

[PhilipDAth]

>What is the difference between SIP trunk and registered SIP?

With SIP registration the device reaches out to the provider and says I'm responsible for this number "x" please send me the calls.

With SIP trunking you statically configure the static IP address of each system in the other and statically configure the number routing.

[Kave]

Hi philip, Thank you for your explanation.

I assume we have VoIP getaway outside of our network, and it using NAT traversal.and because we have automatic NAT-T in meraki MX so it does not need any configuration.

[WillN]

The client registered SIP phones usually have a small outbound connection to the cloud (to listen for incoming calls) and passes keepalives outbound to keep that little connection up and running. Any calls coming in are actually "return" traffic to the SIP phone in question and is therefore "solicited" traffic.

SIP trunks usually have a switch that builds what is essentially a VPN tunnel to the Cloud gateways. Phone calls coming in land on that switch and it's responsible to delegate to one of the phones connected to it. Because of this 3rd party VPN these trunks can be a little bit harder to configure and may require assignment of a public IP.

Looks like you have lucked out and have the SIP service that doesn't have any of that complex nonsense.