Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 3 subscribers
  • Views 16610 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Correct NAT for Remote IP phones?

TomMorgan

I need to setup NAT for a NEC SV9100 phone system. This a primarily a digital phone system with a couple of remote IP phones. For the IP phones, I was instructed to "forward" the following:

UDP 5080-5081 to 192.168.50.12 (IPLE/signal)
TCP 8000 to 192.168.50.12 (Remote management)
UDP 10020-10531 to 192.168.50.13 (DSP/voice)

I've setup the service & networking definitions, NAT & firewall rules. The only service that works is the remote management. The remote phones register with the phone system and produce dial tones but they do not make voice connection. The firewall logs show no RTP/RTCP traffic whatsoever (ports 10020 & 10021) nor to the voice IP (192.168.50.13).

Position: 1
DNAT Any -> 5080:5081 -> WAN (address)
Change the destination to: 192.168.50.12
And the service to: n/a

Position: 2
DNAT Any -> 10020:10531 -> WAN (address)
Change the destination to: 192.168.50.13
And the service to: n/a

Position: 3
DNAT Any -> 8000 -> WAN (address)
Change the destination to: 192.168.50.12
And the service to: n/a

What am I missing?

Thanks! Tom



This thread was automatically locked due to age.
Parents
  • 0

    HI, Tom, and welcome to the UTM Community!

    Does that system not use SIP? Also, per #1 in Rulz, check the Intrusion Prevention log for Anti-UDP-Flooding activity.

    Cheers - Bob

  • 0 in reply to BAlfson

    No, this system has all internal digital phones, no SIP trunk. The installer (& NEC) claim that we only need NAT on the router & dynamic NAT configured on the IP phones. I followed the instructions implicitly but no joy. Support tells me it's in the routing and I believe it. Once the correct NAT is applied, these remote phones should be plug-n-play.

    I found the Rulz last week (brilliant!) and cannot find any violations in #1, #3 or #5 except I'm not sure how to apply a Masquerading rule in this instance since it's technically not a "network". And QoS doesn't apply since it's not "real" SIP but some sort of proprietary NEC VooDoo (I guess).

    IPS has been clean, no flooding, just some momentary random SIP port scanning in the firewall log here & there. It should work.

    I was hoping for a magic SNAT solution since I can't think of anything else.

  • 0 in reply to TomMorgan

    What if you turn on logging on those DNATs - do you see the traffic coming in?  If you do, then I bet the problem is the default gateway configured on the .12 and .13 servers.  Any luck with that?

    Cheers - Bob

  • 0 in reply to BAlfson

    Thanks, I'll try the logging when I'm back at my office. I've triple checked network settings on both sides of the call, gateway is good. I did get this pic from the installer today of the traffic flow of a successful call on one of their phones. It looks like SNAT may be necessary on the UTM but I'll look at traffic first as you suggest...  Tom

     

Reply
  • 0 in reply to BAlfson

    Thanks, I'll try the logging when I'm back at my office. I've triple checked network settings on both sides of the call, gateway is good. I did get this pic from the installer today of the traffic flow of a successful call on one of their phones. It looks like SNAT may be necessary on the UTM but I'll look at traffic first as you suggest...  Tom

     

Children
  • 0 in reply to TomMorgan

    Just so that the community doesn't think I've blown this off;

    I've made no progress with this issue but had to stop since our old ASG 220 was nearly out of resources with everything it was used for. Have since upgraded to a Sophos SG and requisitioned a couple of port mirrors to help resolve this problem. One thing at a time... more to come.