OpenVPN Broadcast on Tunnel Network

Rick

8/10/24, 1:52 PM

I need some explanation about the post subject: my scenario is described in the linked image:

I've an APP for smartphone that should communicate with the End Device, I've make all the configurations (using OpenVPN with TUN configuration) and all work fine, I can ping from the smartphone the End Device, and the other devices present in the diagram. Now the problem is this: the APP use a discovery packet to find the End Device, and this can't works cause broadcast packets can't travel between different networks/subnets. I'd like to try to configure dst-nat to transform the broadcast received from the Mikrotik to an unicast directed to the End Device IP, like Cisco IP Helper, I read that this should be possible, but doing some test I discover a strange behavior: from the prospect of the smartphone, the interface tun0 (that rise up when the tunnel is running) should be a direct connected interface, so I expect that the broadcast packets generated by the APP and leaving this interface should reach all the tun0 interface of the others devices tunnel, like a common LAN, like ARP request packets, obviously these packets could't forward over the tunnel network. Running WireShare on the PC and capturing from the PC tun0 interface I can't see the broadcast packets generated from the smartphone APP. Why???

I try to do this test: delete the arp table of the pc and execute a ping to the smartphone, to force the pc make a new arp request from the tun0 to find the phone tun0 mac address, all captured with wireshark. I discover that the pc executes an ARP request with Source MAC 00:ff:af:18:2b:e8 (tun0) and Destination MAC ff:ff:ff:ff:ff:ff, the ARP reply arrives by a Source MAC address with this value 00:ff:b0:18:2b:e8 (!!!) and Destination MAC 00:ff:af:18:2b:e8 (the original pc source of the request, this is correct). Practically seams that this MAC reply source address is the same value of the PC Source MAC Request andress but with the third byte increased by 1, I try also to do this test with other devices and for different MAC address, the one of the MAC reply has always the third byte increased by 1.

So I suspect that the broadcast that leave the tun0 from any device interfaces actually didn't go through the tunnel network but is closed back by a local virtual MAC address that reply like it was a gateway. Probably, data management like ARP ecc. is managed inside the tunnel with dedicated protocols. If this is true, there is not way to bring broadcast to the End device, neither with IP Helper manner. The main problem is that I can't use TAP interface cause IOS does'nt support it, and also Android with OpenVPN 3 is going to that direction.

thanks! R

0 + 5

openvpn

Nikita Kipriyanov

8/10/24, 4:11 PM

There is no MAC layer on `tun` devices. They are layer3, while MAC is layer2. But you're partially right: the other end of a `tun` device is not other VPN peers or network; it's a *program* which opened the tun device using certain API, in this case, it's OpenVPN. This is the place where you need to enable broadcasts. I don't know if it supports that.

Nikita Kipriyanov

8/10/24, 4:15 PM

Also don't consider whatever you see in Windows as relevant: Windows doesn't have true `tun` driver and it's somewhat imitated with the `tap` driver, which is "usual Ethernet" from Windows standpoint. The imitation is not perfect. This is the reason for Windows clients only support "net30" OpenVPN addressing scheme. The MACs you see there are internal to your OpenVPN process running at that system and don't appear anywhere else (the point of L3 VPN which is achieved by using `tun` is to not to transmit MAC addresses and thus have less overhead).

Rick

8/11/24, 10:36 AM

Hi Nikita, thanks for your reply. OpenVPN seams be not have options about broadcast on tun interface. At this point probably I have to looking for another VPN type, openVPN TAP is not supported by android and IOS. I could use L2TP to make a transparent L2 tunnel but I have to check all the compatibility on the entire design. I see also Wireguard but I never used it, PF Sense not support it but I could think to use a linux distro wirh wireguard server instead of PF sense distro.

Nikita Kipriyanov

8/11/24, 5:16 PM

WireGuard is not an option either, it's strictly L3. Honestly, I think your idea of running Ethernet-only app over the VPN is problematic in the first place.

Rick

8/14/24, 4:04 PM

I think so Nikita, but it all depends on the fact that these apps talk with devices using discovery on broadcast packets..... I hope the vendor will change this behavior, I'am seeing that Layer 2 VPN on mobile environment are strongly discouraged and unsupported.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: OpenVPN Broadcast on Tunnel Network

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.