OpenVPN SSL slow over the pond

Hi David,

I would like to know where do you face the speed problem, is it while accessing the Internal resources or Web browsing through SSL VPN. Also, confirm what the ISP bandwidth is for both sites (also if it is dedicated or shared).

Thanks

Hi, 

thanks for the reply!

Our we have fibre with 1GBps symmetric. 

On the other sides we have various connections, our employees working from home or abroad.

For myself at home I have 200/10 Mbit/s and I can't get much higher download then mentioned above.

Upload to other external resources works fine (uploaded an archive to Google Drive with 110 Mbyte/s this morning).

Also downloading on the remote locations works with the expected speeds.

We use only split VPN so our employees can access internal resources over HTTPS and CIFS.

Best

David

Thanks for the information, hence, the issue is when accessing the internal resources through the VPN tunnel.

What is the DNS configured on the UTM and the remote systems when they connect does changing them to internal DNS server IP address (If available)helps you?

• Test for irregular latency on the network:- Using traceroute/tracert and ping - from the UTM to server, from VPN connected system to server, from internal client to server. Make note if there is a significant difference in speed between the different hops.
• Test for packet loss using continuous ping. From the UTM to server, from VPN connected system to server, from internal client to server.
• Review packetfilter.log and ips.log for interesting packet drops for the connected client's IP address.

Next, if the server are behind eth1, show me the output of "ifconfig eth1" and "ifconfig tun0". 

Thanks

Hey there, 

I tested a lot of things, with various remote clients.

There is literally nothing in IPS or packetfilter logs related to their public IPs or tunnel adapter IPs.

From our internal network I pinged the remote machine (on tun iface):

1067 packets transmitted, 1064 packets received, 0% packet loss
round-trip min/avg/max/stddev = 11.234/114.258/1156.008/82.821 ms

eth0 is the local network where the servers are also located:

eth0 Link encap:Ethernet HWaddr 00:1A:8C:5F:XX:XX 
inet addr:192.168.141.250 Bcast:192.168.141.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1732201788 errors:0 dropped:28522 overruns:0 frame:0
TX packets:2704901752 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1453267287437 (1385943.6 Mb) TX bytes:3002130198728 (2863054.4 Mb)

tun0:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.242.2.1 P-t-P:10.242.2.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1978697 errors:0 dropped:0 overruns:0 frame:0
TX packets:3184046 errors:0 dropped:39693 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:306543515 (292.3 Mb) TX bytes:2993584521 (2854.9 Mb)

I'm out of ideas here...

Hi David,

There are drops observed on the eth0 interface in the RX state. Change the physical cable connecting the UTM to the Switch. 

RX packets:1732201788 errors:0 dropped:28522 overruns:0 frame:0

Show me the result of ethtool eth1, what is the speed and duplex on the WAN intreface?

Did you see any unnecessary latency in tracert output from the (UTM, internal client and VPN client) source towards the file server? This output is important.

Thanks

Hi Sachin, 

thanks for the help!

Our WAN is ppp0, connected on eth7:

Settings for eth7:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes

Tracert on the windows client gives me 1 hop in between over the VPN connection, with 160msec, looks good.

From the UTM it tries 30 hops but does not reach anything o.O

Ignore this, it works with traceroute -I to use ICMP ;)

Cable changed, no changes here!

One more thing:

is what you can see on the screenshot fragmentation?

I tried different values, but it always does DPU fragmentation!

This has been captured on the virtual tun interface on the remote client, downloading a file from internal server.

Can you share a picture of all the tracert permutation results? I would like to see that. I want to understand where is the latency observer; between the UTM & file server or the client and the file server and compare it with an internal client to file server output.

Thanks

Hi there,

this is from the UTM:

traceroute -I 192.168.xxx.180
Note: the -i and -I options were exchangedfor compability with LBL traceroute
Use -I for ICMP, and -i <ifname> to specify the interface name
traceroute to 192.168.xxx.180 (192.168.xxx.180), 30 hops max, 40 byte packets using ICMP
1 192.168.xxx.180 (192.168.xxx.180) 1.037 ms 1.056 ms 1.055 ms

This from the remote client:

tracert 192.168.xxx.180

Tracing route to host.domain.local [192.168.xxx.180]
over a maximum of 30 hops:

1 159 ms 159 ms 159 ms 10.242.2.1
2 160 ms 159 ms 159 ms host.domain.local [192.168.xxx.180]

Trace complete.

Is this enough?

Hi David,

Thanks for the information, there is no delay observed between the UTM and the File server so we can now skip that part. There is a visible delay on the SSL VPN connected clients to reach the server. Is the remote client connected to the wireless or through a LAN? Show me a continuous ping from the remote client to the file server; connected to the VPN.

Do the following settings on the SSL VPN settings:

Encryption Algorithm: DES-EDE3-CBC

Authentication Algorithm: SHA1

Protocol:UDP

Remove compression

Key size: 1024

Thanks