Site-to-Site VPN with Sonicwall and UCM

ip-communications

#1

I need a little assistance with a site-to-site VPN setup. We did not originally setup the UCM PBX and phone systems are a bit foreign to us.

Here’s the scenario,
The client has their main site with phones and the PBX. All works well there. They also have a remote site connected via a Sonicwall SOHO 250 with a site-to-site VPN. All traffic across the VPN is allowed.

With this setup alone, phones at the remote location would register successfully using the PBX private IP. Calls could be made internally and externally with a problem - internal calls were 1-way audio (the phone at the remote location could not be heard, but the extension at the main office could be heard), external calls had no audio in either direction.

When I did a packet capture, the phones would initially connect to the PBX using the private IP, but then change to the public IP. Also note - no outbound ringing sound could be heard on the remote phones. I was able to get the system fully functional by forwarding ports 5060-5061 to the PBX at the main location. However, that seems to defeat the purpose of the VPN.

Any assistance in getting this to work without port forwarding from the public IP is appreciated!


#2

IN the UCM, PBX settings, SIP settings, NAT, insure the external host filed has the public IP or FQDN, insure that the SDP filed below the external host is checked and enter the remote locations local LAN segment along with that of the UCM into this area.

Whether or not 505 should be forwarded is somewhat dependent on the telephone service type.


#3

All the settings are set that way already.

The main issue: everything works fine if I open ports 5060-5061 on the main location’s firewall. But I don’t want those open to the public and want to use the site-to-site VPN instead.


#4

The phone service type is SIP. At the main location, phone service works fine with or without the ports (5060-5061) being forwarded.


#5

I’ve got minimal recent experience with sonicwall, but this sounds to me as if there’s a NAT issue within the firewall for outbound.

VPN traffic generally passes “behind” the firewall, so it follows rules which supersede typical firewall-to-WAN traffic patterns (which is why internal-internal calls work just fine). But outbound calls would need proper NAT’ing, which is something a lot of firewalls don’t do well at.

Untangle (a free superior alternative to Sonicwall) has a “SIP NAT helper” option in Advanced settings - just click it, and this problem disappears. Perhaps Sonicwall has something similar?


#6

Calls from the remote location to the main location only get 1 way audio. You can hear the person at the main location but not the person at the remote location. Remote location has the Sonicwall.


#7

T be clear, when using a VPN, port forwarding, SIP ALG and the like do not come into play between the extensions and UCM on the VPN tunnel. However, if using SIP as the telephone service, these settings and NAT settings do come into play.

SonicWall works well with SIP provided that it has a more recent firmware version. There was an issue from a few years back, that required a hotfix for SIP, but this has since been incorporated into the later releases.

If you have extensions that are going to be remote and outside the UCM lan, then you need to consider that all the factors that came into play setting up the UCM side of things, now come into play with the remote side. As the UCM has settings for NAT, external host and SDP, so does the remote phone.

SO, in the UCM, if an extension is going to be remote, go to the extension settings and enable NAT. If it is the only phone that will be assigned to the extension, then set “can direct media to no”.

In the remote phone, set the SIP server IP to the public IP or FQDN of the UCM. In the same account settings, network, set the network to STUN (or keep-alive if the remote site has a static IP).
In the SIP settings basic, set the registration expiration to 5 minutes or so (more a personal choice). Set the SIP Options Keep-alive to enabled with a timeout of 20-30 seconds. I normally set the unregister on reboot to instance if one device. In SIP security settings, enable "accept incoming SIP from proxy only to enabled. In general settings, set a STUN server if the remote user has a dynamic public IP. If they are fortunate and do have a static, then input their public IP in the NAT IP field and leave the STUN server field empty. Ideally, you would have the remote phone set with a reservation or static for the remote LAN.

Try this and see and advise on the port forwarding as I am unclear on what happened.


#8

I’ll explain the current setup more clearly and let me know if your instructions are still accurate.

Site A - Contains the PBX and the main office phones.

Site B - Has a Sonicwall firewall, connected to Site A with a point-to-point VPN. Computers can communicate with the server and other devices at Site A. Also contains two extensions. Extensions are set to connect to the PBX with the private IP address of the PBX.

The problem: Site A has port forwarding of ports 5060-5061 to the PBX. I want to eliminate these port forwards to increase security of the system. When the ports are closed, Site B extensions get 1 way audio for internal calls and no audio for external calls.

I hope that makes the situation clearer.


#9

Well to be certain, I will need a capture of a call using the VPN. My settings address the remote phone when not using a VPN.

If you are using SIP for phone service, then you are going to use port forwarding of one type or another like it or not. If you have the trunks set for keep-alive, they are sending a packet out and in doing so, they open a port in anticipation of a return. The issue is that if all ports were closed, how would an incoming call ever arrive at the UCM?

The desired method is to use the SonicWall and set up forwarding and the use the object rules and services to define what IPs or FQDNs are allowed to use those ports and services.

Is the SonicWall new or was it in use previously ?


#10

You outbound traffic from the phone is using your default gateway you have to set a route on the Sonicwall any traffic with dst ip of the PABX must go out VPN.


#11

Site A / Main Site does not have a Sonicwall. The firewall for Site A only allows for pretty basic configurations, such as port forwarding.

Both firewalls are new and were deployed by us. I understand what you mean about port forwarding - but the system at Site A worked fine without any ports being forwarded. Site B is brand new.


#12

SIP registration works fine using the internal IP. Wouldn’t a routing problem affect all communication to the private IP?


#13

A few questions:
What type of site-to-site VPN?
Can you ping from one side to the other and vice versa?
Is source port re-write in the SonicWall disabled?

Still need a capture to see.


#14

It’s a IKEv2 site-to-site VPN. All devices can communicate back and forth - and yes, I can ping computer back and forth on the VPN. So the VPN itself is functional.

Even the phones at Site B have successful SIP registration across the VPN, when ports are not forwarded at Site A.

Source port rewrite is not changed - I am actually using only default NAT policies. Could that be part of the problem?

I don’t have the packet capture data and unfortunately no one is at Site B today to capture a phone call. But when I looked at the capture previously, it showed that the phone was trying to connect to Site A’s public IP during a call, instead of the private IP. Naturally, without port forwarding, the public IP won’t work. I’m not sure what would cause the phone to try communicating on the public IP, even though it initially connects via the private IP.


#15

Source port rewrite impacts the audio, but not the public/private IP aspect. Yes, it needs to be changed. I read what you say, but that does not tell me why without looking at the capture,


#16

You are correct or how else with the original registration with have taken place. it is exactly what I thought when we first had this problem. If you have multiple paths and the metrics set or changed it can be the reason

non the less a quick internet search will reveal many have had similar problems with sonicwall.
although below link it not grandstream related it may help you move your trouble shooting closer to the source of the problem.