Proper setup for Broadcast, Multicast? (large mail)
Mark Morschhäuser
mark.morschhaeuser at rwth-aachen.de
Fri Oct 11 11:01:30 CEST 2013
Hello,
I have some questions regarding the proper tinc configuration to allow
IP-broadcasting, IPX etc. aka the complete gaming setup.
I searched the net and did not find a working (or well enough documented)
solution for my needs.
Let me describe what I want and what I tried so far and what worked or
failed.
I want to use the following setup with three machines (all with the same
tinc version tinc-1.0.22), all in different provider networks:
- One server (Gentoo Linux) with one physical network card eth0 and a
fixed, public IP address, let's say 137.foo.
- Two clients A and B (both Sabayon Linux), each with one physical network
card eth0 but with a private class C IP because they are behind DSL
routers with NAT.
- The internal class C network for client A is 192.168.2.0/24 and the
network used by client B is 192.168.1.0/24.
- The DSL routers change their external, public IP every day.
- For ease of use both clients should connect to the server only (I don't
want to edit the certificates every time a client's IP address changes and
port forwarding on client A is no fun, though it works on client B).
- The vpn has to run in switching mode and uses it's own private class C
network on the virtual network device "vpn": 192.168.77.0/24. The server
uses 77.1, the clients 77.2 and 77.3
The game in this case is Baldurs Gate 2, played via wine: The game needs
DirectPlay for network play, which was installed properly and may use IP
or IPX.
Now, I created the certificates and configuration which allow me to
connect client A and B to the server.
-------------------------------------------------
Name = clienta #... or clientb or server
ConnectTo = server
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv
Mode = Switch
Port = 2000
Subnet = 192.168.77.0/24
-------------------------------------------------
Short:
Server: eth0 (137.foo), vpn (192.168.77.1)
Client A: eth0 (192.168.2.100), vpn (192.168.77.2)
Client B: eth0 (192.168.1.2), vpn (192.168.77.3)
It is possible for client A and B (and the server) to ping each other and
create TCP connections to the server (I tried http and irc to the server
via vpn).
I did not try direct TCP connections from A to B ore vice versa, I assume
that this works (afair we succeeded with a direct connection one year
ago), but as the game we use does not work this way (and as a proper
configuration allows all types of connections anyways) it was not my goal
to test direct connections now.
Now comes the problem:
If I try to send a broadcast message over the vpn (e.g. echo hello | socat
- UDP-DATAGRAM:192.168.77.255:5000,broadcast while all machines do nc -lup
5000) from client A, only the server and client A itself get this message.
I started the game and tried to search/connect client A with B but
wireshark told me that there are no incoming messages from the other
client during the search, only outgoing DirectPlay messages.
So my guess is the server eats the broadcast data somehow.
The server has IP forwarding enabled though as I understand it, tinc does
not need this in switching mode.
So I eliminated the server from the configuration and connected client A
with client B directly and hoped that it works now.
But: After trying the netcat and game broadcastings like before, I still
had the same problem that client B did not get any data from client A.
This should work like a crosscable connection so I don't understand where
the problem is.
Well, I knew that the howtos for tinc and openvpn write about bridging the
vpn interface with a physical one to achieve this (why in the world is
this needed? The connection works obviously, but why does broadcasting
need a bridge to a real network card? I can create any packets and send
them anywhere I want, or not?) so I tried - and failed - to create the
bridge (still using the direct connection from A to B without the server):
Client A: eth0 (0.0.0.0 promisc), vpn (0.0.0.0 promisc), br0
(192.168.2.100), br0:0 (192.168.77.2) - and route via br0 of course
Client B: eth0 (0.0.0.0 promisc), vpn (0.0.0.0 promisc), br0
(192.168.1.2), br0:0 (192.168.77.3) - dito
Again: ping worked, broadcast/game did not.
(I tried IPX now via the bridge but it did not work - I used br0 instead
of br0:0 so this was a mistake but I did not see that at the time I tried
this. Can tell me if this setup should have worked?)
So I tried IPX after removing the bridge configuration and returning to
the simple direct connection from client A to B.
After using ipx_interface add -p vpn 802.2 0x12345678 on client A and B
the game worked instantly. It found the open session running on the other
client, was able to connect and we were able to play.
The next thing I did: I added the server again and removed the direct
connection from client A to client B, like it was the first time and how I
want it to be.
IPX now failed also. I did not take care of routing ipx on the server so
maybe it was a wrong configuration. But if tinc really works like a switch
there should be no need for any routing at all and IPX should have worked
like before (same argument as IP forwarding?), shouldn't it?
So... what did I do wrong? Is there something I overlooked? Did I
misunderstand how tinc works? I tried that with openvpn also but aside
from having a huge certificate and CA overhead it did not work better or
worse than tinc so far.
The bridging configuration seems to be the worst documented step ever in
the internet; many howtos use an additional network card eth1 in this case
without telling me details (is this some sort of gateway setup or what?)
and just use private IP ranges without telling me about the purpose or
routing of those networks or if those are for the vpn or used internally
or whatever...
So with only one eth in each machine it should work like I tried it, right?
Another thing:
I also tried to forwarding Multicast traffic into the VPN. The server is
able to receive Multicast traffic from several sources and I want to route
the data into my VPN.
I don't know if tinc supports Multicast at all, I hope that it does
because someone on the net wrote that he successfully forwarded Multicast
to his Playstation using igmpproxy and OpenVPN.
Here is my setup, the server's kernel has everthing it should need:
[*] IP: multicast routing
[*] IP: PIM-SM version 1 support
[*] IP: PIM-SM version 2 support
I tried igmpproxy in debug mode and it tells me that it found a proper
config for upstream eth0 interface (where the multicast is) and the
downstream vpn interface (where it should be routed to), which is all you
have to configure for igmpproxy, but it only finds queries from itself
(192.168.77.1) so nothing happens on my client and igmpproxy has an empty
routing table.
Maybe this needs the same proper setup as broadcasting, if you can explain
if and why and where a bridge is needed and where I made mistakes, this
would be very great.
Thanks in advance and sorry for this large text, but I want to be sure
there are no misunderstandings regarding my setup so the error can be
found easily.
Best regards,
Mark
More information about the tinc
mailing list