On Mon, 12 Jun 2017 17:24:35 +0200 Gert Doering <g...@greenie.muc.de> wrote:
> > Well, in fact it does not matter very much. The slave is sending the > > packet, but the response is sent back to the master. > > "some bits of noise, but nothing bad" > > So I take it's mostly working now? Like a charm :) > Ugh. NAT involved. Any way to do this without (like, doing the > tunnel over IPv6)? Nope. The problem is, whether it's ipv4 or ipv6, that the active tunnel must bind to the virtual ip. And as only one OpenVPN server can have the virtual ip, you will have to NAT. Using NAT I can bind both servers to an internal 198.51.0.1. The daemon will then run on the master and the slave without problems. Outgoing packets: as the slave normally doesn't transmit and receive data, I can SNAT the 198.51.0.1 to the virtual IP. On the slave the udp packets are sent out anyway to the internet using the source address of the virtual ip, although the slave does not own it. Incoming packets: as soon as the slave becomes master, the udp packets sent to the virtual ip wil be received and decrypted. And as the routing tables on the slave and the master point to the tun device itself, the routing table needs not to be changed during master/slave switching. This config doesn't need to switch on and off OpenVPN daemons and is particularly interesting if you have two fail-over configs talking to each other. IMPORTANT NOTE: if only one of the sides has fail-over config, then a simple --float on the server will do the job, even tcp can be used then. > > I can also go for a NOTRACK target and put a rule above the > > ESTABLISHED rule. But I think I'll go for an extra SNAT rule. Once > > the connection is established, it won't be hit again. > > That should be fine, then... Finally I think I'll go for the NOTRACK option. That's safe. No bothering with connection track tables. > > But maybe Gert or anyone else has a better OpenVPN-ish solution to > > this :) > > I'm afraid that *this* is outside OpenVPN's domain - you can play a > bit with --float, but that will break if port changes in a surprising > way, so both sides have the "wrong" remote port information all of a > sudden. Well, that was exactly what I happened to discover. If the stack thinks the src port is still in use, it will choose another src port. This works of course using --float, but during master/slave switching the conntrack tables are different which results in an interrupted VPN connection. Thnx for your support! R. -- richard lucassen http://contact.xaq.nl/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
