Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ifcfg-ipsec support #759

Open
MikhailKasimov opened this issue Aug 5, 2018 · 2 comments
Open

ifcfg-ipsec support #759

MikhailKasimov opened this issue Aug 5, 2018 · 2 comments

Comments

@MikhailKasimov
Copy link
Contributor

Hello!

Reading
[0] https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-interfaces.html or
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-ipsec-net2net.html

we can meet description of ifcfg-ipsec mechanism, e.g. from [0]:

13.2.2. IPsec Interfaces

The following example shows the ifcfg file for a network-to-network IPsec connection for LAN A. The unique name to identify the connection in this example is ipsec1, so the resulting file is named /etc/sysconfig/network-scripts/ifcfg-ipsec1.

TYPE=IPsec 
ONBOOT=yes 
IKE_METHOD=PSK 
SRCNET=192.168.1.0/24 
DSTNET=192.168.2.0/24 
DST=X.X.X.X

In the example above, X.X.X.X is the publicly routable IP address of the destination IPsec router.

Below is a listing of the configurable parameters for an IPsec interface:

DST=<address>

    where <address> is the IP address of the IPsec destination host or router. This is used for both host-to-host and network-to-network IPsec configurations.
DSTNET=<network>

    where <network> is the network address of the IPsec destination network. This is only used for network-to-network IPsec configurations.
SRC=<address>

    where <address> is the IP address of the IPsec source host or router. This setting is optional and is only used for host-to-host IPsec configurations.
SRCNET=<network>

    where <network> is the network address of the IPsec source network. This is only used for network-to-network IPsec configurations.
TYPE=<interface-type>

    where <interface-type> is IPSEC. Both applications are part of the ipsec-tools package.

If manual key encryption with IPsec is being used, refer to /usr/share/doc/initscripts-<version-number>/sysconfig.txt (replace <version-number> with the version of the initscripts package installed) for configuration parameters.

The racoon IKEv1 key management daemon negotiates and configures a set of parameters for IPSec. It can use preshared keys, RSA signatures, or GSS-API. If racoon is used to automatically manage key encryption, the following options are required:

IKE_METHOD=<encryption-method>

    where <encryption-method> is either PSK, X509, or GSSAPI. If PSK is specified, the IKE_PSK parameter must also be set. If X509 is specified, the IKE_CERTFILE parameter must also be set.
IKE_PSK=<shared-key>

    where <shared-key> is the shared, secret value for the PSK (preshared keys) method.
IKE_CERTFILE=<cert-file>

    where <cert-file> is a valid X.509 certificate file for the host.
IKE_PEER_CERTFILE=<cert-file>

    where <cert-file> is a valid X.509 certificate file for the remote host.
IKE_DNSSEC=<answer>

    where <answer> is yes. The racoon daemon retrieves the remote host's X.509 certificate via DNS. If a IKE_PEER_CERTFILE is specified, do not include this parameter.

For more information about the encryption algorithms available for IPsec, refer to the setkey man page. For more information about racoon, refer to the racoon and racoon.conf man pages.

But can't see the neither similar mechanism for SUSE in wicked, nor some description for ipsec configuring in wicked man pages (ifcfg or ifcfg-tunnel).

Is such mechanism implemented currently in wicked? Or how can it be done/workarounded on user's side for today?

Thanks!

@mtomaschewski
Copy link
Member

We've no plans or feature request (https://fate.suse.com/ or https://features.opensuse.org/) to
implement ipsec via ifcfg (generate config for an ipsec daemon from ifcfg variables, ...).

The ipsecX interfaces are "gone" for a very long time (since kernel 2.6 AFAIR), that is the old/alternative ipsec stacks using them are not supported in favor to the ipsec in the kernel.
With kernel ipsec, the (tunnel/transport) policies are applied as xfrm policy (ip xfrm policy list)
to normal (e.g. ethernet) interfaces by e.g. strongswan, which is FIPS, ... certified, what were
done with wicked under the hood.

Use ipsec daemon's config directly, AFAIK there is also a yast2-vpn module that can be used.
When you want to automate apply/remove of ipsec policies (start/stop tunnels), configure
them in strongswan (auto=ignore to not start automatically) and issue ipsec up $connection
via POST_UP_SCRIPT/PRE_DOWN_SCRIPT.

@MikhailKasimov
Copy link
Contributor Author

Thanks for clarification! IMO, this can be as a chapter/paragraph of wicked's manuals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants