This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN speed issues *THROUGH* Sophos UTM

So I have a bit of an issue.  I'm not even sure where to post this so I'm starting here.  I know it's a Sophos UTM issue as my pfsense box acting as the gateway in place of Sophos doens't experience this issue.

Anyway I have a VPN connection setup from my machine to Private Internet Access for more discrete web browsing.  When I am connected through the Sophos box I only get ~2Mbps on my download while a connection through pfsense gets me my line rate of ~10Mbps (actually a little more because of the compression).  

I have shut all the modules off, tried adding bypass rules for the laptop, tried using a different machine on the network and nothing seems to help.  No matter what I do the performance is always significantly worse when I have the Sophos box acting as the gateway.  

I have Googled and Googled and not found a single hit on this.  Would anyone be able to shed some light on this problem?  The only possible explanation I have is that Sophos doesn't have enough resources.  I have given is 2 CPU cores and 4GB of RAM in my VMware environment but can up that if needed.  Anyone have any thoughts?

Thanks much!
--
Dan


This thread was automatically locked due to age.
  • UTM software version?

    VPN type and protocol(s) used?

    Nothing in the UTM logs?

    Flood protection?

    "My machine" = client system inside the UTM protected network?
  • Sorry, should have give more information, my bad:

    UTM version: 9.204-20 (home license)
    VPN type: It's OpenVPN that they are using, not sure of the specifics.  Also they are using LZO data compression if that's relevant.

    Nothing in the logs, where is flood protection?
    Yes, any client inside the UTM network.  I have tried on 3 different computers with the same result.

    EDIT: At this point I'm almost willing to have someone get into the box and take a look.  I've been pulling my hair out for like 3 weeks now trying to resolve this issue...
  • Flood Protection in 9.113, perhaps it hasn't moved far for 9.2:
    WebAdmin: Network Protection->Intrusion Prevention, Anti-DoS/Flooding tab
  • Well I'll be.  I guess shutting off the global intrusion prevention doesn't disable the flood protection (as I would have assumed).  I just turned them all off and am getting almost 10mbps.   I feel like an idiot now, thanks so much for your help!
  • Hi, an Exception would suffice instead of turning off the flood protection.

    Barry
  • Hi, an Exception would suffice instead of turning off the flood protection.

    Barry


    Unfortunatly it doesn't, an exception for the IP of the machine I'm testing from changes nothing.  I suspect Sophos cannot see the IP because it's routing all traffic through the VPN tunnel?  :/
  • Dan, try showing us a line or two from the Intrusion Prevention log where this was a problem.

    Cheers - Bob
  • Dan, try showing us a line or two from the Intrusion Prevention log where this was a problem.

    Cheers - Bob


    Bob,

    Here is where the request is limited:

    2014:08:03-20:16:59 gateway ulogd[822]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="0:30:88:1e:59:bb" dstmac="0:c:29:6e:f9:16" srcip="216.227.***.***" dstip="76.5.***.***" proto="17" length="153" tos="0x00" prec="0x00" ttl="59" srcport="1194" dstport="55577"
    
    2014:08:03-20:16:59 gateway ulogd[822]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="0:30:88:1e:59:bb" dstmac="0:c:29:6e:f9:16" srcip="216.227.***.***" dstip="76.5.***.***" proto="17" length="153" tos="0x00" prec="0x00" ttl="59" srcport="1194" dstport="55577"
    2014:08:03-20:16:59 gateway ulogd[822]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="0:30:88:1e:59:bb" dstmac="0:c:29:6e:f9:16" srcip="216.227.***.***" dstip="76.5.***.***" proto="17" length="153" tos="0x00" prec="0x00" ttl="59" srcport="1194" dstport="55577"
    2014:08:03-20:16:59 gateway ulogd[822]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="0:30:88:1e:59:bb" dstmac="0:c:29:6e:f9:16" srcip="216.227.***.***" dstip="76.5.***.***" proto="17" length="153" tos="0x00" prec="0x00" ttl="59" srcport="1194" dstport="55577"
    2014:08:03-20:17:00 gateway ulogd[822]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="0:30:88:1e:59:bb" dstmac="0:c:29:6e:f9:16" srcip="216.227.***.***" dstip="76.5.***.***" proto="17" length="153" tos="0x00" prec="0x00" ttl="59" srcport="1194" dstport="55577" 


    The 216. address is the VPN server I'm connecting to and the 76. address is my WAN address on the Sophos box. I could use the WAN address on my Sophos box for the rule but this defeats the purpose.  The IP address of the server always changes when I connect...
  • Yes, Dan, but it looks like you could always use your IP in 'going to these destinations' and 1194->1:65535 in 'going to these services'.  You might be able to better identify the subnet of the sending IPs and further limit the Exception.

    Cheers - Bob
  • Yes, Dan, but it looks like you could always use your IP in 'going to these destinations' and 1194->1:65535 in 'going to these services'.  You might be able to better identify the subnet of the sending IPs and further limit the Exception.

    Cheers - Bob


    Unfortunatly my IP always changes as well since I have DSL and it just uses DHCP from a pool.  [:(]  I can't do anything by source because they have a ton of different locations where the tunnel goes all with different IP blocks.  How bad would it be just to do "going to these services" with the 1194->1:65535 listed?  I suppose it's better than having the flood protection totally off and it does seem to work.