7100 with 8 MGI Channels, 4 Analogue trunks. 8 iDCS phones and one 3105 at the main site and 4 SMTi5220 at a remote office.

We've been working through a VPN tunnel and it has been flawless. However, they are noticing problems with the data connection on the tunnel so they would like to move the phones off the VPN tunnel. First step, change the ip address to private with public.

As soon as I do this we loose audio on all the phones at the remote office.

Reconfigure the phone to access the system via the public address and have the same problem.

We have the 30000~30015, 40000~40015, and the 45000~45015 all forwarding to the OS ip address.

Any ideas what's going on here?

All help, greatly appreciated.

When you say you are losing audio, are you just losing the speech path or signalling as well. Is time and date good on the IP sets? What I normally do is put the 7100 on the DMZ and make sure all works and then back through all the port stuff if it does work on the DMZ using a port checker tool to verify all ports that should be open are. Sorry clear as mud, I hope you understand what I'm saying.
Good Luck,

Try it with MPS off, as you may be missing some ports there.

We tend to put the full range in unless its a 2 cab 7030.
30000-30031
40000-40127

Mmc838

Put the ip range of the remote site in (192.168.1.255)

That'll fix the issue until you reconfigure the phones to use the public ip

Ok,

Thanks!!!

Adding the Ip addresses to 838 did the trick for local phones.

For remote phones, the IT guys tell me the forwarding is in place but I am trying to connect a phone from here at my office first and though I can get the time and extension up and dial the other stations, again, I have no audio.

Ideas?

-W

Ok,

Tried scanning the ports using nmap and they all seem to be open.

Still have no audio.

-Will

When you look in programming, what audio ports on listed in the extension info? Does it show 9000?

For IP phones connecting from not inside a VPN you need to have ports 6100 6000 9000 9001 forwarded to the processor IP. I recommend doing both UDP/TCP that's my opinion. Make sure that you have the public IP assigned in Public address 1 section of lan parameters.

All the ports are set to forward to the system and show open with an nmap test.
In this instance, the internal ip addresses if the main system is 192.168.1.xxx and the remote site, currently connected through VPN tunnel is 192.168.3.xxx
Should both ranges be in 838?

public IP address showing correctly in 830 and mgi configuration (it's a 7100 so it propagates)

Are those IP phones white list enabled? If they are, did you add the public ip address of the remote site in mmc875?

No whitelist here. Though I did add the public ip address of the remote connection just to be safe.

Those SMT-i5220 IPs are not listed on mmc838, right? If they are, remove them.

Also, please try port forward the below ports:

30000-30031
40000-40031
45000-45031

It does sound like the MGI port's aren't forwarded.

What Temperor says is correct for the 40000 and 45000 range.

MPS/RTG each use 4 ports per channel, you have 8 MPS/RTG channels on a OS7100 so 4 x 8 = 32 you need to goto 4x031.

MGI only uses 2 ports per channel, so 2 x 8 = 16 so 30015 is the end port.

You will also need UDP 6000 forwarded.

You said that MMC838 fixed the issue for the "local" phones, it shouldn't have had any affect on these (unless they are in a different subnet to the system).

You only need to put the remote range into 838 until you change them to register via the public ip address.

The "local" phones are at a remote site but connected over a VLAN so they did have a different subnet. It was a bit strange that they worked fine with nothing in 838 when the system was set to private, but audio conked out when we changed it to priveate w. public.

Not at all.

Since 4.4x software when you have private with public enabled the system assumes anything outside of the subnet of the MP/MGI cards has to use the public address.

Private only has no public ip address so doesn't assume this.

You override this behavior with MMC838. This also applies to SPNET and SIP Trunks in some circumstances.

Prior to 4.4x you could manually select in the ip phone/spnet config whether it was private or public.

I don't know the reason for the change, but i suspect it has something to-do with MPS.

This question gets asked a bit, I might make a sticky.

I forgot to check in. That did the trick nicely.

Now I'm having issues with the same system (updated to 9.5) and remote IP phones.

I can connect to the server, make calls using the sip trunks, but when I call or intercom to one of the digital phones on the main site, there is no audio.

Is it necessary to set forwarding on the network at the remote site at all?

-W

It sounds like an MGI issue.
You do have the MGI ports forwarded?

IP phones to sip trunks will use MPS.

No, you don't need to forward on the remote network.

Yes, the MGI ports are forwarded.
I ran a wireshark on the phone side and it had a few entries that showed the phone sending requests to the local IP of the OS and the info looked like 9000-->40018 LEN=32

How are these phones connecting to the system, using public ip or vpn from site to site?

Biztel: we are using a Public ip.

Now just for kicks and giggles I placed a newly factory reset router on a raw Internet connection and it all worked a treat. So it should follow that the issue is with the router on the outgoing side. Is no ports are specifically blocked so, any idea what might be stopping it?

If you are using the Public IP address of the system in the IP phones then make sure that it matches the entry of the Public address in the system Public address 1 slot. This would allow the phone to connect but no audio, if the IP's don't match up. Since you have tested the system behind a new out of the box router and things work without a hitch, then yes it is lead to believe that the existing firewall is causing the issue. Have them look at the port fowardings again. The main ones for IP phones are 6100, 6000, 9000 and 9001 all pointed at the processor. I do both UDP and TCP just to make sure. This may be a pain in the behind for some network people to do, but it's better than all them MGI ports.

The reason it is showing this, is because for IP phones port 9000 is the Audio port that it connects to. Forward that port just like the 6000 and you should have audio.

Your issue is that you haven't forwarded enough MPS (40000) ports.

You said you forwarded 40000-40015

Your wireshark trace shows the phone sending RTP packets to 40018 which you don't have forwarded.

Each MPS channel uses 4 ports, Each MGI channel uses 2 ports.

You need double the amount of ports forwarded with MPS then you do with MGI.

Port 6100 is used for SPNET and is TCP.
Port 6000 is used by the IP handsets to register to the system

Ports 9000 and 9001 are used by the phone to receive RTP and RTCP packets respectively, They don't need to be forwarded.

As you are calling from IP to IP it will use the MPS ports.
IP to TDM will use MGI.

I have a document from samsung here about the MPS function I can send if you want.

Nameless can you PM that documentation about MPS. Also I have a question to ask you in private about this subject. I want to clarify something before speaking of it in here.

pm sent

Thanks guys,

Sorry about the delayed response, things have been crazy busy. I really appreciate your help.

I've asked the IT guys to adjust the forwarding.

Another strange one though. The remote phones that have no audio are showing the Gateway address of the main site in the IP address field of 6.2.2 rather than the public IP of the remote site.

Would this be caused by VLAN configuration?

Thanks again!

It's a routing issue. The traffic is going over the vpn then out the main site internet connection, then back in again.
Some routers/firewalls have problems with loopback traffic.

If the traffic is going over a VPN then just connect to the internal IP address of the phone system using the phones. This should then allow for all audio to be passed if the VPN tunnel isn't blocking any ports.

Correct, assuming the phones are programmed to use the local address of the system

Correct Nameless. I would suggest it this way better since all the traffic from the other site is going through the VPN anyways. That way it doesn't create a loop.

That makes sense.

If I could have this phone on a VPN, I would.

This is for an accounting firm and sometimes they will set up at a client's office for a week or more. They would like to be able to take a phone with them and connect back to the main office, so there would not be a VPN for that connection.

How would I best communicate to the IT folks what the problem is so they can address it?

-Will

Perhaps they can Vlan the phone out to a different address and subnet not going through the VPN... That way it will pick up a new address and just use the public internet on site versus having the traffic travel through the vpn. Or if they are kinda tech savy, teach them how to go in and change the server address for when they move to a different location.

Not sure I'm clear on what you are suggesting Biztel.

If we could put this phone on a VPN, there would be no problem, we could use the internal address. But using a phone on a remote site that is not VPNd back to the main is the issue.

All the phones that are VPNd are addressed to the local address of the KSU and work fine.

It was a different solution that possibly wouldn't apply. I would try nameless suggestion of forwarding the ports for MPS/RTG to the cards. If you hadn't already done those.

I am curious, what kind of Firewall are they using at the site of the system?

Ah, yes. This site is a 7100, so only one IP to deal with.

The firewall they are using a Fortiwifi30D.

Cheers,

Only if you're using the onboard MGI. If you have a OAS card, then you will have 2 addresses to deal with. The internal one for the MP and the one for the OAS card.

I do appreciate that having all the phones inside the VPN would be preferable. The two remote offices are configured like that and work pretty well.


What I am hoping is to see if we could find a way to have a phone from outside the VPN connect and function.

So if a phone is coming from the public internet to the (.1.xxx) network that is part of the VPN, something in the translation replaces the public IP of the phone with the local IP of the router.

This results from what I can surmise in the phone system not being able to send back any voice traffic.

If that is a loop, what would be the best way to relay that info to the IT folks?

Naturally if a phone is connecting to a system using the public IP then it will route that way. Regardless if the 2 networks are using a VPN tunnel to talk to each other on a local subnet. Therefore if the phones will connect to 10.x.x.x as a public IP then the system will look for traffic forwarded from that. Doesn't matter if there is a VPN or not.

It seems that maybe the MGI ports are not being forwarded correctly if the audio isn't passing. Or the public IP set in your OAS card isn't the same matching the one for the MP10a. I would double check these settings. Also, what are your Port ranges for the OAS card and the ones for the MP10a as far as MGI goes?

You'll need to put the vpn offices address ranges (x.x.x.255) into mmc838.
That way they will still work over the vpn when you enable private with public.
This will have no effect on the public registered phones as they will report the public ip of their internet connection to the system

Reviving this a bit as we move into Tax season they are asking for the possibility of the setup.

@Biztel, no OAS card here, just the onboard MGIs.

VPN offices are working fine now thanks to that entry in 838. System is set to private with public.

Phones outside the VPN can register but no audio.

Thanks!