Yes the separate clusters each have separate NAT/firewalls protecting them.
Again, I am not going to be able to convince the people donating that bandwidth to set our internal ip on their network as a DMZ host.
I plan to write about it, if I ever figure out how to punch a two way tunnel from me (a place where I have control over such things) to these places.
What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from here via some other capable tunnel to these remote sites till we convince folks we need to get something up on a decent tower.
It doesn't need to be encrypted or authenticated, whatever is easiest and will do the job.
--Quote--
I'm unclear on the topology of your network; I'm going to assume that the separate clusters each have a separate NAT/firewall protecting them.
In that case, I believe you may get the IPIP traffic to pass through the NAT/firewall to the internal host by designating the internal host as a DMZ host. You would then register the NAT/firewall's public IP address as the gateway host.
I'd wager it depends on the software in the NAT/firewall so some may do it and others may not. I heard that OpenWRT does handle IPIP encapsulation.
I've not tried that myself so others who have done so should comment on whether this approach actually works.
I'd much appreciate you writing up what you wind up doing and publish it on the wiki so others may share your experience. - Brian
When you take in account OpenVPN and the problems related to UDP in VoIp communications, take in account that there are also OpenVPN tunnels over TCP, which maintain the proper packet order and don't have the mentioned problem. BTW, lesser cost mikrotik devices support OpenVPN/TCP server and client endpoints (but not UDP).
Marius, YO2LOJ
On 04/17/2013 02:28 PM, Marius Petrescu wrote:
When you take in account OpenVPN and the problems related to UDP in VoIp communications, take in account that there are also OpenVPN tunnels over TCP, which maintain the proper packet order and don't have the mentioned problem.
I think the problem (if there is any problem at all) *is* OpenVPN over TCP. Ordering isn't the problem: the problem is that there's no point in retransmitting a dropped packet when it represents real-time audio that's already happened. The receiving device has already moved on.
This is why RTP operates over UDP. If RTP happens to be encapsulated in a tunnel that runs over TCP, then you have violated the design assumptions of RTP. Fortunately, OpenVPN can also be configured to work over UDP.
I'm rather doubtful that a properly configured OpenVPN tunnel presents any issues with VoIP. I wouldn't believe any such claims without a properly cited reference, since I have several handsets that connect to a remote office through OpenVPN over the public internet with no issues whatsoever. Not that I've performed extensive research on the subject, but I figure my phone manufacturer did some testing before deciding to put OpenVPN connectivity in all of their handsets, and I've never had a reason to doubt their conclusion.
Don't get me wrong: I love OpenVPN. It has been my go-to VPN setup since I was working with the MySQL folks in 2005 where EVERYONE was connected to a bridged (tap) OpenVPN hub in Finland. That said, the TCP tunnels (both tap and tun) "suffer" from the same sort of reliable transport layer. All packets sent through an OpenVPN tunnel are guaranteed to arrive at their destination or the tunnel will collapse before they get there. And the tunnel rarely ever collapses. This is one of the great things about OpenVPN. It is also what makes it such a terrible choice for real-time streaming media traffic. SSH? Yes! HTTP? Yes! SIP? Yup! RTP? No way. Sometimes, you need to be able to drop packets in order to ensure real-time delivery.
http://ipseclab.eit.lth.se/tiki-index.php?page=6.+OpenVPN
I could be wrong here. I would be happy if it turned out I was. But I think you'll find that although OpenVPN is a wonderful piece of software, it is not well suited to the transmission of VoIP or other real-time streaming media traffic.
73,
C.J.
On Wed, 2013-04-17 at 21:28 +0300, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ When you take in account OpenVPN and the problems related to UDP in VoIp communications, take in account that there are also OpenVPN tunnels over TCP, which maintain the proper packet order and don't have the mentioned problem. BTW, lesser cost mikrotik devices support OpenVPN/TCP server and client endpoints (but not UDP).
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17/04/2013 21:16, C.J. Adams-Collier KF7BMP wrote:
(Please trim inclusions from previous messages) _______________________________________________
I could be wrong here. I would be happy if it turned out I was. But I think you'll find that although OpenVPN is a wonderful piece of software, it is not well suited to the transmission of VoIP or other real-time streaming media traffic.
I cannot confirm this, I have been sending VoIP traffic via OpenVPN for quite a few years. You will need to limit the number of packets per second to the capacity weakest element in the chain (CPU, bandwith, etc) in order to avoid packet loss (audible as various kind of degradation of the audio stream). I don't want to go into to much technical details in this post, just wanted to provide my experience.
OpenVPN/UDP has given better results than OpenVPN/TCP but YMMV.
I haven't been in the situation that the bottleneck was the internet bandwidth available, but if it is in your case, you may need to think about throttling some protocols while prioritizing others. Control and signalling messages should be transmitted reliably (e.g. do not drop them) but may be delayed, while audio and video streams should experience as low delay as possible (e.g. do not queue packets, drop some of them to reduce queue size and delay).
Depending on the OS and architecture you will be able to find a bunch of different approaches to do traffic "shaping".
73 de Marc, LX1DUC
I always used openvpn over udp to solve those kind of problems, worked excellent.
73,
Bob VE3TOK
On 13-04-17 01:34 PM, kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
Yes the separate clusters each have separate NAT/firewalls protecting them.
Again, I am not going to be able to convince the people donating that bandwidth to set our internal ip on their network as a DMZ host.
I plan to write about it, if I ever figure out how to punch a two way tunnel from me (a place where I have control over such things) to these places.
What I envision is from the rest of the amprnet, 44.92.21.0/24 http://44.92.21.0/24 comes here via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from here via some other capable tunnel to these remote sites till we convince folks we need to get something up on a decent tower.
It doesn't need to be encrypted or authenticated, whatever is easiest and will do the job.
I just talked to the OpenVPN IRC channel and they tell me I'm making it up. As you were!
73,
C.J.
On Wed, 2013-04-17 at 15:45 -0400, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ I always used openvpn over udp to solve those kind of problems, worked excellent.
73,
Bob VE3TOK
On 13-04-17 01:34 PM, kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
Yes the separate clusters each have separate NAT/firewalls protecting them.
Again, I am not going to be able to convince the people donating that bandwidth to set our internal ip on their network as a DMZ host.
I plan to write about it, if I ever figure out how to punch a two way tunnel from me (a place where I have control over such things) to these places.
What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from here via some other capable tunnel to these remote sites till we convince folks we need to get something up on a decent tower.
It doesn't need to be encrypted or authenticated, whatever is easiest and will do the job.
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-
Bob Tenty -
C.J. Adams-Collier KF7BMP -
kb9mwr＠gmail.com -
Marc, LX1DUC -
Marius Petrescu -
Phil Frost