diff options
Diffstat (limited to 'docs/vpn')
| -rw-r--r-- | docs/vpn/dmvpn.rst | 12 | ||||
| -rw-r--r-- | docs/vpn/gre-ipsec.rst | 14 | ||||
| -rw-r--r-- | docs/vpn/l2tp.rst | 16 | ||||
| -rw-r--r-- | docs/vpn/openvpn.rst | 38 | ||||
| -rw-r--r-- | docs/vpn/pptp.rst | 6 | ||||
| -rw-r--r-- | docs/vpn/site2site_ipsec.rst | 12 | ||||
| -rw-r--r-- | docs/vpn/wireguard.rst | 26 | 
7 files changed, 62 insertions, 62 deletions
| diff --git a/docs/vpn/dmvpn.rst b/docs/vpn/dmvpn.rst index aebbda97..9da6dde2 100644 --- a/docs/vpn/dmvpn.rst +++ b/docs/vpn/dmvpn.rst @@ -47,7 +47,7 @@ can be set to "0.0.0.0". If you do set the `remote-ip` directive at any point, t  HUB Configuration  ^^^^^^^^^^^^^^^^^ -.. code-block:: console +.. code-block:: none    interfaces        tunnel <tunN> { @@ -119,7 +119,7 @@ HUB Configuration  HUB Example Configuration: -.. code-block:: console +.. code-block:: none    set interfaces ethernet eth0 address '198.51.100.41/30'    set interfaces ethernet eth1 address '192.168.1.1/24' @@ -171,7 +171,7 @@ SPOKE Configuration  SPOKE1 Configuration: -.. code-block:: console +.. code-block:: none    interfaces        tunnel <tunN> { @@ -248,7 +248,7 @@ SPOKE1 Configuration:  SPOKE1 Example Configuration -.. code-block:: console +.. code-block:: none    set interfaces ethernet eth0 address 'dhcp'    set interfaces ethernet eth1 address '192.168.2.1/24' @@ -294,7 +294,7 @@ SPOKE1 Example Configuration  SPOKE2 Configuration -.. code-block:: console +.. code-block:: none    interfaces        tunnel <tunN> { @@ -371,7 +371,7 @@ SPOKE2 Configuration  SPOKE2 Example Configuration -.. code-block:: console +.. code-block:: none    set interfaces ethernet eth0 address 'dhcp'    set interfaces ethernet eth1 address '192.168.3.1/24' diff --git a/docs/vpn/gre-ipsec.rst b/docs/vpn/gre-ipsec.rst index 3ca36b9f..38849f67 100644 --- a/docs/vpn/gre-ipsec.rst +++ b/docs/vpn/gre-ipsec.rst @@ -40,7 +40,7 @@ and the RIGHT router is 203.0.113.45  On the LEFT: -.. code-block:: console +.. code-block:: none    # GRE tunnel    set interfaces tunnel tun0 encapsulation gre @@ -90,7 +90,7 @@ RIGHT router has a dynamic address on eth0.  On the LEFT: -.. code-block:: console +.. code-block:: none    set interfaces loopback lo address 192.168.99.1/32 @@ -101,7 +101,7 @@ On the LEFT:  On the RIGHT: -.. code-block:: console +.. code-block:: none    set interfaces loopback lo address 192.168.99.2/32 @@ -119,7 +119,7 @@ address, so we'll have to use RSA keys.  First, on both routers run the operational command "generate vpn rsa-key bits  2048". You may choose different length than 2048 of course. -.. code-block:: console +.. code-block:: none    vyos@left# run generate vpn rsa-key bits 2048    Generating rsa-key to /config/ipsec.d/rsa-keys/localhost.key @@ -131,7 +131,7 @@ First, on both routers run the operational command "generate vpn rsa-key bits  Then on the opposite router, add the RSA key to your config. -.. code-block:: console +.. code-block:: none    set vpn rsa-keys rsa-key-name LEFT rsa-key KEYGOESHERE @@ -140,7 +140,7 @@ for the peer on the dynamic side.  On the LEFT (static address): -.. code-block:: console +.. code-block:: none    set vpn rsa-keys rsa-key-name RIGHT rsa-key <PUBLIC KEY FROM THE RIGHT> @@ -165,7 +165,7 @@ On the LEFT (static address):  On the RIGHT (dynamic address): -.. code-block:: console +.. code-block:: none    set vpn rsa-keys rsa-key-name LEFT rsa-key <PUBLIC KEY FROM THE LEFT> diff --git a/docs/vpn/l2tp.rst b/docs/vpn/l2tp.rst index 3d1a5ee7..a91399e2 100644 --- a/docs/vpn/l2tp.rst +++ b/docs/vpn/l2tp.rst @@ -6,7 +6,7 @@ L2TP over IPsec  Example for configuring a simple L2TP over IPsec VPN for remote access (works  with native Windows and Mac VPN clients): -.. code-block:: console +.. code-block:: none    set vpn ipsec ipsec-interfaces interface eth0    set vpn ipsec nat-traversal enable @@ -36,7 +36,7 @@ for NAT-traversal:  Example: -.. code-block:: console +.. code-block:: none    set firewall name OUTSIDE-LOCAL rule 40 action 'accept'    set firewall name OUTSIDE-LOCAL rule 40 destination port '50' @@ -55,7 +55,7 @@ Example:  Also note that if you wish to allow the VPN to be used for external access you  will need to add the appropriate source NAT rules to your configuration. -.. code-block:: console +.. code-block:: none    set nat source rule 110 outbound-interface 'eth0'    set nat source rule 110 source address '192.168.255.0/24' @@ -64,7 +64,7 @@ will need to add the appropriate source NAT rules to your configuration.  To be able to resolve when connected to the VPN, the following DNS rules are  needed as well. -.. code-block:: console +.. code-block:: none    set vpn l2tp remote-access dns-servers server-1 '8.8.8.8'    set vpn l2tp remote-access dns-servers server-2 '8.8.4.4' @@ -75,7 +75,7 @@ needed as well.  Established sessions can be viewed using the **show vpn remote-access**  operational command. -.. code-block:: console +.. code-block:: none    vyos@vyos:~$ show vpn remote-access    Active remote access VPN sessions: @@ -92,7 +92,7 @@ like RADIUS_ (FreeRADIUS_ or Microsoft `Network Policy Server`_, NPS) is used.  VyOS supports either `local` or `radius` user authentication: -.. code-block:: console +.. code-block:: none    set vpn l2tp remote-access authentication mode <local|radius> @@ -100,7 +100,7 @@ In addition one or more RADIUS_ servers can be configured to server for user  authentication. This is done using the `radius server` and `radius server key`  nodes: -.. code-block:: console +.. code-block:: none    set vpn l2tp remote-access authentication radius server 1.1.1.1 key 'foo'    set vpn l2tp remote-access authentication radius server 2.2.2.2 key 'foo' @@ -116,7 +116,7 @@ If you are using e.g. OSPF as IGP always the nearest interface facing the RADIUS  server is used. With VyOS 1.2 you can bind all outgoing RADIUS requests to a  single source IP e.g. the loopback interface. -.. code-block:: console +.. code-block:: none    set vpn l2tp remote-access authentication radius source-address 3.3.3.3 diff --git a/docs/vpn/openvpn.rst b/docs/vpn/openvpn.rst index 764c991c..ce7dcc44 100644 --- a/docs/vpn/openvpn.rst +++ b/docs/vpn/openvpn.rst @@ -67,7 +67,7 @@ in our configuration.  Local Configuration: -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun1 mode site-to-site    set interfaces openvpn vtun1 protocol udp @@ -81,7 +81,7 @@ Local Configuration:  Remote Configuration: -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun1 mode site-to-site    set interfaces openvpn vtun1 protocol udp @@ -99,7 +99,7 @@ weak, but a number of other encryption and hashing algorithms are available:  For Encryption: -.. code-block:: console +.. code-block:: none    vyos@vyos# set interfaces openvpn vtun1 encryption    Possible completions: @@ -113,7 +113,7 @@ For Encryption:  For Hashing: -.. code-block:: console +.. code-block:: none    vyos@vyos# set interfaces openvpn vtun1 hash    Possible completions: @@ -132,13 +132,13 @@ network of 10.1.0.0/16:  Local Configuration: -.. code-block:: console +.. code-block:: none    set protocols static interface-route 10.1.0.0/16 next-hop-interface vtun1  Remote Configuration: -.. code-block:: console +.. code-block:: none    set protocols static interface-route 10.0.0.0/16 next-hop-interface vtun1 @@ -179,7 +179,7 @@ closing on connection resets or daemon reloads.  .. note:: Using **openvpn-option -reneg-sec** can be tricky. This option is used to renegotiate data channel after n seconds. When used at both server and client, the lower value will trigger the renegotiation. If you set it to 0 on one side of the connection (to disable it), the chosen value on the other side will determine when the renegotiation will occur. -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 mode server    set interfaces openvpn vtun10 local-port 1194 @@ -189,7 +189,7 @@ closing on connection resets or daemon reloads.  Then we need to specify the location of the cryptographic materials. Suppose  you keep the files in `/config/auth/openvpn` -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 tls ca-cert-file /config/auth/openvpn/ca.crt    set interfaces openvpn vtun10 tls cert-file /config/auth/openvpn/server.crt @@ -202,7 +202,7 @@ specify the subnet for client tunnel endpoints. Since we want clients to access  a specific network behind out router, we will use a push-route option for  installing that route on clients. -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 server push-route 192.168.0.0/16    set interfaces openvpn vtun10 server subnet 10.23.1.0/24 @@ -214,7 +214,7 @@ need configuration for each client to achieve this.  .. note:: Clients are identified by the CN field of their x.509 certificates,     in this example the CN is ``client0``: -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 server client client0 ip 10.23.1.10    set interfaces openvpn vtun10 server client client0 subnet 10.23.2.0/25 @@ -223,7 +223,7 @@ OpenVPN **will not** automatically create routes in the kernel for client  subnets when they connect and will only use client-subnet association  internally, so we need to create a route to the 10.23.0.0/20 network ourselves: -.. code-block:: console +.. code-block:: none    set protocols static interface-route 10.23.0.0/20 next-hop-interface vtun10 @@ -242,13 +242,13 @@ Authentication is done by using the ``openvpn-auth-ldap.so`` plugin which is  shipped with every VyOS installation. A dedicated configuration file is required.  It is best practise to store it in ``/config`` to survive image updates -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun0 openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"  The required config file may look like: -.. code-block:: console +.. code-block:: none    <LDAP>    # LDAP server URL @@ -275,7 +275,7 @@ Active Directory  Despite the fact that AD is a superset of LDAP -.. code-block:: console +.. code-block:: none    <LDAP>      # LDAP server URL @@ -309,7 +309,7 @@ Despite the fact that AD is a superset of LDAP  If you only want to check if the user account is enabled and can authenticate  (against the primary group) the following snipped is sufficient: -.. code-block:: console +.. code-block:: none    <LDAP>      URL ldap://dc01.example.com @@ -328,7 +328,7 @@ If you only want to check if the user account is enabled and can authenticate  A complete LDAP auth OpenVPN configuration could look like the following example: -.. code-block:: console +.. code-block:: none    vyos@vyos# show interfaces openvpn     openvpn vtun0 { @@ -372,7 +372,7 @@ using their CN attribute in the SSL certificate.  Server  ****** -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 encryption 'aes256'    set interfaces openvpn vtun10 hash 'sha512' @@ -396,7 +396,7 @@ Server  Client  ****** -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 encryption 'aes256'    set interfaces openvpn vtun10 hash 'sha512' @@ -420,7 +420,7 @@ all users can benefit from it.  If you are a hacker or want to try on your own we support passing raw OpenVPN  options to OpenVPN. -.. code-block:: console +.. code-block:: none    set interfaces openvpn vtun10 openvpn-option 'persistent-key' diff --git a/docs/vpn/pptp.rst b/docs/vpn/pptp.rst index 68ded675..72b3feb0 100644 --- a/docs/vpn/pptp.rst +++ b/docs/vpn/pptp.rst @@ -12,7 +12,7 @@ If no gateway-address is set within the configuration, the lowest IP out of the  server example  ^^^^^^^^^^^^^^ -.. code-block:: console +.. code-block:: none    set vpn pptp remote-access authentication local-users username test password 'test'    set vpn pptp remote-access authentication mode 'local' @@ -28,7 +28,7 @@ client example (debian 9)  Install the client software via apt and execute pptpsetup to generate the configuration. -.. code-block:: console +.. code-block:: none    apt-get install pptp-linux    pptpsetup --create TESTTUNNEL --server 10.1.1.120 --username test --password test --encrypt @@ -39,7 +39,7 @@ The command pon TESTUNNEL establishes the PPTP tunnel to the remote system.  All tunnel sessions can be checked via: -.. code-block:: console +.. code-block:: none    run sh pptp-server sessions     ifname | username | calling-sid |      ip      | type | comp | state  |  uptime diff --git a/docs/vpn/site2site_ipsec.rst b/docs/vpn/site2site_ipsec.rst index 6cbb56c9..bdafd6ce 100644 --- a/docs/vpn/site2site_ipsec.rst +++ b/docs/vpn/site2site_ipsec.rst @@ -116,7 +116,7 @@ Example:  * right subnet: `10.0.0.0/24` site2,remote office side  * right local_ip: `203.0.113.2` # remote office side WAN IP -.. code-block:: console +.. code-block:: none    # server config    set vpn ipsec esp-group office-srv-esp compression 'disable' @@ -166,7 +166,7 @@ Example:  Show status of new setup: -.. code-block:: console +.. code-block:: none    vyos@srv-gw0:~$ show vpn ike sa    Peer ID / IP                            Local ID / IP @@ -186,7 +186,7 @@ Show status of new setup:  If there is SNAT rules on eth1, need to add exclude rule -.. code-block:: console +.. code-block:: none    # server side    set nat source rule 10 destination address '10.0.0.0/24' @@ -203,7 +203,7 @@ If there is SNAT rules on eth1, need to add exclude rule  To allow traffic to pass through to clients, you need to add the following  rules. (if you used the default configuration at the top of this page) -.. code-block:: console +.. code-block:: none    # server side    set firewall name OUTSIDE-LOCAL rule 32 action 'accept' @@ -230,7 +230,7 @@ Imagine the following topology  **left** -.. code-block:: console +.. code-block:: none    set interfaces vti vti10 address '10.0.0.2/31' @@ -264,7 +264,7 @@ Imagine the following topology  **right** -.. code-block:: console +.. code-block:: none    set interfaces vti vti10 address '10.0.0.3/31' diff --git a/docs/vpn/wireguard.rst b/docs/vpn/wireguard.rst index 1fc2e11f..82c38f69 100644 --- a/docs/vpn/wireguard.rst +++ b/docs/vpn/wireguard.rst @@ -21,7 +21,7 @@ within VyOS.  It will be used per default on any configured wireguard interface, even if  multiple interfaces are being configured. -.. code-block:: console +.. code-block:: none    wg01:~$ configure    wg01# run generate wireguard keypair @@ -29,7 +29,7 @@ multiple interfaces are being configured.  The public key is being shared with your peer(s), your peer will encrypt all  traffic to your system using this public key. -.. code-block:: console +.. code-block:: none    wg01# run show wireguard pubkey    u41jO3OF73Gq1WARMMFG7tOfk7+r8o8AzPxJ1FZRhzk= @@ -45,7 +45,7 @@ their own keypairs.  The commands below will generate 2 keypairs, which are not related   to each other. -.. code-block:: console +.. code-block:: none    wg01:~$ configure    wg01# run generate wireguard named-keypairs KP01 @@ -69,7 +69,7 @@ below is always the public key from your peer, not your local one.  **local side** -.. code-block:: console +.. code-block:: none    set interfaces wireguard wg01 address '10.1.0.1/24'    set interfaces wireguard wg01 description 'VPN-to-wg02' @@ -89,7 +89,7 @@ traffic.  To use a named key on an interface, the option private-key needs to be set. -.. code-block:: console +.. code-block:: none    set interfaces wireguard wg01 private-key KP01    set interfaces wireguard wg02 private-key KP02 @@ -100,7 +100,7 @@ which needs to be shared with the peer.  **remote side** -.. code-block:: console +.. code-block:: none    set interfaces wireguard wg01 address '10.2.0.1/24'    set interfaces wireguard wg01 description 'VPN-to-wg01' @@ -113,7 +113,7 @@ which needs to be shared with the peer.  Assure that your firewall rules allow the traffic, in which case you have a  working VPN using wireguard. -.. code-block:: console +.. code-block:: none    wg01# ping 10.2.0.1    PING 10.2.0.1 (10.2.0.1) 56(84) bytes of data. @@ -128,7 +128,7 @@ working VPN using wireguard.  An additional layer of symmetric-key crypto can be used on top of the  asymmetric crypto, which is optional. -.. code-block:: console +.. code-block:: none    wg01# run generate wireguard preshared-key    rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc= @@ -137,7 +137,7 @@ Copy the key, as it is not stored on the local file system. Make sure you  distribute that key in a safe manner, it's a symmetric key, so only you and  your peer should have knowledge of its content. -.. code-block:: console +.. code-block:: none    wg01# set interfaces wireguard wg01 peer to-wg02 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc='    wg02# set interfaces wireguard wg01 peer to-wg01 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc=' @@ -147,7 +147,7 @@ Operational commands  **Show interface status** -.. code-block:: console +.. code-block:: none    vyos@wg01# run show interfaces wireguard wg01 @@ -164,14 +164,14 @@ Operational commands  **Show public key of the default key** -.. code-block:: console +.. code-block:: none    vyos@wg01# run show wireguard keypair pubkey default    FAXCPb6EbTlSH5200J5zTopt9AYXneBthAySPBLbZwM=  **Show public key of a named key** -.. code-block:: console +.. code-block:: none    vyos@wg01# run show wireguard keypair pubkey KP01    HUtsu198toEnm1poGoRTyqkUKfKUdyh54f45dtcahDM= @@ -179,7 +179,7 @@ Operational commands  **Delete wireguard keypairs** -.. code-block:: console +.. code-block:: none    vyos@wg01# wireguard keypair default | 
