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.
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.
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 |
| Note! |
|---|
| The management interface in his basic configuration is only available for localhost and is responsible for the status display in the webinterface. |
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.
| 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.
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.
- With IPFire-2.15 a new OpenSSL library was implemented, thus some new ciphers named CAMELLIA and SEED where implemented.
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.
| 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.
| 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. |
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.
In here the TLS-client specific certificate can be defined. Therefor, some typical X509 data needs to be filled in the appropriate fields.
| 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.
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.
Older Revisions • May 5 at 8:40 pm • Michael Tremer