Tutorial: Forward Multicast Traffic Between VPN Clients Across Multiple Daemons in Access Server⁠

Overview⁠

OpenVPN Access Server can allow UDP multicast and IGMP traffic between VPN clients. In a single-daemon configuration, the vpn.routing.allow_mcast configuration key allows multicast and IGMP traffic to pass through Access Server.

Multi-daemon mode requires additional configuration. By default, Access Server runs one UDP and one TCP OpenVPN daemon per CPU core. Each daemon has its own Linux tun interface, named as0t0, as0t1, and so on. VPN clients connected through different daemons can therefore be on different as0t interfaces.

For multicast forwarding between these clients, the Access Server host must route multicast traffic between VPN interfaces.

This tutorial configures SMCRoute, a third-party static multicast routing daemon for Linux, to forward multicast traffic between the as0t interfaces. SMCRoute isn't included with Access Server and isn't installed, managed, or upgraded by OpenVPN.

If you only need to enable multicast and IGMP without routing between multiple VPN daemons, see Tutorial: Allow UDP Multicast and IGMP to Pass Through.

Example setup⁠

In this example, two VPN clients exchange traffic using multicast group 239.1.1.1.

The caster sends traffic to 239.1.1.1.
The subscriber joins 239.1.1.1.
The clients are connected through different OpenVPN daemons and therefore different as0t interfaces.

Prerequisites⁠

Before you begin, ensure you have:

Access Server installed on Ubuntu 22.04, 24.04, or 26.04.
Console access and the ability to get root privileges.
At least two CPU cores on the Access Server.

Firewall backend⁠

This tutorial includes configuration for both nftables and iptables mode.

Access Server 3.1.0 and newer uses nftables by default. Follow the nftables instructions in Step 7 unless your deployment is explicitly configured to use iptables.

If Access Server 3.1.0 or newer has been switched to iptables mode with: xtables=iptables, follow the iptables instructions instead.

For additional background, see Tutorial: Managing nftables Settings in Access Server and Tutorial: Managing iptables Settings in Access Server.

Connect to the console and get root privileges.

Allow VPN clients to communicate with each other:

sacli --key "vpn.client.routing.inter_client" --value "true" ConfigPut

Enable UDP multicast and IGMP traffic:

sacli --key "vpn.routing.allow_mcast" --value "true" ConfigPut

Restart Access Server services:
```
sacli start
```
Connect both VPN clients.

Before configuring multicast forwarding, verify that unicast traffic works between them. For example, on the caster:

root@caster:~# ip -4 addr show tun0
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1420
    inet 172.27.236.2/22 scope global tun0
root@caster:~# ping -c 3 172.27.232.2
PING 172.27.232.2 (172.27.232.2) 56(84) bytes of data.
64 bytes from 172.27.232.2: icmp_seq=1 ttl=63 time=14.2 ms
64 bytes from 172.27.232.2: icmp_seq=2 ttl=63 time=13.4 ms
64 bytes from 172.27.232.2: icmp_seq=3 ttl=63 time=13.3 ms
--- 172.27.232.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Multicast forwarding requires packets to traverse the as0t tun interfaces so the Linux kernel's multicast routing can process them. DCO bypasses the networking path required by this configuration.

Turn off DCO:

sacli --key "vpn.server.daemon.ovpndco" --value "false" ConfigPut
sacli start

Verify that the as0t interfaces no longer report an ovpn link type:
```
ip -details link show | grep -A2 as0t
```

Each OpenVPN daemon has its own as0t tun interface. The number of interfaces depends on the CPU count and OpenVPN daemon configuration. For example, an Access Server with two CPU cores can run two UDP and two TCP daemons, resulting in four as0t interfaces.

List the VPN interfaces and their IPv4 addresses:

root@as:~# ip -br -4 addr show | grep as0t
as0t0   UNKNOWN   172.27.224.1/22
as0t1   UNKNOWN   172.27.228.1/22
as0t2   UNKNOWN   172.27.232.1/22
as0t3   UNKNOWN   172.27.236.1/22

Record each as0t interface name. You'll configure all of them in Step 5.
Important
Changing the Access Server CPU count or daemon configuration can change the number of as0t interfaces. If that happens, repeat this step and update the SMCRoute configuration in Step 5. Otherwise, multicast traffic won't reach clients connected through interfaces that aren't configured in SMCRoute.

For information about changing daemon configuration, see Tutorial: Turn Off Multi-Daemon Mode and Use Only TCP or UDP.

Install SMCRoute on the Access Server host:
```
apt update
apt install smcroute
```
Verify the package installs:
- smcrouted — the multicast routing daemon.
- smcroutectl — the command-line tool for managing and inspecting SMCRoute.

Configure SMCRoute to forward multicast group 239.1.1.1 between the VPN interfaces identified in Step 3. Each mroute entry defines an inbound interface and the interfaces where SMCRoute should forward matching multicast packets. The packet isn't sent back through the interface where it arrived, so you need one route for each possible inbound interface.

Open /etc/smcroute.conf in a text editor:
```
nano /etc/smcroute.conf
```

Enable multicast routing on each VPN interface:

phyint as0t0 enable
phyint as0t1 enable
phyint as0t2 enable
phyint as0t3 enable

Configure multicast forwarding for 239.1.1.1 between the interfaces:

mroute from as0t0 group 239.1.1.1 to as0t1 as0t2 as0t3
mroute from as0t1 group 239.1.1.1 to as0t0 as0t2 as0t3
mroute from as0t2 group 239.1.1.1 to as0t0 as0t1 as0t3
mroute from as0t3 group 239.1.1.1 to as0t0 as0t1 as0t2

Save the file and exit the editor.

For a server with a different number of as0t interfaces, you can generate the equivalent configuration:

GROUP=239.1.1.1
IFACES=$(ip -br link show | grep -o '^as0t[0-9]*')

{
    for i in $IFACES; do
        echo "phyint $i enable"
    done

    echo

    for i in $IFACES; do
        out=$(echo "$IFACES" | tr ' ' '\n' | grep -v "^${i}$" | tr '\n' ' ')
        echo "mroute from $i group $GROUP to $out"
    done
} > /etc/smcroute.conf

Restart SMCRoute:
```
systemctl restart smcroute
```
Confirm that SMCRoute accepted the routes:
```
smcroutectl show routes
```

To forward a multicast range instead of a single group, specify a prefix such as:

group 239.0.0.0/8

Omitting source from an mroute means traffic can originate from any source. This is useful for VPN clients because their addresses may be assigned dynamically. The kernel installs the active multicast route for a sender when it receives the first packet, so the first packet of a new stream may be dropped.

Running sacli start recreates the as0t interfaces. This invalidates the virtual interfaces SMCRoute uses, so SMCRoute must start after Access Server and restart whenever Access Server recreates those interfaces.

Review the existing SMCRoute systemd unit:
```
systemctl cat smcroute
```

Create a systemd drop-in so SMCRoute starts after Access Server at boot:

mkdir -p /etc/systemd/system/smcroute.service.d

cat > /etc/systemd/system/smcroute.service.d/10-after-openvpnas.conf <<'EOF'
[Unit]
After=openvpnas.service
Wants=openvpnas.service
EOF

systemctl daemon-reload

After each time you run sacli start, restart SMCRoute:
```
systemctl restart smcroute
```
Important
This is a common cause of multicast forwarding working immediately after setup and then stopping after a later configuration change. Any change that runs sacli start, including changes made in the Admin Web UI, recreates the VPN interfaces and requires an SMCRoute restart.

For additional SMCRoute configuration options, refer to the official SMCRoute documentation.

Multicast TTL determines how many routing hops a multicast packet can traverse. Multicast senders commonly use a TTL of 1, which confines traffic to the local network. For the traffic in this tutorial to pass through Access Server's multicast router, it needs a TTL of at least 2.

Whenever possible, configure the multicast TTL in the sending application. This avoids modifying firewall rules on Access Server. For example, with socat:

socat - UDP4-DATAGRAM:239.1.1.1:5000,ip-multicast-ttl=2,ip-multicast-if=172.27.236.3

If you can't change the sender, modify the TTL as the traffic enters Access Server. Follow the section for your firewall backend.

Using nftables (Access Server 3.1.0 and newer)⁠

Access Server 3.1.0 and newer uses nftables by default. Create your multicast TTL rule in a custom table rather than modifying the Access Server-generated as_filter, as_nat, or as_mangle tables. Those generated rules can change when Access Server restarts or is upgraded.

Create a custom nftables table and PREROUTING chain:
```
nft add table ip openvpn_mcast_ttl
nft add chain ip openvpn_mcast_ttl PREROUTING '{ type filter hook prerouting priority -151; policy accept; }'
```
1. Priority -151 places the custom chain immediately before Access Server's as_mangle PREROUTING chain at priority -150.

Set the TTL to 2 for multicast packets entering each VPN interface:

for i in $(ip -br link show | grep -o '^as0t[0-9]'); do
  nft add rule ip openvpn_mcast_ttl PREROUTING iifname "$i" ip daddr 239.1.1.1/32 ip ttl set 2
done

Adjust the destination address if you configured a different multicast group or range in Step 5.
Verify the custom table:
```
nft list table ip openvpn_mcast_ttl
```
Important
Rules added with nft add don't persist across a reboot. Save the table and configure nftables to restore it at boot. For example:
nft list table ip openvpn_mcast_ttl > /etc/nftables.d/90-multicast-ttl.nft
Include the file from /etc/nftables.conf, and verify the custom table after Access Server upgrades.

See Tutorial: Managing nftables Settings in Access Server for more information about Access Server's nftables tables, chains, and priorities.

Using iptables (Access Server before 3.1.0, or after switching from nftables)⁠

Access Server versions before 3.1.0 use iptables by default. Access Server 3.1.0 and newer can also be explicitly configured in iptables mode.

If your deployment is configured to use iptables:

For Access Server 3.1.0 and newer, verify that as.conf contains:
```
xtables=iptables
```
If you change this setting, perform a full Access Server service restart:
```
service openvpnas restart
```
Configure Access Server to append its generated iptables rules after existing rules so the custom TTL rules retain precedence:
```
sacli --key "iptables.append" --value "true" ConfigPut
sacli start
```

Increment the TTL by 1 for traffic entering each VPN interface:

for i in $(ip -br link show | grep -o '^as0t[0-9]'); do
  iptables -t mangle -I PREROUTING 1 -i "$i" -d 239.1.1.1/32 -j TTL --ttl-inc 1
done

Adjust the destination if you configured a different multicast group or range in Step 5.
Verify the rules:
```
iptables -t mangle -L PREROUTING -n -v --line-numbers
```
Important
These custom iptables rules don't persist across a reboot. Make them persistent using the method appropriate for your Linux distribution, such as iptables-persistent or a systemd unit ordered after openvpnas.service.
Recheck the rules after running sacli start.

See Tutorial: Managing iptables Settings in Access Server for additional guidance.

The Linux kernel's mc_forwarding flag indicates whether IP multicast routing is active on an interface. SMCRoute causes the kernel to enable this state for the interfaces it manages.

Verify the kernel is forwarding multicast on the VPN interfaces:
```
root@as:~# sysctl -a 2>/dev/null | grep mc_forwarding
net.ipv4.conf.all.mc_forwarding = 1
net.ipv4.conf.as0t0.mc_forwarding = 1
net.ipv4.conf.as0t1.mc_forwarding = 1
net.ipv4.conf.as0t2.mc_forwarding = 1
net.ipv4.conf.as0t3.mc_forwarding = 1
```
Note
mc_forwarding is read-only. Don't attempt to set it manually.
A value of 0 indicates that the multicast routing daemon isn't active for that interface. Verify that smcrouted is running and that each required interface has a phyint entry in /etc/smcroute.conf.
Review the configured multicast routes:
```
smcroutectl show routes
```
Review multicast group state:
```
smcroutectl show groups
```

Test multicast forwarding between a subscriber and caster. Skip this if your application joins the group itself.

On the subscriber⁠

If the application doesn't join the multicast group itself, install SMCRoute and join the group on tun0:
```
root@subscriber:~# apt install smcroute
root@subscriber:~# smcroutectl join tun0 239.1.1.1
```
Install socat:
```
apt install socat
```

Listen for multicast datagrams:

socat -u UDP4-RECV:5000,ip-add-membership=239.1.1.1:tun0,reuseaddr -

On the caster⁠

Install socat:
```
apt install socat
```

Send multicast traffic once per second:

while :; do echo "mcast $(date +%T)"; sleep 1; done |   socat -u - UDP4-DATAGRAM:239.1.1.1:5000,ip-multicast-ttl=8,ip-multicast-if=172.27.236.3

Expected result⁠

The subscriber receives multicast packets similar to:

root@subscriber:~# socat -u UDP4-RECV:5000,ip-add-membership=239.1.1.1:tun0,reuseaddr -
mcast 13:57:52
mcast 13:57:53
mcast 13:57:55
mcast 13:57:56
mcast 13:57:57
mcast 13:57:58
mcast 13:57:59
mcast 13:58:00
mcast 13:58:01
root@subscriber:~#

On Access Server, verify that SMCRoute shows the active route and the expected inbound and outbound interfaces:

smcroutectl show routes

Symptom	What to check
No multicast traffic reaches Access Server.	Verify that `vpn.routing.allow_mcast` is `true` and that the sender is bound to its VPN interface.
Traffic reaches one `as0t` interface but isn't forwarded.	Verify that every required `as0t` interface has a `phyint` entry and appears in the appropriate `mroute` entries (Steps 3 and 5). Run `smcroutectl show routes` and verify that `mc_forwarding` is `1`.
Multicast forwarding worked and then stopped.	Access Server may have restarted and recreated its `as0t` interfaces. Restart SMCRoute as described in Step 6.
Traffic is forwarded but doesn't reach clients.	Check the multicast TTL. Verify that the sender uses a TTL greater than `1` or that the nftables/iptables rules from Step 7 are present and match the multicast group.
Only the first packet from each stream is lost.	This is expected when the multicast route accepts traffic from any source. The kernel installs the forwarding entry when the first packet from that sender arrives.
Multicast works for some clients but fails as more connect.	Check whether new clients connected through an `as0t` interface missing from the SMCRoute configuration. Also verify that the system hasn't reached its multicast VIF limit. Recheck Steps 3 and 5.