Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 3 subscribers
  • Views 10237 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

Site-to-Site SSL-VPN crashed by QoS !?

TobiasBundy1

Hi,

I've got a strange issue with a SSL-based site-to-site VPN between two Sophos UTMs, both running firmware version 9.4

the SSL-tunnel was performing well until I added QoS-rules on the SSL-server's side.

My setup looks like this

site1: network behind the SSL-server

site2: network behind the SSL-client

site3: other network connected through Sophos-RED

 

The treffic-selcotrs are configured like

source: site3

service: voip-reverse (dest.-port=1:65535 ; source-port=5060:5061)

destination: site1

and

source: any

service http-reverse (dest.-port=1:65535 ; source-port=80,443)

destination: site1

 

the bandwidth pools for both traffic selectors are bound to the internal interface.

 

Now, when the Sophos at site2 is trying to connect its SSL-tunnel it fails with the following log entry:

Connection reset, restarting [0]
2017:06:29-21:25:29 gate-site2 openvpn[12968]: PLUGIN_CLOSE: /usr/lib/openvpn/plugins/openvpn-plugin-utm.so
2017:06:29-21:25:29 gate-site2 openvpn[12968]: SIGHUP[soft,connection-reset] received, process restarting
2017:06:29-21:25:29 gate-site2 openvpn[12968]: DEPRECATED OPTION: --tls-remote, please update your configuration
2017:06:29-21:25:29 gate-site2 openvpn[12968]: OpenVPN 2.3.10 i686-suse-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Oct 25 2016
2017:06:29-21:25:29 gate-site2 openvpn[12968]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.09
2017:06:29-21:25:29 gate-site2 openvpn[12968]: Restart pause, 10 second(s)
2017:06:29-21:25:30 gate-site2 openvpn[13305]: TCP connection established with [AF_INET]a.b.c.d:443 (via [AF_INET]192.168.0.2:39784)
2017:06:29-21:25:30 gate-site2 openvpn[13305]: TCPv4_CLIENT link local: [undef]
2017:06:29-21:25:30 gate-site2 openvpn[13305]: TCPv4_CLIENT link remote: [AF_INET]a.b.c.d:443
2017:06:29-21:25:30 gate-site2 openvpn[13305]: WARNING: Bad encapsulated packet length from peer (5379), which must be > 0 and <= 1559 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
2017:06:29-21:25:30 gate-zeestow openvpn[13305]: Connection reset, restarting [0]

 

When reverting back to the old configuration without QoS, the SSL-tunnels springs back to live like nothing had happened.

SSL-based remote-access VPN does not seem to be affected by this issue.

There must be way to get QoS and site-to-site SSL-VPN working at the same time.

Any hints are appreciated.

Regards

Tobias



This thread was automatically locked due to age.
Parents
  • 0

    Hi, Tobias, and welcome to the UTM Community!

    2017:06:29-21:25:30 gate-site2 openvpn[13305]: WARNING: Bad encapsulated packet length from peer (5379), which must be > 0 and <= 1559 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]

    Are the MTUs the same for the External interfaces on the two UTMs?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

    on both firewalls the external interface's MTU is set to 1500.

    Regards

    Tobias

  • 0 in reply to TobiasBundy

    How about pictures of the QoS settings?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to TobiasBundy

    Try setting both indide interface mtus to 1200.   The encyption process adds packet size which is not entirely predictable.   Qos also adds packet size if it is part of tbe tunnel.

     Cisco"s support site has some srticles that explain this in great detail.  They are based on ipsec but many of the concepts will still apply.

     The maximum upper limit can be something higher than 1200, but it is definitely less than 1400.

    Bottom line, you want to ensure that the source packet is not fragmented when it goes into the tunnel.

  • 0 in reply to DouglasFoster

    Hi everyone,

    thank you for your great input.

    Currently this project is lying on ice, so I cannot give you any results about trying your advises.

    When the time for a new attempt comes I will try out your advises.

    Thank you, again, guys.

    Regards

    Tobias

Reply Children
No Data
Unfiltered HTML