.B cmd ip_address port_numberCommas (',') may be used to separate multiple args in.B cmd.Before the command line is passed to the shell, all commaswill be converted to spaces.If you are running in a dynamic IP address environment wherethe IP addresses of either peer could change without notice,you can use this script, for example, to edit the.I /etc/hostsfile with the current address of the peer.  The script willbe run every time the remote peer changes its IP address.Similarly if.I ourIP address changes due to DHCP, we should configureour IP address change script (see man page for.BR dhcpcd (8)) to deliver a.B SIGHUPor.B SIGUSR1signal to OpenVPN.  OpenVPN will thenreestablish a connection with its most recently authenticatedpeer on its new IP address..TP.B --port portUDP port number for both local and remote..TP.B --lport portUDP port number for local (default=5000)..TP.B --rport portUDP port number for remote (default=5000)..TP.B --nobindDo not bind to local address and port.  The IP stack will allocatea dynamic port for returning packets.  Since the value of the dynamic portcould not be known in advance by a peer, this option is only suitable forpeers which will be initiating connections by using the.B --remoteoption..TP.B --dev tunX | tapX | nullTUN/TAP virtual network device (.B Xcan be omitted for dynamic device inLinux 2.4.7+).  See examples section belowfor an example on setting up a TUN device..TP.B --dev-type device-typeWhich device type are we using?.B device-typeshould be.B tunor.B tap.Use this option only if the tun/tap device used with.B --devdoes not begin with.B tunor.B tap..TP.B --tun-ipv6Build a tun link capable of forwarding IPv6 traffic.Should be used in conjunction with.B --dev tunor.B --dev tunX.A warning will be displayedif no specific IPv6 tun support for your OS has been compiled into OpenVPN..TP.B --dev-node nodeExplicitly set the device node rather than using/dev/net/tun, /dev/tun, /dev/tap, etc.  If OpenVPNcannot figure out whether.B nodeis a tun or tap device based on the name, you shouldalso specify.B --dev-type tunor.B --dev-type tap..TP.B --ifconfig l rConfigure the TUN device to use IP address.B las a local endpoint and.B ras a remote endpoint..B l&.B rshould be swapped on the other peer..B l&.B rmust be privateaddresses outside of the subnets used by either peer.This option implies.B --udp-mtu 1300if neither.B --udp-mtuor.B --tun-mtuis explicitly specified.This option willconfigure the tunnel endpoints using the.BR ifconfig (8)command, eliminating the need to have an.B --upscript.  However, you will still need an.B --upscript if you will be adding routesto the tunnel.The.B --ifconfigoption can be used in conjunction with an.B --upscript in which case the local and remoteendpoints will be passed as parameters tothe script.In addition, the.B --ifconfigoption will set the UDP MTU to 1300and derive the tunnel MTU automatically.  You canoverride the UDP MTU value of 1300 by usingthe.B --udp-mtuoption to explicitly specify a different value.One of the nice features of the .B --ifconfigoption is that it knows how to run the.BR ifconfig (8)tool on each of the operating systemswhich OpenVPN supports, allowing youto specify the option consistentlyacross platforms, while OpenVPN dealswith formatting the appropriate.BR ifconfig (8)command for your platform..TP.B --udp-mtu nTake the UDP device MTU to be n and derive the TUN MTUfrom it (default=1300 when the.B --ifconfigoption is used).The MTU (Maximum Transmission Units) isthe maximum datagram size in bytes that can be sent unfragmentedover a particular network path.  OpenVPN requires that packetson the control or data channels be sent unfragmented.Typically, the UDP MTU should be set to a value between 1300 and 1500.The optimal size for UDP MTU is the largestMTU that can be handled by every router on the link path.The UDP MTU value should be equal on both peers.OpenVPNadds a small amount of overhead to each tunnel packet beforeit is forwarded from the TUN device over the secure UDP channel.This overhead consists of data fields such as the HMAC signature,packet ID, encryption block padding, etc.  Because of this overhead,the TUN device MTU should be slightly smaller than the UDP deviceMTU to make room for the extra bytes which OpenVPN adds to everydata channel packet.  OpenVPN allows you to explicitly specify eitherthe TUN MTU or the UDP MTU (but not both).  OpenVPN will thencompute the value you didn't specify based on the value you did.OpenVPN will compute exactly how much overhead it will need to addto each packet, based on the other options you specify.  If youspecify an.B --upscript, OpenVPN will pass the TUN MTU and UDP MTU values on the command lineto the script..TP.B --tun-mtu nTake the TUN device MTU to be.B nand derive the UDP MTUfrom it (default=1300).See.B --udp-mtuabove more more information on MTU.Using this option is discouraged because it defeatsOpenVPN's ability to automatically set the TUN MTU basedon the UDP MTU.Using the.B --ifconfigoption is the recommended method of configuring theTUN device MTU automatically..TP.B --shaper nLimit bandwidth of outgoing tunnel data to.B nbytes per second on the UDP port.If you want to limit the bandwidthin both directions, use this option on both peers.OpenVPN uses the following algorithm to implementtraffic shaping: Given a shaper rate of.I nbytes per second, after a datagram write of.I bbytes is queued on the UDP port, wait a minimum of.I (b / n)seconds before queuing the next write.It should be noted that OpenVPN supports multipletunnels between the same two peers, allowing youto construct full-speed and reduced bandwidth tunnelsat the same time,routing low-priority data such as off-site backupsover the reduced bandwidth tunnel, and other dataover the full-speed tunnel.Also note that for low bandwidth tunnels(under 1000 bytes per second), you should probablyuse lower MTU values as well (see above), otherwisethe packet latency will grow so large as to triggertimeouts in the TLS layer and TCP connections runningover the tunnel.OpenVPN allows.B nto be between 100 bytes/sec and 100 Mbytes/sec..TP.B --inactive nCauses OpenVPN to exit after.B nseconds of inactivity on the tun/tap device.  The time lengthof inactivity is measured since the last incoming tunnel packet..TP.B --ping nPing remote over the UDP control channelif no packets have been sent for at least.B nseconds (specify.B --pingon both peers to cause ping packets to be sent in both directions).When used in one of OpenVPN's secure modes (where.B --secret, --tls-server,or.B --tls-clientis specified), the ping packetwill be cryptographically secure.This option has two intended uses:(1) Compatibilitywith stateful firewalls.  The periodic ping will ensure thata stateful firewall rule which allows OpenVPN UDP packets topass will not time out.(2) To provide a basis for the remote to test the existenceof its peer using the.B --ping-exitoption..TP.B --ping-exit nCauses OpenVPN to exit after.B nseconds pass without reception of a pingor other packet from remote.This option can be combined with.B --inactive, --ping,and.B --ping-exitto create a two-tiered inactivity disconnect.For example,.B openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60when used on both peers will cause OpenVPN to exit within 60seconds if its peer disconnects, but will exit after onehour if no actual tunnel data is exchanged..TP.B --ping-restart nSimilar to.B --ping-exit,but trigger a.B SIGUSR1restart after.B nseconds pass without reception of a pingor other packet from remote.See the signals section below for more informationon.B SIGUSR1.Note that the behavior of.B SIGUSR1can be modified by the.B --persist-tun, --persist-key, --persist-local-ip,and.B --persist-remote-ipoptions.Also note that.B --ping-exitand.B --ping-restartare mutually exclusive and cannot be used together..TP.B --ping-timer-remRun the.B --ping-exit/.B --ping-restarttimer only if we have a remote address.  Use this option if you arestarting the daemon in listen mode (i.e. without an explicit.B --remotepeer), and you don't want to start clocking timeouts until a remotepeer connects..TP.B --persist-tunDon't close and reopen tun/tap device or run up/down scriptsacross.B SIGUSR1or.B --ping-restartrestarts..B SIGUSR1is a restart signal similar to.B SIGHUP,but which offers finer-grained control overreset options..TP.B --persist-keyDon't re-read key files across.B SIGUSR1or.B --ping-restart.This option can be combined with.B --user nobodyto allow restarts triggered by the.B SIGUSR1signal.Normally if you drop root privileges in OpenVPN,the daemon cannot be restarted since it will now be unable to re-read protectedkey files.This option solves the problem by persisting keys across.B SIGUSR1resets, so they don't need to be re-read..TP.B --persist-local-ipPreserve initially resolved local IP address and port numberacross.B SIGUSR1or.B --ping-restartrestarts..TP.B --persist-remote-ipPreserve most recently authenticated remote IP address and port numberacross.B SIGUSR1or.B --ping-restartrestarts..TP.B --mlockDisable paging by calling the POSIX mlockall function.Requires that OpenVPN be initially run as root (thoughOpenVPN can subsequently downgrade its UID using the.B --useroption).Using this option ensures that key material and tunneldata are never written to disk due to virtualmemory paging operations which occur under mostmodern operating systems.  It ensures that even if anattacker was able to crack the box running OpenVPN, hewould not be able to scan the system swap file torecover previously usedephemeral keys, which are used for a period of timegoverned by the.B --renegoptions (see below), then are discarded.The downsideof using.B --mlockis that it will reduce the amount of physicalmemory available to other applications..TP.B --up cmdShell command to run after successful tun/tap device open(pre.B --userUID change).Execute as:.B cmd tun_tap_dev tun_mtu udp_mtu ifconfig_local_ip ifconfig_remote_ipTypically,.B cmd