Somehow I remember wrongly that it does not work with static key either but in fact it does. So it only doesn't work with tls (without `mode server`).
My server conf: dev tun cipher AES-256-CBC #secret tls.key tls-server dh dh.pem ca ca.crt cert rpi.crt key rpi.key tls-crypt tls.key remote-cert-tls client topology subnet ifconfig 192.168.146.17 255.255.255.252 #mode server #ifconfig-pool 192.168.146.18 192.168.146.18 255.255.255.252 My client conf: dev tun remote 192.168.1.143 nobind cipher AES-256-CBC #secret tls.key tls-client ca ca.crt cert pc.crt key pc.key tls-crypt tls.key remote-cert-tls server topology subnet ifconfig 192.168.146.18 255.255.255.252 #pull If I uncomment `mode server` and `ifconfig-pool` in the server conf and pull in the client conf (and comment `ifconfig` in it), float works as expected, so does it if I uncomment `secret` and comment all lines below it in both confs. Nothing new shows up in the client log either when it works or not, but in the server log, I can see `Peer Connection Initiated with [AF_INET]new_ip:new_port` when it works. But when it doesn't work, I can see `TLS Error: local/remote TLS keys are out of sync: [AF_INET]new_ip:new_port [0]`. (The line keeps repeating itself if the client keeps pinging through the tunnel.) A sample full log: Nov 14 21:09:50 alarm systemd[1]: Starting OpenVPN service for test... Nov 14 21:09:50 alarm openvpn[1167]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode Nov 14 21:09:50 alarm openvpn[1167]: OpenVPN 2.4.8 [git:makepkg/3976acda9bf10b5e+] aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2019 Nov 14 21:09:50 alarm openvpn[1167]: library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10 Nov 14 21:09:50 alarm openvpn[1167]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server> Nov 14 21:09:50 alarm systemd[1]: Started OpenVPN service for test. Nov 14 21:09:50 alarm openvpn[1167]: TUN/TAP device tun0 opened Nov 14 21:09:50 alarm openvpn[1167]: /usr/bin/ip link set dev tun0 up mtu 1500 Nov 14 21:09:50 alarm openvpn[1167]: /usr/bin/ip addr add dev tun0 192.168.146.17/30 broadcast 192.168.146.19 Nov 14 21:09:50 alarm openvpn[1167]: Could not determine IPv4/IPv6 protocol. Using AF_INET Nov 14 21:09:50 alarm openvpn[1167]: UDPv4 link local (bound): [AF_INET][undef]:1194 Nov 14 21:09:50 alarm openvpn[1167]: UDPv4 link remote: [AF_UNSPEC] Nov 14 21:09:57 alarm openvpn[1167]: [pc] Peer Connection Initiated with [AF_INET]192.168.1.2:53553 Nov 14 21:09:58 alarm openvpn[1167]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 14 21:09:58 alarm openvpn[1167]: Initialization Sequence Completed Nov 14 21:10:53 alarm openvpn[1167]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]192.168.1.3:53553 [0] I tested with a client host that is in the same LAN as the server, by manually changing the static IP (added a new one then deleted the old one). On Thu, 14 Nov 2019 at 15:39, Gert Doering <g...@greenie.muc.de> wrote: > > Hi, > > On Thu, Nov 14, 2019 at 11:45:53AM +0800, Tom Yan wrote: > > I happened to notice that "float" doesn't seem to work (even if I > > explicitly set it when the conf already has "remote") when "mode > > server" is not set. Is that an expected behavior? As I see neither > > warning nor anything in the manual about it. > > "mode server is not set" could still be like 15 different ways to run > your setup... > > "Float" is expected to work in plain p2p mode (both sides in mode p2p, > one side using tls-server, the other side tls-client, or even with static > keys). In my t_client test set 9 (udp, mode pdp, static key mode), it > works nicely. Tested every day. > > If it's not working, please provide exact server config and logs that > show a roaming client (= IP address change without a client restart) > not being recognized. > > > > Btw, is it also expected that, `ifconfig` in a client conf will only > > works if the server operates in "mode p2p"? (i.e. a client must be > > pushed an address instead when the server operates in "mode server") > > The server needs to know which address the client has. So if you do > not push, you need to set up an iroute in the ccd/ file to tell the > server "which client has what address". Or do "ifconfig-push" in the > ccd/, which will make it push *and* install the appropriate iroute > (and looks less surprising). > > And this is expected to work, and part of my test set (mostly due to a > very convoluted tap-with-vlan setups where the pool handling is not > flexible enough). > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh Mistress > > Gert Doering - Munich, Germany g...@greenie.muc.de _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
