Many thanks to you all for your miscellaneous contributions ; I must admit it was sometimes quite hard for me to follow you ...
I found out this one:
https://www.snbforums.com/threads/v...-of-internet-connection-merlin-384-4_2.45750/
and indeed by simply putting a "sleep 2" in nat-start, this is solving the issue. For the rest, if you think nat-start is not the right place to issue those iptables command, you are still welcome to tell me what would be best.
Rgds,
GS
In the end, it's whatever works for you. If I see someone struggling w/ something, my first thought is, are they doing it correctly?
Normally, if you want some action performed in conjunction w/ the OpenVPN client (or server for that matter), it only makes sense to use its scripting engine to handle it, either via the openvpn-event script, or directly via directives in Custom Config (that was the debate Martineau and I were having). That's why it exists. Sometimes certain things can *only* be done via the scripting engine because you need information that's only available from OpenVPN when it becomes connected (the tunnel's local IP, the VPN's default gateway, etc.). And if you're building data structures (e.g., port forwarding rules) that are only relevant to the VPN, it's *nicer* to only construct them when needed, and delete them when they're not needed.
What makes your particular issue workable outside the OpenVPN scripting engine is that you make so few references to anything related to OpenVPN anyway. All you need is the tunnel's network interface name. And fortunately, in the case of the firewall, it will let you create rules that reference network interface names that don't even exist at the time the rule is created. But that's not true of, for example, the routing system. The routing system *requires* any routes to actually exist at the time those routes are added. So in that case, use of the OpenVPN scripting engine becomes necessary.
Again, in the end, for this particular case, it happened to not matter whether or not you used the OpenVPN scripting engine. But as I explained in one of my prior posts, had you used the scripting engine, you wouldn't have had to hard code the network interface name (tun11) into the script (nor had timing issues like you did w/ nat-start). That would have been determined by OpenVPN at runtime by using the OpenVPN $dev variable. And now the script would work w/ *any* OpenVPN client that was active, unchanged. Is that a big advantage in this case? Probably not. But as the complexity of your scripts grows, working outside the OpenVPN scripting engine becomes more and more difficult.
