VPN in iDirect

Lots depends on your plans, but so far these are iDirect's main benefits over other technologies:

1) Uplink efficiency. This can reach 98% if the satellite network is properly planned and the network operator executes high quality standards. This is not possible with any of TDMA (especially Aloha-based and it's derivatives) technologies present so far, be it LinkStar, LinkStar S2, Hughes HX, Gilat or anything else. In most of the cases, uplink is extremely important and sometimes that's what renders all the additional bells and whistles absolutely useless. Good efficiency basically means you get more bandwidth at the same cost and reliable service.

2) QoS. If you anticipate using other data, voice or videoconferencing applications bypassing the VPN tunnel, iDirect's QoS is superior to anything else out there. You will definately need to prioritize streaming traffic to make sure it remains of business quality whenever the voice or video communication is required. I haven't seen a VSAT solution with QoS nearly as good as the one implemented in iDirect, despite many advertisement brochures praise other QoS mechanisms.

3) Dedicated timeslot availability. If you're dealing with realtime traffic and need jitterless data transfer, iDirect provides you with true CIR because timeslots can be made dedicated in iDirect's D-TDMA mode while other VSAT systems can only emulate CIR as they need to contend with other terminals to request the timeslot. This is pretty well covered on our website at https://www.bcsatellite.net/eng_dtdma.html
(Notice we are not offering iDirect system alone.)

4) iDirect has it's own Network Accelerator units - means you pre-accelerate your IPSec based VPN without using 3rd party devices. This simplifies troubleshooting and maintenance. I'd like to notice that those accelerators are pretty expensive so if you can build your VPN over an SSL-VPN standard, that would save you lots of cash as the iDirect modem will be able to accelerate your VPN tunnels with it's built-in TCP acceleration algorithm.

and the last - I've seen lots of poor engineered iDirect networks out there. Designing a successful solution is more the art of the engineer. Of course platform plays a very important role too, but an improper bandwidth management concept can ruin all the technological benefits.

Hope this helps.

And quite informative too.
These above breakdown sort of puts iDirect in a class high above other technologies that as it has always been.
Locally here , the stiff competition and cost do bring up the issue of which way to go .The iDirect way or the other ways. From my experience, coming from a developing community where there is limited resources and cost plays a vital role . The other technologies have always had their way for not major technical reason other then cost of equipment and bandwidth. But I have always tabled before them all the huge benefits that comes bundled with iDirect . I hope solution providers will see these and make more of the overall performance based on a well structured deployment than the immediate gain .

I am managing 5IF Hub and I couldn't get the VPN to work,  I don't know what the reason. Right now I am setting in a remote (3100) and trying to connect to our office VPN (Cisco) but failed. I asked my college to remove the check form CRTP and apply the configuration to both sites (modem & Hub) but still unable to connect.

If anyone could help in this issue I will be really thankful.

I am running 7.05,
You know I changed the LAN IP to public IP and it works, but I am still don't know what the real reason because I was in another remote with a local IP  Range in the modem and the VPN worked for me, the iDs was 7.0.1.2

Any Ideas ?! Thanks !

Dear pgannon,
Thanks for reply. I just new to this iDirect technology and I receive no training yet, so if you can provide me with more details in order to configure the VPN to work with local/private IPs (DHCP) as you said and what to configure (Client/Hub) I will be so thankful. Thank you in advance.

To Y2J:  You need to contact the vendor for your VPN solution to get assistance configuring it.  Whether it runs over iDirect or any other broadband satellite service does not matter - they all have the same latency issues.  You can overcome the latency restrictions by using pre-acceleration equipment, or hosting your VPN appliance in the teleport, among other workarounds.  As I understand from your posts, you are trying to simply get the VPN to work, and it sounds to me like it worked previously because you had a public IP, and it doesn't work now, because you're using a private IP that probably changes every time DHCP assigns a new address.  The simplest solution is to get a public IP and then get your VPN vendor to talk you through the configuration.  That should solve the connectivity issues.  A VPN, if properly configured with private IP addresses should always work unless the network operator specifically blocks it.  The latency issue is another issue entirely, and it has a significant impact on performance.  Search this forum for VPN solutions - the standard workarounds for addressing VPN latency have been posted on multiple occasions.  Note, that I have seen situations where VPN performance suffered because the customer had requested that QoS be configured to de-prioritize UDP in an effort to restrict voice and video services on their circuit.  They did not realize that IPSec and PPTP wrap up the original TCP packet in a UDP frame, so they were de-prioritizing their VPN to the extent that it didn't work.  With proper QoS configuration (use the IP address of the appliance)  this issue is easily solved.

To HVYMTL:  You have mentioned a good alternative VPN solution.  Citrix works because it uses SSL-VPN technology.  It encrypts the data, but not the headers, thus TCP Acceleration that is built into most broadband satellite solutions today can do its job.  The problem is, many people in remote offices are mandated by their corporate data centers to use IPSec or PPTP, and these VPNs encrypt/encapsulate the entire packet, thus TCP Acceleration doesn't work since it can't see the TCP headers.  When you are in this situation, then the only options are to look at the available work-arounds, which include pre-acceleration devices from companies such as iDirect, UDCast, Mentat/Packeteer and others.  These devices add to the cost of the solution, but they do work to overcome the limitations that latency imposes on VPN connections.