Broadcast routing on multiple interfaces

[Helix]

Hi,

I am having a problem correctly routing UDP broadcast packets.

I am operating an OpenVPN here to enable online playing of a game (StarCraft to be exact). The game relies on limited broadcasts (destination 255.255.255.255 packets) for game discovery and after trying for a day this is still not working with my VPN setup. Here is what I did:

Right now I am using the following test setup: Two Gentoo machines, both running StarCraft in Wine (because my network knowledge of Linux is much deeper than that of Windows), connected via LAN on eth0 and having addresses from the 192.168.11.0/24 net. One machine doubles as VPN server and StarCraft computer. Firewall and routing is configured identically on both machines, this might change because later the goal is to have a dedicated VPN server and only Windows clients. I am still trying to understand the networking matter in Linux though.
The VPN is using address in the range 10.1.0.0/24 and was using TUN devices. Everything worked except of course for Network Neighborhood browsing (relies on Layer 2 broadcasts I think which TUN does not offer). Direct access with the IP worked fine. The firewall on both computers is configured to block any StarCraft traffic in either direction coming from the LAN and only lets the VPN pass (so I can be sure the game was found over the VPN).

However, games where not found at all. Investigation using Wireshark revealed that the broadcast packets were not reaching the TUN interface nor the other side. Instead there were only LAN packets which where blocked by the firewall. StarCraft games which are looking for an online game (not hosting one) are constantly broadcasting UDP packets with 255.255.255.255 as a destination. Using ip route I added a route with that destination and passing via the IP of the VPN server (10.1.0.1). The game was found then. Trading game server and client and adding another route with the game servers IP worked, too.

While it is working somehow I consider this quite bad a solution. First of all it seemed from the Wireshark output that the previous LAN packets where now VPN broadcast packets only. What I really want is to have the packets on BOTH interfaces (eth0 and tun) using the corresponding source address. This will probably make the game appear twice, once for each path but at least it would correctly represent the setup. Redirecting any limited broadcast through the VPN tunnel is not what I want. I wanna have it per interface. Is that even possible ?

Testing was not over yet. Substituting one Linux computer for a Windows computer without firewall revealed that the same trick was working too but only unidirectional (Linux computer connecting to a Windows game). The reason seemed to be that the routes in Windows were not allowing any limited broadcast onto the tun interface. Route addition like on Linux seems not permitted when it involves broadcast addresses. Connecting from the windows computer to a game on the Linux resulted in broadcast packets with the VPN source IP arriving on the Linux computer's eth0 (so basically totally wrong)

Switching the whole setup to tap interfaces changed something but did not resolve the issue. Both Linux computers behaved exactly the same regardless if I was using tap or tun interfaces. However, using a tap on Windows somehow fixed the routing table, and connecting from there to a Linux hosted game was possible then. The revers was only possible using the extra route again.

From what I read up, it seems as if my only choice is bridging the eth0 and tap device on the VPN server, to obtain a single broadcast domain (two interfaces on it might be a problem though ... ARP fluxing ?). However, I did not want to do that for security reasons.

Any suggestions ?

Thanks a lot.