MBG in DMZ no SIP signaling out and one way audio

[GZgidnick]

Referencing post: Link

Same as reported in the previous post, SG Configuration works fine. DMZ does not.

MBG IP: 172.18.5.13

​

Set-side streaming addresses 120.X.217.182

​

Icp-side streaming addresses 120.X.217.182
MCD IP: 172.18.2.20

All traffic between the two VM is allowed and they communicate successfully.
On outgoing calls one way audio and disconnect as no SIP messages are conveyed out from the MBG to the SIP Carrier.
Incoming calls don't work (dead air and disconnect after 20 sec - timer) as no SIP messages are conveyed out from the MBG to the SIP Carrier.

There is the SIP flow on incoming call:

More precisely, MBG doesn't proxies the 180 Ringing received from the 3300 onto the SIP Carrier. This causes the SIP Carrier to issue CANCEL message after 20secounds timeout expires.
As it can be seen, the MBG doesn't proxies out the SIP messages received form the MCD. This puzzles me....

 

[Billz66]

MBG IP: 172.18.5.13
Set-side streaming addresses 120.X.217.182

Shouldnt the ICP side be set to this address
Icp-side streaming addresses 172.18.5.13



If I never did anything I'd never done before , I'd never do anything.....

 

[GZgidnick]

No. When you run MBG in DMZ is sets both IPs, ICP and SET SIDE included to the public IP address of the internet facing device (firewall)
At least thats what Mitel states in their EG.

 

[Mitelmatt]

I agree birth Bill, I always change mine to custom and set the icp side to the internal mbg address. Otherwise you will need an inside and outside nat

 

[GZgidnick]

I already have the SNAT and DNAT rules in place.
Firewall doesn't blocks anything. The signaling path is going from the LAN direct to the External IP of the firewall, through its own gateway completely bypassing the MBG.
I would expect every SIP message to be directed from the MCD onto the MBG (Internal IP) but thats not the case apparently which brakes everything

 

[boycey9]

Maybe your firewall is SIP Aware, try turning this off

 

[wireman50]

This is why I always ran MGB in server/gateway mode; saves a lot of angst. I have a couple that are run behind a firewall with all the ports opened up but the IT guy had a small fit hwen he saw how much work he had to do on the firewall. YMMV

 

[Billz66]

we normally override the internal streaming to be the internal address
then allow all the required ports into the MBG from outsode

we dont rstrict the internal address from internal network

If I never did anything I'd never done before , I'd never do anything.....

 

[danramirez]

MBG eng guidelines are very clear: disable any sip helper and ALG at the firewall. Firewall do inspect SDP protocol and rewrites packages. Please try disabling this

http://www.hatkana.com

http://www.wtelecom.com

 

[GZgidnick]

The firewall is indeed SIP aware but all SIP features have been switched off.

I did some extensive packet tracing to find out the issue was a consequence of a routing issues.
The only way one can have this running is by applying fair bit of static routes and having all his networking fairly messy.

as @Blllz66 stated the only way make this working is by overriding the icp-side with MBG's local IP's. THis effectively puts MBG into custom conf.
I find Mitels docs and guides on this deployment to be very misleading.

Lets suppose you have MBG in the DMZ.
MiCollab and MiVB live on the LAN.
DMZ is different that your LAN.
MBG has single interface for all comms private and public.
The firewall is the public facing interface.

LAN = 192.168.0.0/24
DMZ = 192.168.100.0/24
Public IP = 1.2.3.4

When MBG is put into DMZ mode, it scans for the public IP and sets both ICP-side and Set-side to the public IP: 1.2.3.4

Now lets say MiVB has IP: 192.168.0.2 and MBG has IP: 192.168.100.2.

Because MBG is setup to Proxy all request for MiVB, whenever MiVB has outgoing packet ready to be send to external SIP networks will send this packet to MBG's public IP: 1.2.3.4.
As this is public IP, MBG will send the packet to its default gateway, lets suppose 192.168.0.1.
The Default gateway, whether the same device (router on stick) or a different device, will try to get the packets to the firewalls public IP address (1.2.3.4). This will often fail with "no route to host" or if there is an route and the packet manages to reach the Firewall public interface, will bypass the MBG completely hence the signaling session will not be maintained and often teardown with an expiry timer.

By overriding the ICP-side with MBGs local IP: 192.168.100.2, MiVB sends the packets onto its local interface through its default gateway. MBG receives the packets, replaces the IP addressing and sends it out to the external SIP network. All good.

Hate whinging, but this tad bit of logic should have not been omitted from the documentation.

 

[wireman50]

Isn't there an "overide local IP's" in MGB programming somewhere (I think its its in a submenu but its been a while since I did one).

 

[Billz66]

Its in the network profiles - set to custom and set them as suggested
ICP = LAN , Set SIDE = PUBLIC IP

If I never did anything I'd never done before , I'd never do anything.....