Re: [strongSwan] xAuth request for VICI
I have not tested the configuration in swanctl.conf yet, but my goal is to move away from configuration files so I can dynamically add/remove connections remotely. I will add it in to see if perhaps my dictionary has a syntax issue. The output of `ipsec statusall`: test: %any...%any IKEv1/2 test: local: [x.amazonaws.com] uses public key authentication test:cert: "C=US, O=x, CN=xx.amazonaws.com" test: remote: uses XAuth authentication: any test: remote: [C=US, O=xx, CN=test] uses public key authentication test: child: 31.13.69.80/32 === dynamic TUNNEL I have loaded in the serverCert/key and caCert/key using the vici commands as well. All returned a successfull completion message and are listed in `ipsec listcerts`. Additionally I loaded in a value for the xAuth connection. Best, Sam On Wed, Feb 25, 2015 at 11:49 AM, Martin Willi wrote: > Hi, > > > I have attempted to create the same configuration using a call to the > VICI > > with this dictionary: > > Have you tried to configure that in swanctl.conf to avoid any problems > with your "dictionary"? Here such an XAuth configuration works fine when > defined in swanctl.conf. > > > This keeps returning this error: `1 config found, none that allow > > xAuthInitRSA using MainMode` > > Not sure what exactly goes on. Can you confirm the the connection has > been successfully loaded. What's the output of "ipsec statusall" (or > "swanctl --list-conns")? > > > 'vips' : ['10.0.0.5'], > > This is probably not what you want, "vips" requests a virtual IP. Use > the "pools" keyword and the appropriate "pools" section to define > virtual IP pools, refer to swanctl.conf(5) for details. This is probably > not the root cause of your issue, though. > > Regards > Martin > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] xAuth request for VICI
Hi, > I have attempted to create the same configuration using a call to the VICI > with this dictionary: Have you tried to configure that in swanctl.conf to avoid any problems with your "dictionary"? Here such an XAuth configuration works fine when defined in swanctl.conf. > This keeps returning this error: `1 config found, none that allow > xAuthInitRSA using MainMode` Not sure what exactly goes on. Can you confirm the the connection has been successfully loaded. What's the output of "ipsec statusall" (or "swanctl --list-conns")? > 'vips' : ['10.0.0.5'], This is probably not what you want, "vips" requests a virtual IP. Use the "pools" keyword and the appropriate "pools" section to define virtual IP pools, refer to swanctl.conf(5) for details. This is probably not the root cause of your issue, though. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] xAuth request for VICI
Hello,
I am trying to translate an old ipsec.conf configuration to using the VICI
interface. My old ipsec.conf configuration that is working completely
normally is this:
config setup
conn %default
keyexchange=ikev1
authby=xauthrsasig
xauth=server
left=%defaultroute
leftsubnet=0.0.0.0/0
leftid=xxx
leftcert=serverCert.pem
leftsendcert=yes
leftfirewall=yes
leftauth=rsa
rightauth=rsa
rightauth2=xauth
dpdaction=clear
auto=add
conn ios
rightid="C=US, O=xx, CN=test"
rightsourceip=10.0.0.5
I have attempted to create the same configuration using a call to the VICI
with this dictionary:
{ 'test':
{
'version' : 1,
'vips' : ['10.0.0.5'],
'local' : {
'id' : 'x',
'auth' : 'pubkey',
'certs' : [serverCert]
},
'remote': {
'auth' : 'pubkey',
'id' : 'C=US, O=xx, CN=test'
},
'remote2': {
'auth': 'xauth'
},
'children': {
'test' : {
'local_ts' : ['0.0.0.0/0'],
'remote_ts' : ['dynamic']
}
}
}
}
This keeps returning this error: `1 config found, none that allow
xAuthInitRSA using MainMode`
Not sure how to modify this configuration to work correctly. I have tried a
number of different combinations with the same message. Any help would be
appreciated.
Sam
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Regarding strongswan UCI support
Hi, > I am not observing init script to configure ipsec.conf and > ipsec.secrets from /etc/config/strongswan configuration file. Is this > available in any patch or in any other release? where can I find the > init script for it? We don't provide any init scripts from upstream (beside some systemd service files); you'll have to use those provided by your distribution, or write them yourself. > I have one more question, As per my understanding UCI infra will take > the configuration from /etc/config/ and update the module's > configuration file and reload/restarts the daemon. Then what is the > role of UCI plugin in strongswan? Not sure what exactly OpenWRT provides. Does it generate ipsec.conf? The strongSwan uci plugin is a configuration plugin in which the daemon directly reads connection definitions from UCI files. It is rather limited, and didn't get much love during the last years. It does not provide enough functionality for anything more than trivial PSK configurations. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ipv6 GRE sent in clear instead of getting encrypted
Noel,
I've modified my setup from GREv6 to 'traditional' site 2 site. I had a similar
but a bit different problem [ traffic not getting encrypted - but simply
vanishing in the linux ].
After looking at the routing table I've noticed this very wierd route in the
table 220.
root@f-nccf-1a-de:/etc# ip -6 route show table 220
unreachable 2a00:c31:1ffe:fff::/64 dev lo proto static metric 1024 error -101
I've got rid of it and now it works.
Why strongswan is pushing a bogus ipv6 route?
Regards
> Date: Wed, 14 Jan 2015 20:23:10 +0100
> From: n...@familie-kuntze.de
> To: users@lists.strongswan.org
> Subject: Re: [strongSwan] ipv6 GRE sent in clear instead of getting encrypted
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello Olivier,
>
> Does the traffic selector cover the IP addresses used in the IPv6 GRE tunnel
> configuration?
>
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 14.01.2015 um 08:02 schrieb Olivier PELERIN:
> > Any ideas why ipv6 GRE is sent in clear?
> >
> > -
> > From: olivier_pele...@hotmail.com
> > To: users@lists.strongswan.org
> > Date: Fri, 19 Dec 2014 13:27:16 +0100
> > Subject: [strongSwan] ipv6 GRE sent in clear instead of getting encrypted
> >
> > Hello Strongswan Alias,
> >
> > I've the following problem:
> >
> > Trafffic from a remote device is properly decrypted [ transport is GREipv6
> > / overlay is ipv6]. Encrypted packet leave the ubuntu box un-encrypted.
> >
> > Either xfrm policies and state are looking right.
> >
> > ip xfrm policy
> > src 2b00:d31:e7e4:1b::1:201/128 dst 2b00:c31:e7e2:17::2:12/128 proto gre
> > dir fwd priority 1026
> > tmpl src 2b00:d31:e7e4:1b::1:201 dst 2b00:c31:e7e2:17::2:12
> > proto esp reqid 2687 mode tunnel
> > src 2b00:d31:e7e4:1b::1:201/128 dst 2b00:c31:e7e2:17::2:12/128 proto gre
> > dir in priority 1026
> > tmpl src 2b00:d31:e7e4:1b::1:201 dst 2b00:c31:e7e2:17::2:12
> > proto esp reqid 2687 mode tunnel
> > src 2b00:c31:e7e2:17::2:12/128 dst 2b00:d31:e7e4:1b::1:201/128 proto gre
> > dir out priority 1026
> > tmpl src 2b00:c31:e7e2:17::2:12 dst 2b00:d31:e7e4:1b::1:201
> > proto esp reqid 2687 mode tunnel
> > src 0.0.0.0/0 dst 0.0.0.0/0
> > socket in priority 0
> > src 0.0.0.0/0 dst 0.0.0.0/0
> > socket out priority 0
> > src 0.0.0.0/0 dst 0.0.0.0/0
> > socket in priority 0
> > src 0.0.0.0/0 dst 0.0.0.0/0
> > socket out priority 0
> > src ::/0 dst ::/0
> > socket in priority 0
> > src ::/0 dst ::/0
> > socket out priority 0
> > src ::/0 dst ::/0
> > socket in priority 0
> > src ::/0 dst ::/0
> > socket out priority 0
> >
> > root@zg-nccf-1a-hr:/home/localadmin# ip xfrm state
> > src 2b00:c31:e7e2:17::2:12 dst 2b00:d31:e7e4:1b::1:201
> > proto esp spi 0xb173226b reqid 2687 mode tunnel
> > replay-window 32 flag af-unspec
> > auth-trunc hmac(sha1) 0x630d4dae250e28a9dfd1184b20dfd0e33cda1665 96
> > enc cbc(aes) 0x3dc58789ace1be5fccdb4b2c42b3aa23
> > src 2b00:d31:e7e4:1b::1:201 dst 2b00:c31:e7e2:17::2:12
> > proto esp spi 0xccbc90f5 reqid 2687 mode tunnel
> > replay-window 32 flag af-unspec
> > auth-trunc hmac(sha1) 0xd7e81acb481eb00c2389bdfdc2e7fdc1ca0b6417 96
> > enc cbc(aes) 0x9e7d10c82aa14b562c541482d6b5933b
> >
> >
> > ipsec statusall
> > Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-32-generic,
> > x86_64):
> > uptime: 7 minutes, since Dec 19 12:12:26 2014
> > malloc: sbrk 2568192, mmap 0, used 358352, free 2209840
> > worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> > scheduled: 2
> > loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random
> > nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc
> > cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke
> > updown eap-identity addrblock
> > Listening IP addresses:
> > 2a00:c31:7fe2:17::1:11
> >
> > 2001::2
> > Connections:
> > CSR1000V: %any...2b00:d31:e7e4:1b::1:201 IKEv2
> > CSR1000V: local: [] uses pre-shared key authentication
> > CSR1000V: remote: [] uses pre-shared key authentication
> > CSR1000V: child: 2b00:c31:e7e2:17::2:12/128[gre] ===
> > 2b00:d31:e7e4:1b::1:201/128[gre] TUNNEL
> > Security Associations (1 up, 0 connecting):
> > CSR1000V[1]: ESTABLISHED 7 minutes ago,
> > 2b00:c31:e7e2:17::2:12[]...2b00:d31:e7e4:1b::1:201[]
> > CSR1000V[1]: IKEv2 SPIs: db2eec9fddaea13f_i* 5b0acc0ed25bced5_r,
> > pre-shared key reauthentication in 23 hours
> > CSR1000V[1]: IKE proposal:
> > AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
> > CSR1000V{1}: INSTALLED, TUNNEL, ESP SPIs: c673e3d6_i 1e5da7b9_o
> > CSR1000V{1}: AES_CBC_128/HMAC_SHA1_96, 4512 bytes_i (34 pkts, 333s
> > ago), 0 bytes_o, rekeying in 34 minutes
> > CSR1000V{1}: 2b00:c31:e7e2:17::2:12/128[gre] ===
> > 2b00:d31:e7e4:1b::1:201/128[gre]
> > root@zg-nccf-1a-hr:/home/localadmin#
> >
> > conn CSR1000V
>
Re: [strongSwan] OSX weakswan pfkey_open no such file
Hi Tobias, thanks for your help. I just did and uninstall and install without options, using same conf files, but with other internet provider, and now it works as espected, in the second attempt. Looks like the ipsec trafic was not allowed in that spot. I didn't need to use leftsourceip=%config, since in the sonicwall profile we use the option "Virtual adapter settings: DHCP Lease or Manual Configuration". I'll like to congratulate all of you for your effort. I have the same conn configuration running in RHEL 6, centOS 6, openSUSE 13.2, ubuntu 14.4 and OSX 10.10. The only diference is that in ubuntu and opensuse, our rigthid that uses espaces have to be "double quoted", because it runs version 5.1. Now I'm trying iOS and Android ;-) Thanks again. -- Alejandro Valcarcel Garcia Responsable de sistemas y comunicaciones ODEC - Construimos Soluciones avalcar...@odec.es - http://www.odec.es - Calle Vicent Macip, 1 (46701) Gandia SPAIN - T: +34 962 860 466 ext 1292 - M: +34 699 679 435 2015-02-24 15:02 GMT+01:00 Tobias Brunner : > Hi Alejandro, > > > brew install strongswan --with-curl --with-suite-b > > If you use `--with-suite-b` our own userland IPsec implementation will > be used instead of the kernel's via PF_KEY. So you won't see any output > in `setkey -D` (also you'd have to run that command as superuser with > sudo). > > > parsed INFORMATIONAL_V1 request 2418823313 [ HASH N(INITIAL_CONTACT) ] > > configuration payload missing in XAuth request > > ... > > The tunnel is stablished OK always in the second try, sonicwalls asks > > twice for the username and password. > > Looks like Sonicwall sends an INITIAL_CONTACT in an INFORMATIONAL > exchange during the XAuth exchange (and even though it is the server). > Apparently, charon has trouble handling this properly. In the second > try the Sonicwall perhaps still has the state from the first attempt > around and therefore does not send the notify. > > > But once stablished no packets are arriving to the VPN Server. > > You might need to request a virtual IP address [1] from the server using > `leftsourceip=%config`, which is usually the case in remote access > scenarios. > > Regards, > Tobias > > [1] https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] 60+ SAs listed in ipsec status output?
I have a tunnel between two Strongswan boxes that is set
to rekey IKE every 8 hours and rekey the SA every 1 hour.
Here is the local ipsec.conf (the other side is the same,
but has a dozen other tunnels, too):
[root@hudson ~]# cat /etc/ipsec.conf
version 2
conn %default
keyingtries=%forever
include /etc/ipsec.user.conf
conn Data
left=ipa.ddr.ess.a
leftsubnet=192.168.0.0/21
leftfirewall=yes
lefthostaccess=yes
right=ipa.ddr.ess.b
rightsubnet=10.100.0.0/23
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/Datacert.pem
leftid="@hosta.mydom.dom"
rightid="@mydom.dom"
ike=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp
esp=aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256
keyexchange=ikev2
ikelifetime=8h
keylife=1h
compress=yes
dpdaction=restart
dpddelay=120
dpdtimeout=30
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
auto=route
For some reason, if I leave the machine to its own
devices, the output of ipsec status ends up littered with
old (?) SA entries, that make no sense to me. Why would
this be happening?:
Routed Connections:
Data{4}: ROUTED, TUNNEL
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Security Associations (1 up, 0 connecting):
Data[286]: ESTABLISHED 33 minutes ago,
ipa.ddr.ess.a[C=US, ST=NH, O=Mydom, OU=Engineering Dept,
CN=hosta.mydom.dom]...ipa.ddr.ess.b[C=US, ST=NH, O=Mydom,
OU=Engineering Dept, CN=mydom.dom]
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c8107662_i
c89e3611_o, IPCOMP CPIs: 43cf_i 36be_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: cb693600_i
c09bb1e2_o, IPCOMP CPIs: b74b_i 2a3a_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: cf34c325_i
c8ae364f_o, IPCOMP CPIs: 04c8_i db51_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c6450374_i
c89d0fd0_o, IPCOMP CPIs: b2d5_i 8f17_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: ccb82be4_i
cb8c6de5_o, IPCOMP CPIs: cc2f_i 7485_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c046292d_i
cb9c5941_o, IPCOMP CPIs: e1ef_i eb0b_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c46c40fa_i
c8cb22a6_o, IPCOMP CPIs: 7468_i 1a4e_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c7471719_i
ceb7ebfb_o, IPCOMP CPIs: abd5_i 15fd_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c79e5c03_i
c47d2958_o, IPCOMP CPIs: 3646_i 32ee_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c34675de_i
c8e2a79b_o, IPCOMP CPIs: 268c_i b0c6_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c000d12c_i
cb8c4f5f_o, IPCOMP CPIs: 48e4_i 10ff_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: cdf3f6f1_i
c268a557_o, IPCOMP CPIs: 2d38_i 2aa2_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c79415e3_i
c145e90e_o, IPCOMP CPIs: e71d_i 689e_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: cb6195e9_i
c6e07cf3_o, IPCOMP CPIs: e0a9_i 71e5_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c47ffca9_i
cbed8f2e_o, IPCOMP CPIs: 6fd0_i 1fc1_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c64f97ef_i
c848ff51_o, IPCOMP CPIs: 088f_i 474d_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: cfc07514_i
cddf8c9b_o, IPCOMP CPIs: 151a_i 3337_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c2c00cee_i
c82e3f90_o, IPCOMP CPIs: 8b0a_i d772_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c85abeb0_i
cc4c2e4e_o, IPCOMP CPIs: b555_i 81aa_o
Data{4}: 192.168.0.0/21 === 10.100.0.0/23
Data{4}: INSTALLED, TUNNEL, ESP SPIs: c81f806b_i
c0306bc7_o, IPCOMP CPIs: 2e43_i cf80_o
Data{4}: 192.168.0.0/21 =
[strongSwan] Regarding strongswan UCI support
Hi All, I have compiled strongswan5.2.1 on openwrt attitude adjustment and enabled UCI plugin. I am not observing init script to configure ipsec.conf and ipsec.secrets from /etc/config/strongswan configuration file. Is this available in any patch or in any other release? where can I find the init script for it? I have one more question, As per my understanding UCI infra will take the configuration from /etc/config/ and update the module's configuration file and reload/restarts the daemon. Then what is the role of UCI plugin in strongswan? Regards, -Sridhar ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan using VTI - got it working!
Hello, Apologize for the huge delay but I had many things going on. I will try to restart my environment in a few days. I will paste the Cisco config + the Strongswan side. I'm sure it can be useful for someone. Regards Date: Fri, 19 Dec 2014 15:37:32 +0100 From: avalen...@marcant.net To: users@lists.strongswan.org Subject: Re: [strongSwan] Strongswan using VTI - got it working! Hi! It would be wonderful if you could document your setup in an email to the list, inluding kernel version. I would even create an Wiki Article for it, if it's allowed. Kind regards, André Am 19.12.2014 um 15:11 schrieb Olivier PELERIN: Thanks Martin! Quick question, If I understand you well, it's a global setting. Are you planning to add a knob under the conn itself? It would be nice to be able to control it per conn. Regards, Olivier > Subject: Re: [strongSwan] Strongswan using VTI - got it working! > From: mar...@strongswan.org > To: olivier_pele...@hotmail.com > CC: schw...@gaertner.de; n...@familie-kuntze.de; users@lists.strongswan.org > Date: Fri, 19 Dec 2014 15:07:09 +0100 > > > > Question: what is the use of that table 220? Do we have a CLI to avoid > > Strongswan installing that route? It's not necessary in case of VTI. > > strongSwan installs routes for negotiated policies to a dedicated > routing table mainly for two reasons: > * Avoid any conflicts with the main routing table, for example > with the default route > * Ignore routes from this table when doing route lookups for IKE > traffic; IKE packets should always bypass the tunnel. > > To disable automatic route installation, set the install_routes option > to no in the strongswan.conf "charon" section. The routing_table and > routing_table_prio options allow you to customize installation of > routes. > > Regards > Martin > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users Mit freundlichen Grüßen André Valentin Systemadministrator -- MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18 URL: http://www.marcant.net | http://www.global-m2m.com Internet * Netzwerk * Mobile Daten Citrix Silver Solution Advisor Geschäftsführer: Thorsten Hojas Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238 ___ Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung. Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
