> If you need to be able to reach the subnets behind the far gateway from the > local gateway, the best is to get the routing done properly on the local > gateway (and visa versa). The updown script can do this for simple conns, > using sourceip=, but for more complicated scenarios you might need to do > something yourself. You have some options:
Something I just got done doing with a site-to-site deployment is using VTI endpoints with the documentation at https://libreswan.org/wiki/Route-based_VPN_using_VTI, then left/rightsubnet=0.0.0.0/0 and vti-routing=no. The VTIs have netfilter connmarks, then xfrm knows which connection to use. Be sure you have the vti-routing=no if you are going to use subnets that accept all traffic like this or your default route will become the tunnel, and the tunnel will use itself to try and pass ESP. As I read that doc, I see that it has some caveats but it was last modified eighteen months ago. I am running this on kernel 4.20.6 with no problems. Now you have VTI interfaces that will pass any traffic that ends up on one interface to the other side without headaches and you can run OSPF using something like https://bird.network.cz over those interfaces. You have to tune it, it might propagate more routes than what you want, but it’s completely practical at that point for any established network to get to any other one. If you do this, something to watch out with in OSPF is it’s easy to propagate the interface of one node’s default route interface to the other nodes. What will happen is the same as above, the other nodes will think the fastest way to get to the other node with ESP traffic is through the VPN, so you have to exclude those default networks from getting propagated at the very least. What I haven’t figured out yet is how to do this in some kind of arbitrary mesh. The VTI devices need identifiers and marks that are unique for the connection, but I don’t think Libreswan can generate those for me. If it could, I might be able to say something like mark=%someunique and vti-interface=vti%someunique and everything would automagically just take an unused value and roll with it. It would be helpful when static core nodes had a lot of road warriors are connecting to it. Then Bird could be configured with something like `interface vti*` to just deal with them all in some kind of wildcard nbma setup. Such a config might look like this: > log syslog all; > > # Turn on global debugging of all protocols > #debug protocols all; > > # This pseudo-protocol watches all interface up/down events. > protocol device { > scan time 2; > } > > protocol kernel { > export all; # Default is export none > persist; # Don't remove routes on BIRD shutdown > } > > protocol ospf backbone { > import all; > export all; > area 0.0.0.0 { > interface “eth0” { }; # if I want to announce OSPF on eth0 > interface “vti1" { > type nbma; > strict nonbroadcast yes; > neighbors { > 10.9.255.1 eligible; > }; > }; > }; > } Again, I haven’t figured out the details yet of all the VTI interfaces. It would be pretty amazing if broadcast worked over vti-shared=yes. Brian _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
