Net-to-Net as a TLS-server:

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 starts by selecting the connection type (see above). 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

The connection is 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 does not revolve 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

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 zero, e.g., 192.168.1.0.
- Note: 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 WebGUI.

MTU settings

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

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

Fragmented the unencrypted UDP packets to be sent through the tunnel to the value of 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.
- Note - 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

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.

Cryptographic options

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 chosen cipher will be used for the encryption of your data channel. To be at disposal now:

GCM - Galois/Counter Mode with 256, 196 and 128 Bit
Camellia with 256, 196 und 128 Bit
AES with 256, 196 und 128 Bit
SEED with 128 Bit
Should not be used anymore:
- DES-EDE3 with 196 Bit (Should not be used anymore)
- DESX with 196 Bit (Should not be used anymore)
- DES-EDE with 128 Bit (Should not be used anymore)
- BF with 128 Bit (Should not be used anymore)
- CAST5 with 128 Bit (Should not be used anymore)

All above as "Should not be used anymore" marked ciphers are 64/128 bit block ciphers - 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 through the data canal and will be proved by the function 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 your own investigate should be done. However, it was kept an eye to the order of the lists in the drop-downs, so the stronger algorithms are listed from above and 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. And the red asterisk by each functions indicates that these entries are required.

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 cannot 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 required.

After completing the configuration the client .zip package can be downloaded by the WebGUI 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

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.
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.