NAT 1:1 Polycom VSX 7000
-
It is impossible for anyone to know whether that range of ports is accurate or not.
Did you tell your conference server to use 189.20.108.XX as its address in the SIP sessions?
-
Illustration 1: Graphic scheme
Step 1
Let's now create a virtual IP for the WAN interface, which will be the public IP that will receive the external calls, which in turn will be redirected to the videoconferencing equipment. Do this by adding in Firewall -> Virtual IPs, editing as shown below.
Step 2
Create a 1:1 NAT on the Firewall -> NAT tab 1:1 to redirect external calls to local equipment as illustrated.
Step 3
TCP_VideoConference ports, with the following TCP ports: 1720 (H.323 Call), 1731 (Audio Call Control), 5060 (SIP), 53 (DNS), and 1024: 65535, high TCP ports used for data sending (Illustration).
UDP_Videoconferencing ports, with the following UDP ports: 5060 (SIP), 53 (DNS), 123 (NTP), and 1024: 65535, high UDP ports used for data sending (Illustration).
Step 4
Now it's time to set the firewall rules. First for DEDICATED interface. Go to Firewall -> Rules, DEDICACO tab. See illustration.
Best regards,
Wesley Santos -
That all looks fine, though I doubt all of those ports need to be both TCP and UDP. But:
There is no way for anyone here to know if those are the ports you need to have open.
None of that has anything to do with configuring your video conferencing solution to tolerate the NAT.
It does not cover any static outbound NAT ports your video conferencing solution requires, and there is no way for us to know what those are.
-
Below is an illustration of the doors to be released, this information is official from the manufacturer's website.
https://support.polycom.com/content/dam/polycom-support/products/telepresence-and-video/vsx-series/user/en/vsx-series-admin-guide.pdf
-
As usual, the VOIP documentation is woefully-inadequate. pfSense will not alter the destination port so something like 80-Static is meaningless. Are those inbound or outbound connections?
-
Can you give a clearer example based on my information?
Best regards,
Wesley Santos -
Not really. It is up to your VoIP vendor to give you accurate information. It looks like you have done what needs to be done based on what we have been shown. Impossible to know what is inbound and outbound as they don't specify. Have you talked to them?
-
@Derelict said in NAT 1:1 Polycom VSX 7000:
Not really. It is up to your VoIP vendor to give you accurate information. It looks like you have done what needs to be done based on what we have been shown. Impossible to know what is inbound and outbound as they don't specify. Have you talked to them?
It's a very old equipment, I don't have support anymore.
-
Dear,
Regarding the source, it is not possible to determine which, as can be done from any Polycom client, already with destination address, is pointed to my local host.Best regards,
Wesley Santos -
Hello, does anyone have any suggestions what I can apply in this case of mine?
Best regards,
Wesley Santos -
Most current VoIP solutions have figured out that things like SIP helpers are bad news and have coded some smarts into them to deal with NAT more gracefully. The situation was certainly worse when "very old" equipment was being manufactured.
You're going to have to packet capture your SIP sessions and get down and dirty, learn the protocol, and see what NAT needs to happen and where. Essentially reverse-engineer what your particular environment needs (they are all different).
-
Is it possible to configure without using nat, but passing all traffic from polycom through my pfsense?
-
Sure, if you don't need to use NAT and have a routed subnet you can put the PBX on.
-
You might want to hire someone familiar with VoIP to set this up for you.
-
My intenet link, with valid public ip's, can I use one of these ip's to release this traffic to polycom?
Best regards,
Wesley Santos -
If they are routed to you, sure.
If they are on the WAN subnet, you'll have to go to other lengths like make a silly WAN bridge.
I would do everything I outlined above and make sure what the problem actually is first.
You could do all that and the issue isn't NAT at all.
You really need to understand what your VoIP system requires in order to deploy it successfully instead of guessing.
-
I think the problem is with NAT.
Already configured the WAN subnet direct in polycom, without going through my pfsense, worked successfully.Best regards,
Wesley Santos -
I would use an IPAlias rather than a ProxyARP VIP though it probably doesn't make any difference.
By far the most likely cause is that the Polycom device is sending it's internal IP in the contact packets for other devices to connect back to which will obviously fail. When you use a public IP on it directly it sends that so everything works.
If that is the case you need to set the Polycom to send it's external IP when it's behind NAT. Almost all VoIP devices have a setting for that. There's nothing we can do in pfSense to correct it.
A packet capture would likely prove that to be the problem.
Steve
-
Hi Steve, how are you?
Thanks for your return.
According to your suggestion of using IPAlias, I already set it up, but it was not successful, the same problem occurs when configured with ProxyARP.
Regarding the configuration of sending NAT to Polycom, it is also already configured, but there were problems sending and receiving calls.
My Polycom dials external, but with black video, it also receives an external call, but does not automatically connect as it should.Best regards,
Wesley Santos -
Ok well really you would need to get a packet capture of the SIP packets to check that it really is sending the external IP in the SIP connection to open replies to.
There is probably something similar there for the other services but we may not be able to see it.Steve
