Two things are worth separating here, because they are easy to conflate and one of them costs a lot of time.
"unsafe legacy renegotiation disabled" comes from the client's TLS library rather than from OpenVPN's own option handling. It means the server side never offered the secure renegotiation extension (RFC 5746), which points at a very old TLS stack on the Vigor. Because it is refused at the TLS layer, nothing you add to the .ovpn profile will negotiate around it. In particular, tls-cert-profile legacy is the option most people try next and it will not help, since that only relaxes certificate and key strength such as small RSA keys and SHA1 signatures, not the renegotiation extension. The app-level Security Level setting Joseph pointed you at is the knob that covers this class of problem, so if you have already tried it and the error is unchanged, worth saying so explicitly, because that narrows things considerably.
Before changing anything else, three details would help: is the Vigor's OpenVPN service set to UDP or TCP, which cipher and hash are selected in its OpenVPN general setup, and what do the first twenty or so lines of the Connect log show up to the failure? That distinguishes a handshake that dies on renegotiation from one that never gets that far, which are different problems.
If the security-level change does not get you connected, the practical options are on the server side rather than the client side, since the 2832n is end of life and its TLS stack will not be updated. One is to leave the Vigor as a plain router and run the OpenVPN server on any always-on device on the LAN, forwarding the port to it: you then have a current OpenSSL on the server side and the client can stay at its defaults, which is a better outcome than permanently lowering the client. The other, if what you actually need is remote access rather than OpenVPN specifically, is that the Vigor's L2TP over IPsec is a separate implementation from its OpenVPN build and iOS has a native L2TP/IPsec client, so that path is not affected by the OpenSSL age at all. Use a strong pre-shared key and per-user credentials if you go that way.
One caveat on Security Level: it is an app setting rather than a per-profile one, so leaving it at Insecure affects every profile in the app and not just this connection. Reasonable as a diagnostic step, less so as the permanent answer.
