Hi, Arne and I discussed PUSH_REQUEST/PUSH_REPLY handling in OpenVPN a lot recently, and found something interesting.
Naively, one would assume that only "--client" (or "--pull") instances would send PULL_REQUEST messages, and only "--server" (or "--mode server") instances would reply to them, and behaviour in other cases is "somewhat unclear" - a non-server would not have information about client IPs to push, for example. After looking at my test rig, it turns out that my --inetd test case actually uses such a combination... - the server side has --inetd --tls-server (because --server is not permitted in --inetd mode), plus a few "push route ..." statements in the config - the client has "--ifconfig" and "--client" in its config - so, it does not rely on server-pushed IP config, but it *does* send PUSH_REQUEST and the server *does* send PUSH_REPLY with the needed routes. Breaking this "interesting combination of features" by permitting replies to PUSH_REQUEST only in "--mode server" configs would not hurt *me* much (we want to get rid of --inetd mode anyway), but it brought up the question "are people using this?". So: if you make use of PUSH_REPLY coming back from a "server" that is not configured with "--server" or "--mode server" (so, technically, the remote end of a p2p instance, not p2mp), please let us know what you do and why :-) Genuinely curious... gert PS: this is the reason why https://patchwork.openvpn.net/patch/1338/ was withdrawn, for now. -- "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
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
