VOIP Vs VPN
-
Hi guys, i'm new in this forum
i have a question about VOIP,
let's have a look in my current situation, i have 2 location : main office and branch office connected together with site to site VPN, in the main office i have small network 25 computers (soft phones) and one IP PBX,
in the branch office i have 8 computers (soft phones)
the IP PBX in the main office is connected via ISDN connectivity (E1 10 channel)
the computers in the branch were registered successfully in the IP PBX (which is located in the main)
when i call an extension from the main to the branch or from the branch to the main i can hear the dial tone and the call is established but the problem is after the call was established i cannot hear anything in both sides and after a short time the call end automatically
IP PBX : Ozeki Phone System XE
VPN server : pfsense -
I have no idea on your PBX specifically, but you are likely not routing everything correctly. Either The VPN is not excluded from NAT or RTP was not routed correctly. More details of the network configuration would be needed to give a more realistic answer.
-
Is there any sort of firewall or limiting factors "inline" in the VPN? Typically a VPN will be a wide open channel between one location and the other, we would expect the two locations to act as if they were local. Is there NAT translation going on, perhaps? That will cause all kinds of issues.
-
i'm using OpenVpn so i have a dedicated virtual NIC for VPN and all port are opened in this virtual NIC, as for RTP, how can i routed it correctly because really i didn't make anything regarding this protocol
best regard
-
@IT-ADMIN said:
i'm using OpenVpn so i have a dedicated virtual NIC for VPN and all port are opened in this virtual NIC, as for RTP, how can i routed it correctly because really i didn't make anything regarding this protocol
best regard
How does the machines at each site route over the VPN?
-
i have 2 different networks 192.168.1.0 in the main and 192.168.2.0 in the branch, so each pfsense box route between 2 different network
-
@IT-ADMIN said:
i have 2 different networks 192.168.1.0 in the main and 192.168.2.0 in the branch, so each pfsense box route between 2 different network
Any NAT going on or are both networks addressed publicly to each other?
-
in the beginning the branch box address the main box with it public ip, once the main box validate the key installed in the branch box the tunnel is forwarded automatically to openvpn interface which is virtual, in this virtual interface all port are opened
i hope i was clear -
@IT-ADMIN said:
in the beginning the branch box address the main box with it public ip, once the main box validate the key installed in the branch box the tunnel is forwarded automatically to openvpn interface which is virtual, in this virtual interface all port are opened
i hope i was clearWhat I am trying to determine is if every 192.168.1.x address can communicate directly with ever 192.168.2.x address. Can, say, 192.168.1.15 talk directly to 192.168.2.34? And vice versa?
-
No Mr Scott
unfortunately if 192.168.2.x want to talk to 192.168.1.x the following will happen : 192.168.2.x hit pfsense then pfsense route into 10.10.10.x then 10.10.10.x hit 10.10.10.1 (gateway of the branch pfsense) then 10.10.10.1 forward the packet internally into 192.168.1.x
soooooorry if i was not clear -
@IT-ADMIN said:
No Mr Scott
unfortunately if 192.168.2.x want to talk to 192.168.1.x the following will happen : 192.168.2.x hit pfsense then pfsense route into 10.10.10.x then 10.10.10.x hit 10.10.10.1 (gateway of the branch pfsense) then 10.10.10.1 forward the packet internally into 192.168.1.x
soooooorry if i was not clearThat's your issue. There is no connection for the voice traffic. There is no means for the SIP connections to set up your RTP connections. SIP does not carry any traffic itself, it just handles setting up the calls - which can cause a handset to ring. But once you pick up the call SIP hands the call over to RTP. But since you don't have a connection between the two sites to talk to each other, SIP has no way to tell RTP where to send the voice traffic.
You need a VPN tunnel from one site to the other. What you have is a VPN that is firewalled in the middle. VoIP isn't going to play nicely with that, there is no means of establishing the connection.
-
so what i understand is: i should configure pfs to forward VOIP traffic to it destination without any NATing,
-
@IT-ADMIN said:
so what i understand is: i should configure pfs to forward VOIP traffic to it destination without any NATing,
That doesn't work easily. VoIP is not a "forwarding" thing because you can't easily define the ports or the end points. Have you no means of creating a direct tunnel opening the two networks? That will make things a LOT easier. Plus faster.
If you HAVE to, yes, you can forward SIP and UDP 10,000 - 20,000 ports to your PBX and often this will work. But double NATing inside of your own network is going to be a continuous issue.
-
i'm very appreciated really
thanks alot for your time
i will try my best to get that donesee you again soon
best regard
-
Good luck
By far the easiest option will be to create a direct tunnel.
-
@scottalanmiller said:
Good luck
By far the easiest option will be to create a direct tunnel.
This is the way to go for sure. I can tell you I am running 4 sites (soon to be 5) from a single PBX at my main site, so if you're able to follow Scott's advice above, it can work very, very well for you. All of my sites are in the same metro area, and each remote site is connected via site-to-site vpn back to the main site. We have QoS configured at every firewall. And we do not filter / inspect SIP traffic as that can cause you a world of hurt.
-
@NetworkNerd I'd like to point a few things. 1
- QoS over the internet means nothing. Your carrier is not going to respect your tags unless its on a P2P or MPLS circuit.
- Your carrier can't read tags on traffic if you encrypt it all together.
-
Wrapping real time UDP based protocals with TCP is in general a waste of bandwidth (your going to retransmit data that will actually make the quality worse if it is processed out of order).
-
@Lost_Signal773 said:
Wrapping real time UDP based protocals with TCP is in general a waste of bandwidth (your going to retransmit data that will actually make the quality worse if it is processed out of order).
Yeah, not a good idea.
-
@Lost_Signal773 said:
@NetworkNerd I'd like to point a few things. 1
- QoS over the internet means nothing. Your carrier is not going to respect your tags unless its on a P2P or MPLS circuit.
No, but QoS before it hits the Internet does the majority of what most people need. It is normally your own WAN link that is the choke point, not the open Internet. If it was, nothing we expect to work would work.
