QOS of Site-to-Site VPN Tunnels

I suspect the routing tables are confused because you have two VPNs established for the same networks.  You need somethiing like:

IPSec VPN:
{Site1.LocalNetwork.subnetA}={Site1.PublicIP}  {Site2.PublicIP}={Site2.LocalNetwork.subnetC}

SSL VPN:
{Site1.LocalNetwork.subnetB}={Site1.PublicIP}:443  {Site2.PublicIP}:43598={Site2.LocalNetwork.subnetD}

Cheers - Bob
PS What is the reason for using 43598 on one end?  How do you make that work?

43598 was created by the system, I did not assign it, I just copied the information available on the "Site-to-Site VPN" page in WebAdmin.
Thank you Bob, I will continue testing.

Hi Bob,
Unfortunately, the problem is still there even after I subnetted my phone equipment. I am sure, the firewall is capable to do QoS properly, there is something wrong with my configuration.
Here it my s2s VPN:
IPSec VPN:
{Site1.dataSubnetA}={Site1.PublicIP}  {Site2.PublicIP}={Site2.dataSubnetB}

SSL VPN:
{Site1.voipSubnetC}={Site1.PublicIP}  {Site2.PublicIP}={Site2.voipSubnetD}

I have also attached the screen shots for the QoS configuration.
Temporary, I have disabled all traffic-consuming services to let voice go through. Please help as soon as you can. Thanks!

In your traffic selectors, try "Any" instead of "External (WAN) Address".

Does that work?

Also, have you tried momentarily disabling the IPsec VPN to prove that VoIP traffic all goes through the SSL VPN?

Cheers - Bob

"Any" or "External" make no difference (just tried)
When I did the change, I tested, the phone traffic uses SSL line, and data uses IPSec.
There is no SSL traffic other than VoIP right now, and voice is still scrambled when data traffic is high.

I think it's time for a support ticket to Astaro.  There's a question we're not thinking to ask, so one of the support engineers needs to put some fresh eyes on the issue.  I think you could point them at your post above: https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/39632/135782#135782, and mention that you tried with "Any" instead of "External" but that voice is still scrambled when data traffic is high.

A temporary band-aid would be to limit the IPsec traffic to 1000kb/sec.

Cheers - Bob

Thanks Bob for your reply in "How to open up ports between subnets in Astaro Security Gateway?" I also think, that the voip server was not provided with DG address, but I don't configure it, and will get this cleared a bit later today.

Regarding the QoS. As a last approach, I swapped my VPN channels with each other, as you suggested earlier. As I figured, there were two remote users utilizing SSL protocol... (didn't think about such possibility) So, my site-to-site data goes via SSL VPN now, and Phones use IPSec. I changed the QoS preference accordingly as well. Guess what? It has become way better than before, but still not 100% clear. Phone system still shows that 5-10% of packets are being lost, and people still complain about voice quality. So, it works exactly the way we configured it! These 5-10% are coming from the phone equipment, but that traffic is not voice, it is the information about phone statuses at each location (status like has new voice mail, busy, call forward on, etc). This information is displayed to the user by the application I mentioned in "How to open up ports" topic. This data packets have the same priority as the voice packets, and of course, the voice gets interrupted.

So, all I have to do is to isolate the voice completely from the data. Please tell me if this will work or not:

1. Put both phones and data back on the same subnet (Site1: 192.168.0.0/24, Site2: 192.168.1.0/24)

2. Create two virtual VoIP networks (one for each site. Site1:192.168.100.0/24 Site2:192.168.101.0/24) by doing Full NAT:
Site1:
Traffic Source: 192.168.0.0/24, Service: VoIP Protocols, Destination: 192.168.1.0/24
Tratslated Source: 192.168.100.0/24, Service: VoIP Protocols, Destination: 192.168.101.0/24
Site2:
Traffic Source: 192.168.1.0/24, Service: VoIP Protocols, Destination: 192.168.0.0/24
Tratslated Source: 192.168.101.0/24, Service: VoIP Protocols, Destination: 192.168.100.0/24

3. Keep VPN channels unchanged:
SSL is for data, serving 192.168.0.0/24  192.168.1.0/24
IPSec is for VoIP, serving 192.168.100.0/24  192.168.101.0/24

4. Keep QoS settings unchanged with a preference to IPSec on External interfaces of each firewall.

What do you think?

It's an interesting idea, but, unfortunately, there's no 1-to-1 NAT option with Astaro, so I don't think that will work.

If you have devices with VLAN capability, then I think this would be the way to go unless you easily can change your wiring scheme to have the phones and PCs on physically-separate networks that get DHCP from different interfaces on your DHCP server.

Cheers - Bob

Bob, my phones are not IP phones, they connected directly to the Control Unit of the phone system. I assume phones may talk TCP/IP but strictly within their subnet.
When it comes to PC to Phone conversation, the actual conversation is between PC and the Control Unit which has information about any phone status. This is how we dial numbers from the PCs.
So, computer network is isolated from the phone network, and all I have to do is to prefer this traffic:
{192.168.100.0/24}  {VoIP Protocols}  {192.168.101.0/24}
because communication other than VoIP (between these two phone networks) causes all kinds of quality problems.
Is this possible to do with Astaro?

Wait a minute - Aren't the phones on the same physical ethernet network with the data network?  There are some phone systems, like the 3Com NBX, that communicate on Layer 2, but ones like Cisco use TCP/IP and have regular IP addresses.  AT&T and others made systems that could communicate via TCP/IP between PBXs even though the phones themselves were connected on their own non-Ethernet network.

Apparently, there's some traffic that's not included in the VoIP services definition in your Astaro.  Adding the other port(s) should fix your problem, but that's a question for the phone system provider.

What we've done should work once all of the right services are added to the VoIP group.  If not, then its time to get your reseller and/or Astaro Support involved to look at your configuration.

Cheers - Bob