SSTP VPN - Skype sound drops issue

Hello,
I have setup SSTP tunnel to our USOffice.
Now we expect issue with sound drops in Skype. It seems that Skype connect to peer via SSTP tunnel.

D:\Users\admin\Desktop>type CHANGELOG_5 | find /I “sstp”

*) sstp - improve initial handshake to better handle many new connections;
*) sstp - fixed connection idle time reporting;
*) sstp - made it working on Pentium 4 again;
certificate validation problems for some programs (VPN, SSTP etc)
*) sstp - added RC4 cipher support to fix interoperability issues
*) sstp client - added an option to skip
*) sstp - when server certificate verification is enabled for sstp client,
*) sstp - fix problems on multicore systems;
*) sstp - fixed memory leak;
*) fixed sstp memory leak;
*) sstp - fixed memory leak;
*) sstp - made it work with Windows 7;
*) sstp server - client reconnects did not work;
*) fixed sstp on x86;
*) added support for SSTP protocol (PPP over TLS);

Early we had Netscreen NS50 with IPSec setup to our RB1200, but we changed it to RB433UAH and RB1200 to RB1100AH.
Now is: RB433UAH – SSTP – RB1100AH.
When I drop VPN all seems to be ok. I will try to setup IPSec VPN instead of SSTP.

Does someone have similar issue ?

try ip firewall connection tracking and set udp timeout to a higer value (20?)

It seems that with IPSec between offices issue disappeared. But with IPSec we have less throughput.
More good sound with lees throughput :slight_smile:

Please contact support with detailed description of the problem and supout file generated at the time when problem appears.

Ticket#2012070666000456

It seem that IPSec doesn’t resolved issue.

/ip firewall connection tracking set udp-timeout=20

Will see the results.

Without success :frowning:

How I can troubleshoot this ?

what is ping between sites? Try even bigger udp timeout. how about 50? 100?

Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=167ms TTL=63
Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=167ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=171ms TTL=63
Reply from 192.168.13.1: bytes=32 time=172ms TTL=63
Reply from 192.168.13.1: bytes=32 time=171ms TTL=63
Reply from 192.168.13.1: bytes=32 time=187ms TTL=63
Reply from 192.168.13.1: bytes=32 time=170ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=169ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=167ms TTL=63
Reply from 192.168.13.1: bytes=32 time=168ms TTL=63
Reply from 192.168.13.1: bytes=32 time=345ms TTL=63



Ping statistics for 192.168.13.1:
Packets: Sent = 59, Received = 59, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = > 167ms> , Maximum = > 531ms> , Average = > 202ms



how about 50? 100?

Will try

As a workaround

Define L7 filter for Skype-to-Skype

/ip firewall layer7-protocol add comment="Pattern for: Skype to Skype traffic" name=Skype-to-Skype regexp="^..\\x02............."

Mark Skype-to-Skype traffic using L7 filter

/ip firewall mangle
add action=mark-routing chain=prerouting comment="Skype-to-Skype packets" disabled=no layer7-protocol=Skype-to-Skype new-routing-mark=skype-to-skype passthrough=yes src-address-list=US-Skype-issue

Route Skype-to-Skype traffic via default gateway - not via SSTP VPN

/ip route
add comment="Route: Skype-to-Skype via default gateway" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=81.81.81.81 routing-mark=skype-to-skype scope=30 target-scope=10

Will see the results.

Doesn’t helped.
I disabled all UDP traffic in forward chain between offices.
Without success.
Only when I disable routes from each office to another issue disappeared, because then Skype doesn’t have route to another office via VPN.

I’m trying to roll-back to ROS 5.14 both routers.

After downgrade to ROS 5.14 certificate disappeared from ROS and I can’t import it again:

# certificate import file-name=vpn.domain.com.key
passphrase: ***************
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)

Ticket#2012071166000339

Can’t import the certificate in ROS 5.14, ROS 5.15, ROS 5.16.
ROS 5.17 - works. Will see what is happening in ROS 5.17 with Skype in SSTP VPN.

ROS 5.17 SSTP VPN

Jitter measure via SSTP VPN

D:>iperf -c 192.168.1.1 -u -b
iperf: option requires an argument – b

Client connecting to 192.168.1.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)

[1868] local 192.168.2.1 port 28498 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[1868] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[1868] Server Report:
[1868] 0.0-10.1 sec 1.25 MBytes 1.04 Mbits/sec > 13.252 ms > 0/ 893 (0%)
[1868] Sent 893 datagrams

Jitter measure via directly

D:>iperf -c 81.81.81.81 -u -b
iperf: option requires an argument – b

Client connecting to 81.81.81.81, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)

[1868] local 192.168.2.1 port 28627 connected with 81.81.81.81 port 5001
[ ID] Interval Transfer Bandwidth
[1868] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[1868] Server Report:
[1868] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec > 0.166 ms > 0/ 893 (0%)
[1868] Sent 893 datagrams

Why jitter is so gib in VPN ?


Problem: Jitter
Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)
QoS
VoIP Basics: About Jitter

Hello,

Instead of SSTP try L2TP with and/or without IPSec.

Geza

Now issue appear without VPN also.

  1. Upgraded all devices to 5.24
  2. Removed bridge(lan+wlan)

And now all is fine.