Site to Site Tunnel Routing issues? about pistrong

[gitbls]

Kris, just to confirm: You're saying that sitting on, for instance, 192.168.0.10 you're unable to ping hosts on the 192.168.1.x network (and vice versa). Is that correct? If that's the case, I'm pretty sure (but my notes are lacking on this) that the .x systems (besides the VPN server) need to know a route to the .other.x network.

What is the result if you add a route to one of these systems that is along the lines of "192.168.other.0/24 goes to the VPN server on my network"?

[gitbls]

OK, had a minute to test and validate. Without a route on an "other node" on one side of the network, that "other node" was unable to access hosts across the VPN. I added the equivalent (in your network terms) of 'route add -net 192.168.1.0/24 gw 192.168.0.10' (for the .0.0/24 network). There are many ways to make this permanent, depending on how your network is configured and what the various host OS are. LMK if you have any further questions/issues on this.

[kriszabala]

Thanks for the super quick replies on this. Sorry, I may have been confusing with the use of terminology. Here's a quick and dirty diagram.

From either of the RPi's I can reach any host on the other end of the tunnel. I cannot, however, reach Host 1 from Host 0 or vice versa. I guess I was under the assumption that the site-to-site tunnel would accomplish this. Apologies in advance, my networking knowledge is very limited.

[gitbls]

Yes, my previously mentioned route statement would be done as thus for your network (assumes Linux):

Host 0: route add -net 192.168.1.0/24 gw 192.168.0.10
Host 1: route add -net 192.168.0.0/24 gw 192.168.1.10

[kriszabala]

Ah, got it. The hosts are standalone hardware on which I can't configure routes on. The use case is, one host sends a broadcast and the other will reply. I was thinking the RPi would handle this, filtering for any traffic destined for the subnet of the other end of the tunnel and then forwarding it through the tunnel.

[gitbls]

How do these devices get an IP address, and what operating environment is running on them? What are you using for a DHCP server on each of these subnets?

[kriszabala]

Each of the routers are the DHCP servers for each side. I have two use cases for this.

In one use case, one is a standalone hardware device (laser projector fixture w/ unknown OS, embedded device) and communicates with software running on windows.

In another use case, again one side is another standalone hardware device and communicates with multiplatform software so it could be windows, linux, android, etc.

So I guess I'm trying to accomplish this in the most general way so that different scenarios will work.

[gitbls]

Some DHCP servers can push routes to the DHCP clients when an address is assigned. Worth checking to see if yours does, and if so, will your devices honor it.

My only other suggestion would be to use another level of indirection, and have the hardware devices connected directly to a Pi that can forward all traffic appropriately out through a 2nd adapter to the VPN server. You might be able to do this with a dedicated adapter on the VPN server, but might be easier to try and debug starting out with another Pi if that's possible. Sorry I don't have a definitive solution for you.

[kriszabala]

Thanks for the ideas! I think for my use case, it will be better for me to upgrade to routers with VPN tunnel functionality. I wasn't sure if the pi's would provide enough bandwidth anyways.

[gitbls]

It dawned on me when you closed this...You can easily run the RPis as routers by adding a second ethernet (USB dongle) to each of the Pis. Then, your devices will sit on the Pi's private network and the other network will be on the internet, running the VPN.

In fact, makeTunnel generates the iptables for each end needed for this scenario, in the file Tunnel-tunnelname-otherhost-firewall.iptables

I've done a moderate amount of testing with this, so can't guarantee that it's 100% complete, but if you were to go down this path, I'd be happy to work with you on it as needed.

[kriszabala]

I actually just got this to work. Here's what I did. I added a static route on each router and each pi.
[email protected] adds route to 192.168.1.0/24 with the [email protected] as the gateway.
On the [email protected], route add -host 192.168.1.10 dev eth0 and then route add -net 192.168.1.0/24 gw 192.168.1.10
Then repeated for symmetry on the other side's router and pi.

So basically the traffic intended for the other side gets routed to the pi gateway, which in turn routes it to pi on the other side.

Seems to be working, I can now reach Host1 from Host0 with zero-config on either one. See any issues with this?

[gitbls]

Kris, Doh! I had completely forgotten about that option. Thanks for the reminder. Adding it to the doc, because I don't see any issues with it. Well, just one consideration: packets that hit the router and get re-routed to the VPN hit the router twice, don't they? You've probably cut down the effect of that a lot by adding the route to each pi (I assume you mean other Pis on each of the LANs?).

Did you run into any other issues getting your tunnel set up?

[gitbls]

Closing. Hope all is well.