Facetime and site to site VPN
-
I have a site to site VPN connection between 3 sites using ipsec tunnels. These three sites are my house (Toronto), My sisters House (Otttawa) and my parents house (Vancouver). The tunnels are working fine and we are using the APU4 pfsense boxes at all three sites. We all have high speed internets at all three sites.
The problem I am having is that facetime calls are being carried over the VPN tunnels rather than the internet. This results in lag and poor connections. I am wondering if there is a way to override this behavior. Even though Facetime is a closed Apple products I am guessing the initial handshake and call setup is taking over the Internet but soon after the routers at both end realise that the two end points of the Facetime call are also connected via the site to site VPN link and then subsequent packets are then being routed via the secure VPN tunnel. This would not have been a problem if the latency and delay due to the encryption/decryption was not causing a delay.
Was wondering if any one has any ideas on how to prevent Facetime from going over the VPN?
Thanks
-
As far as I know (I might be wrong), FaceTime calls are always routed as "peer to peer" whenever possible. In fact, you should get better performance if the link is established directly since you are avoiding 3rd party servers. The overhead caused by the encryption/decryption of the VPN link should be negligible. If you are having poor performance, I highly doubt it is because of the VPN link per se.
As regards your original question, FaceTime uses well defined UDP ports for data transport. I guess you can just block these ports on your tunnels (info)
Best regards
-
If I shut off the tunnel during the call everything works fine. Going through the tunnel is definitely introducing latency. It also have to do with the way my VPN is setup. The thing is that I have a "Hub and Spoke" pattern of VPN where Site A is connected to Sites B and C but site B and C are not connected to each other directly. Any communication between site B and C goes through site A which increases the RTT. I know I should pr
Here is a ping from Site C to site A (through the site to site tunnel. This is a DIRECT site to site tunnel)
System:~$ ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=62 time=69.6 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=62 time=68.5 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=62 time=70.2 ms
64 bytes from 10.1.1.1: icmp_seq=4 ttl=62 time=69.1 ms
–- 10.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 68.564/69.402/70.287/0.715 msNow compare to the ping from site C to site B (Remember site C and B are NOT connected directly but the packets first go through the tunnel to site A and then from the tunnel from site A to site B)
System:~$ ping 10.2.1.1
PING 10.2.1.1 (10.2.1.1) 56(84) bytes of data.
64 bytes from 10.2.1.1: icmp_seq=1 ttl=61 time=148 ms
64 bytes from 10.2.1.1: icmp_seq=2 ttl=61 time=150 ms
64 bytes from 10.2.1.1: icmp_seq=3 ttl=61 time=147 ms
64 bytes from 10.2.1.1: icmp_seq=4 ttl=61 time=159 ms--- 10.2.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 147.789/151.622/159.958/4.913 msAs you can see my RTT times are close to three times longer going from site B to C which is what's causing my troubles. Also for comparison here is a ping from Toronto to Google's server in mountain view california using WAN and not the tunnels.
System:~$ ping 173.194.70.138
PING 173.194.70.138 (173.194.70.138) 56(84) bytes of data.
64 bytes from 173.194.70.138: icmp_seq=1 ttl=45 time=102 ms
64 bytes from 173.194.70.138: icmp_seq=2 ttl=45 time=103 ms
64 bytes from 173.194.70.138: icmp_seq=3 ttl=45 time=105 ms
64 bytes from 173.194.70.138: icmp_seq=4 ttl=45 time=103 ms
64 bytes from 173.194.70.138: icmp_seq=5 ttl=45 time=103 ms -
Ok then! Then you will have to filter out the traffic. Did you try with the ports specified on the Apple document? You can also monitor the state table while on a call.
Or better, assign a fixed IP address to your iOS devices and deny them access to the remote networks (unless you need that access for other reasons, of course)