IPSEC low bandwitdh

[blainvillem]

Good morning, sir,

I have two ipsec tunnels between two pfsense router's. One that leaves my local network with overthebox and one that leaves my local network with openmptcprouter and both go to an ovh network.

Expected Behavior

I'd like both tunnels to work equally well. With a higher throughput for the tunnel through mptcprouter.

Actual Behavior

The tunnel going through overthebox has a throughput of about 8mo/s and the other one going through openmptcprouter is at 300ko/s.

Specifications

• OpenMPTCProuter version: version 0.51.5
• OpenMPTCProuter VPS version: 0.1000 4.19.56-mptcp
• OpenMPTCProuter platform: x86_64

[blainvillem]

EDIT:

When I disable an interface on either WAN on MPTCPROUTER the throughput in my ipsec tunnel becomes good again. I think the problem comes from the mptcp protocol.

[Ysurac]

You can try an other TCP Congestion Control and an other Multipath TCP scheduler in Network->MPTCP

[blainvillem]

You can try an other TCP Congestion Control and an other Multipath TCP scheduler in Network->MPTCP

Hello, I've made all the possible changes with Multipath TCP scheduler and Congestion Control, but nothing improves the situation we remain stuck at about 512kbps.

Do you have another idea? Knowing that the problem can't come from the tunnel an identical tunnel works to overthebox.

[blainvillem]

[slitsevych]

Hi @blainvillem ! Have you tried to increase fullmesh subflows to 2 or more? Although my infrastructure is not exactly same as yours, we also use pfsense routing. In our case OMR/MPTCP works fine with fullmesh path-manager, 2 fullmesh subflows and "olia" as congestion control mode. We also switched from Glorytun-TCP to Glorytun-UDP and use "Master interface selection - no change" at "cgi-bin/luci/admin/system/openmptcprouter/settings". Besides that we've disabled TCP Fast Open and set up all relevant (LAN,WAN1,WAN2) interfaces as bridges over system eth interfaces:

I hope some of these suggestions will be helpful

[blainvillem]

Salut @blainvillem ! Avez-vous essayé d'augmenter les sous-flux fullmesh à 2 ou plus? Bien que mon infrastructure ne soit pas exactement la même que la vôtre, nous utilisons également le routage pfsense. Dans notre cas, OMR / MPTCP fonctionne très bien avec le gestionnaire de chemin d'accès fullmesh , 2 sous-flux fullmesh et " olia " comme mode de contrôle de la congestion. Nous sommes également passés de Glorytun-TCP à Glorytun-UDP et utilisons " Sélection de l'interface principale - pas de changement " dans " cgi-bin / luci / admin / system / openmptcprouter / settings ". En plus de cela, nous avons désactivé TCP Fast Open et configuré toutes les interfaces pertinentes (LAN, WAN1, WAN2) comme ponts sur les interfaces eth du système:

J'espère que certaines de ces suggestions vous seront utiles

Hello, first of all I wanted to thank you for your help.

I tried to change "fullmesh", 2 sub-flow fullmesh and "olia" but it didn't change anything in terms of throughput in the tunnel, still blocked at about 512kbps.

Concerning Glorytun, I'm already in udp without having changed the default configuration.

For the configuration of LAN / WAN 1 / WAN 2 interfaces in bridge it didn't work, I don't have internet in my local network anymore and here are the errors in the preview :

PS: I couldn't find where to disable "TCP Fast Open".

[blainvillem]

I think you have at least 3 network cards on your mptcprouter while I have only one. My mptcprouter is a virtual machine on a "Vmware" ESX. That's why it's impossible for me to bridge several different cards.

But I can add virtual network cards if needed, if this is the solution to our problem.

After what is weird is the fact that the network throughput works very well from a computer using mptcprouter as default gateway. But also that the tunnel works pretty well with only one of the two WANs enabled on mptprouter. The tunnel blocks at about 512kbps when both interfaces are activated with one master and the other one activates "Mptcp".

[slitsevych]

Hi again! I'm really sorry to hear that none of the suggestions helped, however I would like to add that in our case we also configured mptcprouter as a VM of KVM type created within local Proxmox cluster. Interfaces are being added as virtual NICs: All of them are also bridged from corresponding vlan interfaces added manually in /etc/network/interfaces and configured in Pfsense. so it is something like this: vlan20 (pfsense) --> vmbr20 bridge (proxmox node network) --> net2 (as defined in VM hardware page) --> eth2 (as listed in kernel) --> wan2 (as initially in mptcprouter) --> br-wan2 (after creating bridge in OMR Interfaces). We decided to use bridged mode after several tests which showed that in our setup gateways and routes are more stable if we use bridged mode.

Not sure if this helps, but I just wanted to add these small nuances.

p.s: You can disable TCP Fast Open, change master interface selection, etc in Advanced Settings under System --> Openmptcprouter

[blainvillem]

Thank you. Thank you, I just tried and no change for the "TCP Fast Open" configuration. Concerning the bridges with network cards, I don't know if it will change much since the throughput works very well without aggregating connections to access the tunnel.

I'll wait to hear back from Mr Yannick Chabanois, if you have other proposals, I'd be happy to try.

Especially the ipsec configuration of your pfsense "AES GCM 3DES SHA256 encryption..."

Because even on overthebox or directly from my two ISPs I don't get a very high throughput in the tunnel "3 to 8 mbps maximum" for a connection of several hundred mbps.

[blainvillem]

After several tests during the day, I realized that the problem probably came more from my "pfsense" firewall routers. Or compared to the fact that they are hosted in a vmware esx.

I have 1.5 mbps throughput per mptcprouter and 3.5 mbps per overthebox.

[blainvillem]

https://forum.netgate.com/topic/149905/ipsec-low-throughput

If you want more informations.

[blainvillem]

UP

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days