We'd love to hear about it! Click here to go to the product suggestion community
I have some minor (our Sales Rep would classify it as major) issues with our SG135/UTM.Saturday our Sales Rep called me and complained about the performance.
A little preface:He works with his laptop (cable, not WiFi) from home with a 50/10 Mbit/s connection.He connects through Sophos SSL VPN client directly onto our SG135 and then connects via RDP to his office PC.
At first I thought he was exaggerating, so I logged from my home PC into the company network as well (also Sophos SSL VPN client).And he was right. It was slow and laggy and by no means suited to work productively.
My question: how canI find the culprit, i.e. how to monitor in the UTM for this specific problem? I mean, there are no services in the network which would burden it with high load in such a way.In addition to the Remote Access users, I have 3 IPSec S2S tunnel to our branch offices and no one else is complaining about performance, so I have to assume its something related to the SSL VPN functionality?
Im relatively new to Sophos UTM and would appreciate a "nudge" in the right direction :)
Thank you in advance.
Hallo Constantin and welcome to the UTM Community!
When you connect via RDP to your office PC, what are you doing on the PC that is slow? What are the down/upload speeds at the office?
Cheers - Bob
In reply to BAlfson:
thanks for the reply.In regards to the "slow" issue, I would describe it as a very annoying input lag - up to a point where clicking etc. is delayed for a good second, even two.
Unfortunately, the guy semi-managing the IT (that very same Sales Rep) before my joining last year, thought it was a good idea to get a Vodafone consumer connection, so we are "blessed" with 100/6 Mbit/s until we move into our new headquarters in November.
In terms of bandwith usage:
IPSec S2S Branch A - 1 RDP user at a time (maximum is 2 at the same time)
IPSec S2S Branch B - Same deal, mostly 1 user, sometimes 2
IPSec S2S Branch C - constantly 3 RDP user
Correct me if Im wrong, but they should not use up the whole bandwith?
Thanks in advance.
In reply to Benni Faller:
With 5-to-7 users, Constantin, I would expect that it would be easy for one of them to fill up the 6Mbits/s pipe and for everyone else to complain about slowness. About all you can do is create a Bandwidth Pool for each branch. 1000kbits/s for branches A & B and 1500kbits/s for C.
If you want to prioritize RDP response traffic only, you will need to select 'Keep classification after encapsulation' on the 'Advanced' tab of QoS. You will need to create a new Service "RDP Response" = 3389 → 1:65535 for your Traffic Selectors.
If the RDP traffic is the only thing transiting the IPsec tunnels, then you can just use the IPsec Services Group in your Traffic Selectors.
In fact, before you go to all that effort, check the Intrusion Prevention logs everywhere to be certain that it's not Anti-UDP Flooding causing problems. That can occur when the VPN endpoint is behind a bridged UTM, for example.
Vodafone 100/6 hmmm.. well 6 can be quite slow. And it seems like that since you said the Connection is only delayed and not disconnecting so it just Looks like a delay because to low of a bandwith.
My Idea: if you have another place with better bandwith, just create a Remote Access VPN and test how the Performance is from the other Location.
In reply to Jason Klein:
Hello Bob, Hello Jason,
@Bob, I will try that out ASAP and test it thorougly. At this point Im open to anything, since our Sales Rep is coming down on me like the wrath of ancient greek gods.@Jason its actually a double name "Benni Constantin" but only my family calls me by my first name to tease me - in public I go by Constantin :)I will try your suggestions as well - Branch C got an acceptable connection.
Will get back to you both.
just a quick update. I have yet to implement the traffic selector - in fact, tomorrow I will deploy a 2nd SG135 and initiate an active/passive cluster.While Im at it, I will put the traffic selector and bandwith pool in place.
Meanwhile, I switched SSL VPN Remote Access to UDP, which helped a lot (tested it myself)
@Jason - tried your suggestion as well, although that Remote Access at Branch C was newly deployed with UDP, so that is inconclusive.
What do you guys think about SSL VPN Site-to-Site with UDP for the normal tunnels? Not reliable enough?The thing is, all branches have to work with our ERP system here at HQ - if I knew, that they could work on their respective PCs in the branches, I would quit the whole RDP thing.
Well i never have hade any Problems with SSL Site2Site. I would reccomend the follow hopefully Balfson agrees.
use SSL VPN or Ipsec Site2Site between UTMs(Sophos).
use ipsec Site2Site with other Vendors.
well i have alot of VPNs and in my Opinion Sophos VPN Tunnels be it remote access or Site2Site are very stabel. I have alot of other admin colleagues working via RDP on our System over VPN and it always worked great you also do not need to configure anything special for the RDP Session to work. Because i rarely see the UTM cause VPN Problems especially speed wise (Just my personal experience ofcourse) i would search on other Places for the speed Problem. Like other Network devices, Bandwith and so on.
But i have some bad experience something that might be obvious, but alot of people underestimate this. Keep (depending if you use remote access or site2site) Clients, and UTM always up to date, especially ***** Windows 10 ;). There are constant security Updates and Updates in general and i had the weirdest things happen to me.
Agreed with Jason about using site-to-site tunnels, Constantin. I prefer IPsec with a policy that uses AES 128 GCM as that can take advantage of hardware encryption with CPUs that are capable of AES-NI.
I prefer UDP with the SSL VPN as it is faster than TCP. If a packet gets mangled between the sites, the recipient just requests it again, so reliability is not compromised at all.
I agree that adding site-to-site tunnels is a better way of doing things than having multiple people use RDP via remote access connections. Depending on what they're doing, the 6Mbps limitation may still be a problem.
thanks for the suggestions. I implemented them all (including Traffic Selectors and Bandwith Pools).We'll see how that plays out. The Sales Rep did not complain... yet.
I guess we can close this thread?In case something unforeseen happens, I will let you know :)
Thanks again and lets hope everything goes well.