Regarding question 1:
LAN games using (UDP) broadcasts typically choose the network interface which uses the lowest metric for its broadcast route (i.e. ip 255.255.255.255
). Most probably your default network interface (e.g. your NIC) has the lowest metric so the games broadcast e.g. on your 192.168.1.0/24
LAN instead of the VPN. You can check your route table with route -vn
on Linux or route print
on Windows.
To get broadcasts on your VPN, do the following on all OpenVPN clients (not on the server):
Add a new broadcast route (255.255.255.255/32
) on your OpenVPN interface with a lower metric than the one your default network interface uses. If such a route already exists on your OpenVPN interface then just change the metric to be the lowest one.
In Windows the broadcast route already exists so you can just change the global interface metric like this:
netsh int ip set int <name_of_your_openvpn_connection> metric=5
This will prioritize the OpenVPN interface if a connection is established. If you seem to have trouble setting the metric, try disabling the Automatic Metric option for the interface.
In Linux you probably just need to add the corresponding route (add a metric if necessary):
route add -host 255.255.255.255/32 <your_openvpn_device>
This will get games like WarCraft III or Anno 1404 to broadcast to the VPN instead of to the local LAN (successfully tested with a Debian OpenVPN server and several Windows 7 clients).
Regarding question 2:
There are plenty of tutorials (also helper scripts) available on how to setup ethernet bridging in OpenVPN.
Note that you don't need any ethernet bridging at all if you just want to be able to play LAN games over OpenVPN. It is enough to use OpenVPN with tap devices, e.g. to also handle broadcasts or protocols like IPX which are needed for old games.
I don't think you can properly do what you are trying to with your current router (unless you can upgrade it to OpenWRT or equivalent.). Its also A LOT harder to do then you think - and probably can't be done through the web interface alone.
As has already been pointed out, each subnet needs to point to the router with an IP in its own netblock.
Thus on LAN Interface of the router you need to have 2 IP addresses - 192.168.0.1 and 192.168.0.254 (or, in the second case, an Ip address in 192.168.0.129 - 192.168.0.254 which you are not using). In order to do this you need to bind a second IP address to the router, and it does not appear to allow you to do this.
Even if you do achieve the above, you are still only part way to your goals.
If you are using DHCP, you need to have the DHCP server answer on both subnets, and provide IP's in the appropriate range for each subnet. Again, this is doable but probably not with your current router.
The question to ask though is "Why are you doing this". Doing this does not buy you any significant security/isolation because the systems are still on the same segment, ie computers in one half can read and respond to broadcast traffic in the other half. The typical way of handling this problem is thus a bit more complex - and again, you need more powerful router software to pull it off. (In order to fully understand what I'm going on about here, you need to understand the difference between a subnet and network segment - the 2 concepts go hand-in-hand, and generally 1 subnet=1 segment, but you are describing 2 subnets on 1 segment - which is often not what you want)
The way I have done something similar is thus -
I got a router which supported OpenWRT. I configured the LAN ports on the router into different VLANS. (Most 4 port routers are interesting in as much as the 4 lan ports are actually individually accessed, and the software makes them appear as a switch and interchangeable - but you can actually program them to be on different VLANS, and provide per-port isolation). You then put each VLAN in a different subnet, and assign an IP address to the router interface for each subnet. You will probably need 2 switches (if you have more then 3 devices in any subnet) - you would need to use 1 of the switches for each subnet. In this way computers are in different network segments and - from a practical POV - can't talk to each other without going through the router. [ That said, I can point you to articles which say don't rely on VLANS for security - although I don't agree with their conclusions ]
Best Answer
I think that the times when operating systems responded to broadcasts pings are long gone. As far as I know every modern operating system ignores those requests as a security measure to avoid broadcast storms.
The default in Linux:
If you want to discover machines you'll have to resort to unicast ping (nmap, ping loop or other means), but note, there can be machines configured to always ignore ping requests.