[[Category:General]]

== Client Setup ==

* Create separate VLAN interface (Protocol: None, no firewall zone, '''bridge Interfaces''')
** Step 1: create port based VLAN (Network > VLAN > Port Based). Here we use LAN4 to create a new VLAN with ID 4. [[File:Image.png]]
** Step 2: Create Interface (Network > Interfaces > Create New Interface) with the following properties:
*** (General Settings) Protocol: '''none'''
*** (Physical Settings) Bridge Interfaces: '''yes'''
*** (Physical Settings) Interface: '''eth0.3''' (your newly created interface)
*** (Firewall Settings) Firewall zone: '''unassigned'''
** Step 3: Enable Layer2 Bonding in Bondix Settings (Network > Interfaces > Bondix Bonding). Select your newly created interface as bridge interface.

== Server Setup ==

*Create network bridge on Linux server
*Make sure that bridge-utils is installed
* Static IP Address
** via netplan: /etc/netplan/50-cloud-init.yaml, e.g.:
network:
version: 2
ethernets:
eth0:
<KEEP AS IS>
bridges:
sabr0:
addresses: [ 10.133.7.1/24 ]

* Configure DHCP server
** in /etc/dhcp/dhcpd.conf add:

subnet 10.133.7.0 netmask 255.255.255.0 {
range 10.133.7.26 10.133.7.250;
option domain-name-servers 8.8.8.8, 8.8.4.4;
option subnet-mask 255.255.255.0;
option routers 10.133.7.1;
option broadcast-address 10.133.7.255;
default-lease-time 600;
max-lease-time 7200;
}

* In Bondix Server, enable Layer 2 Bonding for the target tunnel(s). L2 Interface name can be left empty, L2 Interface bridge mut be set to configured bridge (e.g. sabr0)

Quality of Service

2026-06-11T11:39:24Z

Sylvia:

[[Category:General]]

==Basics==
[[File:QoS Editor.png|thumb|right|The QoS editor with a default rule.]]With Bondix Quality of Service settings, you can apply different bonding rules for different types of traffic. Traffic can be differentiated via packet type, source, and/or destination IP. Bonding rules allow for setting priority or duplication to limiting bandwidth or optimizing for latency.

===Server: QoS Presets===
On the server side, Bondix comes with a selection of QoS presets which can be used for quick configuration. In effect, Bondix QoS replaces Bondix Tunnel Presets. However, if QoS is to be initiated from the Client, make sure to choose "Custom QoS" in the Tunnel Presets of the General Settings.

Here are the Server's QoS presets at a glance:
{| class="wikitable"
|+
! Preset
!Description
|-
| style="width: 150px" |Bonding
|This is the default preset - bonding over any interface with BondingProxy enabled.
|-
|Bonding (No Proxy)
|Bonding with BondingProxy disabled.
|-
|Packet Duplication
|Default Bonding with packet duplication (1x) enabled.
|-
|Seamless failover
|Only use one interface as indicated by channel priority or latency.
|-
| Satellite
|A preset for satellite scenarios. Satellite is only used for HTTP(S) traffic, except when no other interfaces are available.
|-
|Default QoS
|A more sophisticated preset including a priority rule for DNS traffic, VoIP and online meetings.
|}
A QoS preset consists of one or more traffic groups (QoS group). When a client connects to a server, it sends along its desired QoS configuration which the server can either use or replace with a different configuration. The server also comes with a QoS preset editor which allows you to create custom presets that can be applied on multiple tunnels.
<gallery widths=400px heights=260px>
File:Bondix-123101-qos.png|thumb|QoS settings on Bondix Server
File:Bondix-123101-tunnel-qos.png|thumb|QoS presets for Tunnels on Bondix Server
File:Bondix-123101-qos-presets.png|thumb|QoS presets for Tunnels on Bondix Server, list
</gallery>

===Client & Server: Traffic Group===
A traffic group (QoS group) consists of a ruleset of how traffic should be handled, and a list of matching traffic types to which these rules shoule be applied to.

====Group Settings====
{| class="wikitable"
|+
!Property
!Description
|-
| style="width: 150px" |Name
|This is where you give your traffic group a short descriptive name that ideally describes the type of traffic you want to assign to it.
|-
|Score
| The group's score determines how often it gets the chance to send out data. The minimum value is 1, each additional score point gives the group a bigger slice of available data. Groups with higher score also get to write their data first. View this as a type of priority setting.
|-
|Packet Copies
|This value defines how many copies of each packet should be made. A value of 0 means no duplication, a value of 1 means single duplication, and so on. Packet Copies are opportunistic: If not enough interfaces are available to send the amount of configured copies, less copies will be made.
|-
|Latency Offset
|This setting describes the maximum difference that is allowed between the interface with the lowest and the one with the highest latency. With this setting, you can exclude slow or unreliable lines should their latency become too high. A value of 0 means no limitation.
|-
|Max Down (MBit)
|This value defines the maximum bandwidth allowed downstream in MBit. Downstream always refers to traffic sent from the server to the client. A value of 0 means no limitation.
|-
|Max Up (MBit)
|This value defines the maximum bandwidth allowed upstream in MBit. Upstream always refers to traffic sent from the client to the server. A value of 0 means no limitation.
|-
|Max Channel
|This value sets the maximum number of channels that should be used at once for this group. A value of 0 means no limit.
|-
| Channel Selection
|Here, you can define how channels are selected. These are the possible options:

* Default: This is the default method which considers configured priority, latency and reliability.
* Latency: This option only considers latency (lowest first).
* Bandwidth: This option only considers available bandwidth (highest first).
* Priority: This option only considers priority.
|-
|Bonding Proxy
|If enabled, matching TCP traffic will be bonded using BondingProxy which optimizes bonding throughput and efficiency.
|-
|Always Distribute
|If enabled, traffic is always spread through all interfaces. This is disabled by default as it usually introduces unnecessary jitter but may be beneficial if you're looking to spread traffic evenly across multiple interfaces.
|}

==== Matching Rules ====
Matching rules describe the type of traffic you want to assign to a group.
{| class="wikitable"
|+
!Property
!Description
|-
| style="width: 150px" |Traffic Type
|Possible options:

* Any - ignore traffic type
* TCP
* UDP
* TCP & UDP
* ICMP
* Other - everything else that is not on this list
|-
|Source
|Here, you define the source IP network in CIDR notation. In order to match properly, make sure to disable masquerading on the client. A value of "0.0.0.0/0" means traffic from any source.
|-
|Source Port
|Here, you define the source port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.
|-
|Destination
|Here, you give the destination IP network in CIDR notation. For individual IPs, make sure to include the network prefix /32. A value of "0.0.0.0/0" means traffic to any destination.
|-
|Destination Port
|Here, you give the destination port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.
|-
|DSCP
|Here, you specify the DSCP [[wikipedia:Differentiated_services|Differentiated Services Code Point]] value. A value of -1 means that packets with any DSCP value will match. This value is ignored in combination with Bonding Proxy.
|}
Traffic matching rules are sorted by specificity. That means that the most specific rules are checked on first, the broadest rule is checked last.

<gallery widths=400px heights=260px>
File:Bondix-123101-qos.png|thumb|left|QoS settings on Bondix Server
File:Tel-07045-network-bondixsane-qos.png|thumb|left|QoS settings on Bondix Client for Teltonika 07.04.5
File:Tel-07045-network-bondixsane-qos-detail.png|thumb|left|QoS settings on Bondix Client for Teltonika 07.04.5, Traffic Group detail
</gallery>

===Client: Teltonika===
[[File:Teltonika Preset Selection.png|right]]
If you want to use custom QoS settings on Teltonika routers, make sure that the preset is set to "Custom QoS" and that the assigned server allows Client QoS settings - otherwise the server will override any Client QoS settings. You can verify this via the Status page.

We recommend pushing QoS presets via the Bondix Server because then they're created and managed in a single place and don't have to manage the QoS settings on all routers individually.

==Compatibility==
Client and server are generally backwards compatible. When a legacy client connects to a QoS-enabled endpoint, the client can still apply its original tunnel preset (which is what QoS replaces). When a QoS-enabled client connects to a legacy server, it will always use the default "Bonding" tunnel preset, or the preset propagated by the legacy server.

== Best Practices ==

* Always create a default rule that matches to any traffic. Traffic without an appropriate matching rule will still be transmitted but performance results may vary.
* BondingProxy uses ''iptables'' rules to redirect matching TCP traffic. To exclude certain traffic from BondingProxy, create a new group with matching rules and the proxy disabled. This will create appropiate exclusion rules for ''iptables''.

Teltonika Portforwarding

2026-06-11T11:39:13Z

Sylvia:

[[Category:General]]

== General port forwarding settings ==
For TCP port forwarding a separate configuration of a forwarding on the router with the Bondix client is not necessary if:

* the port forwarding is configured via the web interface
* only TCP ports are forwarded
* the Bonding proxy is in use
* port forwarding is enabled in the Bondix client advanced settings.

For any kind of port forwarding which includes UDP ports, iptables (or equal) rules will be needed on the server side.

In this case, there is also a need to configure a port forwarding on the Bondix client router. For Teltonika see below.

== UDP Port Forward from a Teltonika router to the server ==
In this example, we are going to create two port forwardings to make a UDP port behind a Teltonika Router accessible via the endpoint's public IP. The first port forwarding will be created on the router, forwarding traffic from the Bondix tunnel towards the device in LAN. The second port forwarding will be created on the endpoint server, forwarding requests from it's public IP to towards the appropiate tunnel.

But first, lets make sure on the server that the tunnel in question is configured with a fixed IP, as it will make things much easier:

[[File:Fixed IP for tunnel.png]]

The IP must be part of the environment's virtual network which the tunnel used (169.254.xx.0/24 by default). In this example, we are using ''169.254.20.2.''

Next, go to the router's webinterface and navigate to Network > Firewall > Port Forwardings. In this example, we are going to create a port forwarding from a device in LAN towards the Bondix tunnel:

[[File:Teltonika Port Forward Settings.png]]

* Protocol: as required by your needs. Defaults to TCP+UDP, change to UDP.
* Source zone: "bondix" (where the request is coming from)
* External port: The port used for the forwarding. This port used here is just intermediate and can be used freely, although it is advised to use a port number higher than 1024.
* Internal zone: "lan" (where the request should be forwarded to)
* Internal IP address: the target device
* Internal port: the target port

In the firewall general settings, make sure that Masquerading for LAN => Bondix is enabled.

Finally, the second port forwarding must be set up on the server:
iptables -A PREROUTING -t nat -i eth0 -p udp --dport 20022 -j DNAT --to 169.254.20.2:12345
iptables -A FORWARD -p udp -d 169.254.20.2 --dport 20022 -j ACCEPT
Make sure that the following argument is correct:

* eth0 - the interface name used on your server might differ
* 20022 - this is the port that the will be used for forwarding, and will be publicly accessible.
* 169.254.20.2:12345 - the tunnel ip + intermediate port used.