Bridging on windows networks

[Anon]

WOW!  What a great tutorial.  Thanks.  I'm probably going to end up
going the easy way, but I'm learning so much that I'm chomping on the
bit to make the hard way work, just as an exercise, with a limited
portion of my network, for educational purposes.

Of course, I get stuck right out of the gate.  I tried adding a route
on 192.168.0.188 so that 10.20.30.1 would ping, and it doesn't.

This is what I tried:

route ADD 10.20.0.0 MASK 255.255.0.0 192.168.0.155

This added the following line to the route table:

10.20.0.0   255.255.0.0 192.168.0.155 192.168.0.188 1

But ping fails.

Is there a step I've missed?

Thanks, again.  Give me a day or two to digest the "easier way" and
I'll try and implement it.

************************************************************************************

It will be much easier if you could just use 192.168.x.y addresses for the VPN
as well. But first let me tell you what needs to be done to get it working with
10.20.x.y addresses on the VPN.

HARD WAY:

When 192.168.0.188 sends a packet to 10.20.x.y, it needs to have an entry in
its routing table that says that packets for 10.20.0.0/16 should go to
192.168.0.155.

Then, you should be able to ping 10.20.30.1. However, pinging any other node on
the VPN will not work yet. Suppose 192.168.0.188 tries to ping 10.20.40.1. Tinc
on 192.168.0.155 will pick the ping packets up and forward them to 10.20.40.1.
There, the kernel will generate an ICMP reply, and will try to send it back to
192.168.0.188. For that, it needs to have an entry in its routing table that
says packets for 192.168.0.0/16 should go to the VPN adapter.

Tinc on 192.168.1.155 will then pick it up, but it needs to know where to send
packets with destination address 192.168.0.188 to. For that, the tinc daemon on
192.168.0.155 should have Subnet = 192.168.0.0/24 in its host config file.

Suppose there are more hosts on the other LANs as well, and 192.168.0.188 wants
to ping 192.168.1.199. Then 192.168.0.188 must have an entry in its routing
table that says packets for 192.168.0.0/16 should go via the VPN, 192.168.1.155
must have Subnet = 192.168.1.0/24 in its host config file, and 192.168.1.199
must also have an entry in its routing table that says packets for
192.168.0.0/16 should go via the VPN.

If any host should be able to communicate with any other host on the VPN, you
are going to have to add a lot of routes... If you can control the routing
table of the gateway of each LAN (I assume having IP address 192.168.0.1,
192.168.1.1 and 192.168.2.1), you can add an entry in each of them directing
packets with destination 10.20.0.0/16 and 192.168.0.0/16 to the host running
tinc on each LAN. But, then packets will be sent twice over the LAN, which is
not so efficient.

EASIER WAY:

It is much easier to use tinc's switch mode, and to bridge the LAN to the VPN
interface on each host running tinc. Then, you don't need to configure Subnets
and you don't need to add any routes. You also won't get any address conflicts.
You will only use 192.168.x.y addresses this way. However, you need to change
the netmask of the LAN interface of all the hosts from 255.255.255.0 to
255.255.0.0, otherwise they will still send packets for a different LAN to
their default gateway instead of to the local tinc node.