Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 1475 views
  • Users 0 members are here
Options
Suggested
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

UTM 9.2 to Sonicwall very high bandwidth used for Hyper-V connections

TevorHinch
I am having a problem with the amount of bandwidth being used by a VPN tunnel from the office to the hosting location and loss of connectivity.
Our office uses a Sonicwall PRO 1260 Enhanced
The Host UTM is an ASG120 with FullGuard subscription.
I have an IPSEC VPN tunnel to the Sophos using IP addresses as the VPN ID.
I used the AES-256 policy to match  the the Sonicwall and setup these policies:
IKE: Auth PSK / Enc AES_CBC_256 / Hash HMAC_SHA1 / Lifetime 28800s / DPD
ESP: Enc AES_CBC_256 / Hash HMAC_SHA1 / Lifetime 28800s

The problems that I am seeing is that it tends to lose it's connection regularly on the UTM side (I recieve failure messages usually once a day) and whenever a Hyper-V Manager connects across the tunnel, it uses about 1.5 MB/minute of data use just sitting open. When activating a Hyper-V remote session to connect, run an ipconfig and disconnect, I just used 56 MB of data in less than 30 seconds.

Is this a common issue or do I have a configuration issue that needs to be updated?


This thread was automatically locked due to age.
  • 0
    I'd vote for a configuration issue, Trevor.  On the off chance that it's not a problem with Hyper-V, let's look at the IPsec log for a single connection setup...

    On the 'Debug' tab of 'IPsec', make sure nothing is selected.
    Disable the IPsec Connection.
    Start the IPsec Live Log.
    Enable the IPsec Connection.
    Activate a Hyper-V remote session to connect, run an ipconfig and disconnect.


    That should yield about 80 lines in the Live Log.  Please paste them into a new post here.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi Bob,

    When I disconnected the VPN tunnel, I needed to entirely rebuild my authentication settings to re-establish the connection. 
    Here is the log after the rebuild:

    2014:10:24-09:37:17 utm pluto[8124]: "S_27Burnside .2" #1: deleting state (STATE_MAIN_I4)
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface lo/lo ::1
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface lo/lo 127.0.0.1
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface lo/lo 127.0.0.1
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface eth1/eth1 72.2.5.140
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface eth1/eth1 72.2.5.140
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface br0/br0 192.168.30.1
    2014:10:24-09:37:18 utm pluto[8124]: shutting down interface br0/br0 192.168.30.1
    2014:10:24-09:37:18 utm ipsec_starter[8118]: pluto stopped after 340 ms
    2014:10:24-09:37:18 utm ipsec_starter[8118]: ipsec starter stopped
    2014:10:24-09:37:50 utm ipsec_starter[8721]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2014:10:24-09:37:51 utm pluto[8733]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2014:10:24-09:37:51 utm ipsec_starter[8727]: pluto (8733) started after 20 ms
    2014:10:24-09:37:51 utm pluto[8733]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
    2014:10:24-09:37:51 utm pluto[8733]: including NAT-Traversal patch (Version 0.6c)
    2014:10:24-09:37:51 utm pluto[8733]: Using Linux 2.6 IPsec interface code
    2014:10:24-09:37:51 utm pluto[8733]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2014:10:24-09:37:51 utm pluto[8733]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2014:10:24-09:37:51 utm pluto[8733]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2014:10:24-09:37:51 utm pluto[8733]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2014:10:24-09:37:51 utm pluto[8733]: Changing to directory '/etc/ipsec.d/crls'
    2014:10:24-09:37:51 utm pluto[8733]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2014:10:24-09:37:51 utm pluto[8733]: listening for IKE messages
    2014:10:24-09:37:51 utm pluto[8733]: adding interface br0/br0 192.168.30.1:500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface br0/br0 192.168.30.1:4500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface eth1/eth1 72.2.5.140:500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface eth1/eth1 72.2.5.140:4500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface lo/lo 127.0.0.1:500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface lo/lo 127.0.0.1:4500
    2014:10:24-09:37:51 utm pluto[8733]: adding interface lo/lo ::1:500
    2014:10:24-09:37:51 utm pluto[8733]: loading secrets from "/etc/ipsec.secrets"
    2014:10:24-09:37:51 utm pluto[8733]: loaded PSK secret for 72.2.5.140 184.71.24.2
    2014:10:24-09:37:51 utm pluto[8733]: added connection description "S_27Burnside .2"
    2014:10:24-09:37:51 utm pluto[8733]: "S_27Burnside .2" #1: initiating Main Mode
    2014:10:24-09:37:56 utm pluto[8733]: packet from 184.71.24.2:500: ignoring Vendor ID payload [5b362bc820f60006]
    2014:10:24-09:37:56 utm pluto[8733]: packet from 184.71.24.2:500: received Vendor ID payload [RFC 3947]
    2014:10:24-09:37:56 utm pluto[8733]: packet from 184.71.24.2:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2014:10:24-09:37:56 utm pluto[8733]: packet from 184.71.24.2:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: responding to Main Mode
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: ignoring Vendor ID payload [404bf439522ca3f6]
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: received Vendor ID payload [XAUTH]
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: ignoring Vendor ID payload [da8e937880010000]
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: received Vendor ID payload [Dead Peer Detection]
    2014:10:24-09:37:56 utm pluto[8733]: "S_27Burnside .2" #2: NAT-Traversal: Result using RFC 3947: no NAT detected
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #2: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #2: Peer ID is ID_IPV4_ADDR: '184.71.24.2'
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #2: Dead Peer Detection (RFC 3706) enabled
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #2: sent MR3, ISAKMP SA established
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #3: responding to Quick Mode
    2014:10:24-09:37:57 utm pluto[8733]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="27Burnside .2" address="72.2.5.140" local_net="192.168.30.0/24" remote_net="192.168.20.0/24"
    2014:10:24-09:37:57 utm pluto[8733]: "S_27Burnside .2" #3: IPsec SA established {ESP=>0x2a3e5c86 0x5eb25c86 
  • 0
    It looks like the tunnel was established with the first try and that there were no errors while you did things with a Hyper-V remote session.  Maybe you should try a Hyper-V forum to see if this is a known issue there in some situations.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi Bob,

    I appreciate you checking the connection logs. While I could not see anything there that struck me as a problem, it is nice to have an experienced set of eyes to review this.

    I will drop this into a couple of Hyper-V forums as well to see if they have any answers for me. I will update this post if I find an answer there.

    I have to admit that it seems strange that this VPN tunnel is generating this much bandwidth (see the attached picture) for a HyperV connection through the tunnel with no other use on either end. 
    The far end consists of Two HyperV servers that are not serving any content or users (development is happening on another server), this end has two people with Hyper-V manager connections and one remote session to the Firewall's Admin console.

    With our other firewall's VPN tunnels do not seem to show double up the amount of traffic and have this much management bandwidth use. Yesterday, when the VPN tunnel had failed before noon, I used a about 60 MB of data in 12 hours. Today with the tunnel active. I am already seeing over a GB. No FTP, No web usu, just hyper-V and VPN.

    If anyone else has seen something like this please let me know if there is a solution. Until then, I will not connect my Hyper-V and may leave the tunnel off when it is not needed.

    Thanks for you help.

    Trevor
Unfiltered HTML