Net-to-Net as a TLS-server:

Back to OpenVPN main page

Next configuration section

  • "Net-to-Net Virtual Private Network"

This option should be selected if this IPFire also assumes the TLS-server function. In this mode, after configuring a client .zip package will be created, in which are all relevant data such as the configuration file and all certificates to construct the tunnel. After selecting the menu item, the configuration area will be opened by clicking the "Add" button.

Configure the connection

The configuration of the network-to-network connection of the TLS server takes place over the second point of the selection of "connection type" (see above). By clicking the "Add" button, the window for connection and authentication will be opened.

Connection

In here, all connection related data like the OpenVPN subnet, the local and remote subnet but also the protocol and port will be endorsed.

  • Name: In this line the name of the connection is given, this is arbitrary, but should be selected sensible so that the connection can clearly be assigned. This name is also used for the configuration file in/var/ipfire/ovpn/n2nconf/ and must not contain spaces or special characters.

  • Act as: Here, the connection can be configured as a OpenVPN server or client. Since the network-to-network connection is working properly in a, for both gateways equal peer-to-peer mode, so in this case the TLS-server or the TLS-client will be defined. It do not revolves around the OpenVPN server mode (as in Roadwarrior), but this option defines only the procedure for authentication.

  • Remote Host/IP: In this field the FQDN, a static IP or a Dynamic DNS for the destination device should be entered.

  • Local Subnet: Defines the own subnet behind the IPFire gateway (default the green zone), so that the counterpart station can access this network. Provided that the route should lead to a different network (eg blue or orange) then this route must be entered here. If multiple subnets are to be reached, they must be edited manually via the console in the configuration file, this file is the folder under/var/ipfire/ovpn/n2nconf, these entries must always be made for the remote site.

  • Remote subnet: In here the subnet of the remote station will be entered which should be connected to the local subnet and the local gateway. These informations, if they are not already known, needs to be inquired from the remote site.

  • OpenVPN subnet (e.g. 10.0.10.0/255.255.255.0): In here the IP of the OpenVPN tunnel (transfer net) will be defined. The tun device needs this input to create the virtual network. As the example shows it can be advantageous to choose an IP that differs significantly from the others (e.g. 192.168.x.x), thus the routing tables, or network address overlap can better be overlooked and prevented.

Note!
• In order to write an entire subnet out the last digit of the IP should be a 192.168.1.0 .
• It may be none of the subnets overlap with one another or be the same.

  • Protocol: As protocol UDP and TCP is available, whereby OpenVPN are optimized for UDP and provides faster data throughput. For TCP, the server waits indefinitely for a connection while the client trying to (about every 5 seconds) to produce such ones. When separated SPI firewalls work in front of the server or client, TCP can help against connection abortions, even with the use of an upstream proxy TCP will be used.

  • Destination port: The destination port is the port at the remote site, it should regarded to ensure that this port is not used by other services.

Note!
There must be used a different port as for the Road Warrior Connection
  • Management Port: The management port listens by default on the connection port, this field can be used to change the default setting.
Note!
The management interface in his basic configuration is only available for localhost and is responsible for the status display in the webinterface.

MTU settings

The relevant data for managing the package settings can be adjusted in here.

  • The MTU Size: specifies the maximum size of packets to be sent to (default UDP 1500, TCP 1400), but it can be influenced by mssfix and fragment (only with UDP). It should be ensured that the additional headers which adds OpenVPN to the packages makes no fragmentation of packets necessary.

  • fragment [max]: Fragmented the unencrypted UDP packets to be sent through the tunnel to the value of [max] the maximum byte size of the package. The UDP header will not be regarded, the default value is 1300 byte.

Note!
• mssfix and fragment are only used with UDP as protocol.
• To adapt mssfix and fragment to a specific infrastructure, a MTU-test may be helpful. How an MTU-test can be done, can be found in here.

  • mssfix [max] - Used for TCP packets that are sent via a UDP tunnel. Over [max] the TCP connection will be delivered, the maximum packet size in bytes. Unless no different value is edited, mssfix takes the value of fragment.

  • LZO-Compression: The LZO-compression compresses the data passing through the tunnel. , However the network traffic will be reduced, but it increases the CPU utilization. A speed table with turned on and off LZO-compression and also with different protocols and encryptions can be found in here .

  • Path MTU Discovery - PMTUD is implemented since Core 65 and is used for automatic detection of the optimal MTU value of the compound. PMTUD substitutes mssfix, fragment and the MTU value.

There are 4 variants of these directives.

  • 1) Forced - (mtu-disc yes) There are always set the DF (Do not Fragment) flag.
  • 2) Optionally - (mtu-disc maybe) Use per-route hints.
  • 3) Never - (mtu-disc no) Never send DF (Don't Fragment) frames.
Note!
1) Since MTU discovery using ICMP packets (ICMP type 3, subtype 4) and the DF bit, it can comes in rare cases to problems on the connection if ICMP packets are dropped on the way.
2) The client should dispose over the necessary system call so PMTUD can be used, these include primarily Linux clients. Tested negative until now was Windows 7 and Mac OS X 10.6., which unfortunately does not have this feature.

In both above explained cases it should be re-used fragment and mssfix or a suitable mtu setting. An insightful report on the pros and cons of PMTUD can be found here.

Cryptographic options

With Core 79, two more dropdown menus has been arrived. Now it is possible to configure also the cipher algorithm for Net-to-net connection (like for the Roadwarrior). Likewise it is now also possible to configure the hash algorithm which is responsible for the data integrity of the data channel.

  • Encryption: - The choosen cipher will be used for the encryption of your data channel.


- With IPFire-2.15 a new OpenSSL library was implemented, thus some new ciphers named CAMELLIA and SEED where implemented.

  • With IPFire-2.19-Core120 a new OpenSSL library but also an update to OpenVPN-2.4.x has been introduced which entails a new block cipher called Galoise/Counter Mode .

To be at disposal now:

All above as "Should not be used anymore" marked ciphers are so called 64 bit block ciphers whereby meanwhile know practical attacks are possible. You can find a workaround on OpenVPNs wiki if these ciphers are used but difficult to change. Nevertheless they should be changed as soon as possible.

  • Hash algorithm - The hash algorithm defined here (--auth directive) is used to secure the integrity of the IP packages which belongs throught the data canal and will be prooved by the funtion of a so-called Hash Message Authentication Code (HMAC). This authentication serves the integrity of the data and prevents a manipulation of the data. The following algorithms are available.

  • Whirlpool (512 Bit)

  • SHA2 (512 Bit)
  • SHA2 (384 Bit)
  • SHA2 (256 Bit)
  • SHA1 (160 Bit) old default value.
Note!
If a AES-GCM cipher is in usage, the HMAC menu in the web user interface will be disabled since GCM uses its own message authentication code called GMAC

It would be go beyond the scope to explain the pros and cons of all available algorithms, therefor own investigate should be done. However, it was seen to it the stronger algorithms are listed from above down to the weaker algorithms in the menu. However, it was kept an eye to the order of the lists in the dropdowns, so the stronger algorithms are listed from above down to the weaker algorithms in the menu.

Remark

  • Remark: The remark helps to allocate the connection and is freely selectable.

Note!
• There is no need to set separated IP-Forwarding or special IPTable rules cause IPFire makes this automatically.
• The red asterisk by each functions indicates that these entries are optional.

Creation of the Keys and Certificates

The creation of the CA the cert and the two keys (server and Diffie-Hellman) takes place on the lower section of the configuration page, the "authentication". It will resumed all required certificates and keys in a PKCS#12 file together with the configuration file and all files will be stored in downloadable .zip package. The individual options are pretty self-explanatory but nevertheless a brief explanation for them follows too.

Authentication

In here the TLS-client specific certificate can be defined. Therefor, some typical X509 data needs to be filled in the appropriate fields.

  • User´s full name or system hostname: - The name should include an allocation of the connection partner. Hereby there is no need to fill up a domain name or FQDN, but it can´t be used spaces or special characters.
  • Users e-mail address: - The e-mail address of the connection partner should be filled up here.
  • User´s department: - Is used to assign a specific area eg. business department.
  • Organization Name: - Where there are several companies or organizations which stands in connection via OpenVPN, can be set a label in here.
  • City: The indication of the location can also help to keep order.
  • State or Province: - The state or province should be used with shorthand symbols.
  • Country: - Serves to further differentiation of localities.
  • Valid till (days): - Defines, how long (in days) this certificate should be valid.
Note!
The red asterisk by each functions indicates that these entries are optional.

After completing the configuration the client .zip package can be downloaded by the webinterface in the area of ​​"client status and control" over the small disk icon --> and can be transmitted and imported to the appropriate client gateway.

Important: 1) Since the certificates and the keys are not stored with a password (difference between the Roadwarrior and N2N connection), it is strongly recommended before the export to the client gateway to ensure a suitable and safe transport for this .zip file, for example with an encrypted email using GnuPG. 2) The remaining .zip package on the intermediary computer should be safely deleted or detained after the import to IPFire.

It could be also imported an already existing .zip package in this case, the certificates and keys needs to be saved together in a PKCS#12 format (p.12) and the configuration file in a .conf format both files are to be laced as a .zip package.

Next configuration section

Back to OpenVPN main page

Edit Page ‐ Yes, you can edit!
Last changed by Jon, November 30, 2019 View Older Revisions