VOIP Vs VPN
-
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.
-
@scottalanmiller said:
@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.
Yep - that is how I should have worded it. Sorry if that was not clear from my post.
-
Hi guys
i was unclear in my previous posts, what i have to say is :
when a sip client 192.168.1.10 want to talk with sip client 10.10.10.6 the following happen :
since we are connected via openvpn tunnel no NAT happen actually, because i run wireshark in both machine (remote vpnclient and IP PBX) and i saw that the packets carry the real IP of the sip phone not the public ip (source ip : 10.10.10.6 --- destination ip : 192.168.1.10)
what happened actually is routing not Nating, because there is a virtual tunnel between vpn client and vpn server and the vpn server route the packets to it destination (in this case 192.168.1.10 )
so the RTP traffic should be established without any issue since there is not NAT in the tunneli find the solution and now i have 2 site connected via openvpn and both location can call each other, the problem occur because i had wrong setting (in Ozeki server), before i set Discover public IP address using STUN server: stun.ekiga.net, this what created problem for me, i change it to my local IP PBX (Ozeki server) then everything work fine except sound quality, both side can hear each other but the sound was not totally clear (mixed with some noise),
any suggestion to improve sound quality knowing that in the main office the download speed is 4 mbs and upload speed is 0.5 mbs , and in the branch office we have download speed is 10 mbs and upload speed is 2 mbs ,
i think that my connection speed which decrease sound quality ????? or maybe something else ??? any suggestion ??thank you all for you answers
