<div dir="ltr">Not sure if this is an option for your application, but another choice which functions very similarly to VTI's is to use an IPsec+GRE tunnel.<div><br></div><div>Security policy configuration is very simple (you just need any "any any" transform for the tunnel endpoint addresses), and you can tunnel anything you want through the GRE using routes and such, just like with a VTI.</div><div><br></div><div>The only downside is an additional 4 (8 if you use a tunnel key) bytes of per-packet overhead.</div><div><br></div><div>But it's well supported on Cisco and works fine with Strongswan.... create a GRE tunnel interface in Linux, set up the SA, and install routes for whatever you want over the GRE interface.</div><div><br></div><div>/Ry</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 8:15 AM, Noel Kuntze <span dir="ltr"><<a href="mailto:noel@familie-kuntze.de" target="_blank">noel@familie-kuntze.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hello,<br>
<br>
This [1] is the commit that was referenced from your email<br>
Currently, strongswan does not support VTIs. The reason is, that<br>
VTIs use XFRM policies with marks. If you set strongSwan up to create<br>
a connection with marks associated with it, it will insert policies and states<br>
that all have marks associated with them. That means, that incoming esp/ah/espinudp<br>
packets will have to have the correct mark set to it before they reach XFRM LOOKUP [1].<br>
However, the standard way VTIs get set up is with a wildcard policy for esp packets.<br>
That means, that you need to manually mark esp traffic in *mangle INPUT. I wrote an email [2] about that.<br>
If you use VTIs, you do not need to set the mark rules in *mangle POSTROUTINg and *mangle OUTPUT.<br>
The VTI does that for you implicitly.<br>
Furthermore, you probably need to set up routing yourself, instead of having strongSwan<br>
do it (Because of the RP filter. Look into table 220 to see what routes strongSwan adds.).<br>
Logging martians [3] will probably help you figure out what happens and<br>
The return value descriptio of recvmsg [4] from its manpage says, that EAGAIN is nothing to worry about<br>
by itself. There is simply no data to be read from the buffer. I do not think that from this point of progress on,<br>
the problem is not the VTI itself anymore.<br>
<br>
[1] <a href="http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commit;h=44bdc4a2f8d3a25c81f768c7b92d5165e42dfd2d" target="_blank">http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commit;h=44bdc4a2f8d3a25c81f768c7b92d5165e42dfd2d</a><br>
[2] <a href="http://inai.de/images/nf-packet-flow.png" target="_blank">http://inai.de/images/nf-packet-flow.png</a><br>
[3] <a href="https://lists.strongswan.org/pipermail/users/2014-November/006942.html" target="_blank">https://lists.strongswan.org/pipermail/users/2014-November/006942.html</a><br>
[4] net.ipv4.conf.all.log_martians = 0<br>
net.ipv4.conf.default.log_martians = 0<br>
net.ipv4.conf.<interface>.log_martians = 0<br>
[5] EAGAIN or EWOULDBLOCK<br>
The socket's file descriptor is marked O_NONBLOCK and no data is<br>
waiting to be received; or MSG_OOB is set and no out-of-band<br>
data is available and either the socket's file descriptor is<br>
marked O_NONBLOCK or the socket does not support blocking to<br>
await out-of-band data.<br>
<br>
<br>
<br>
Mit freundlichen Grüßen/Regards,<br>
Noel Kuntze<br>
<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
Am 18.12.2014 um 13:06 schrieb Olivier PELERIN:<br>
<span class="">> Tried to follow this kernel commit - it does not work<br>
><br>
> <a href="https://lists.ubuntu.com/archives/kernel-team/2013-November/034116.html" target="_blank">https://lists.ubuntu.com/archives/kernel-team/2013-November/034116.html</a><br>
><br>
> It seems utterly broken<br>
><br>
><br>
</span>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<span class="">> From: <a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a><br>
> To: <a href="mailto:avalentin@marcant.net">avalentin@marcant.net</a>; <a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a><br>
> Date: Thu, 18 Dec 2014 10:11:23 +0100<br>
> Subject: Re: [strongSwan] Strongswan using VTI<br>
><br>
> Will try it out<br>
><br>
> When I strace my ping I'm getting (Resource temporarily unavailable) when we receive the echo-reply<br>
><br>
> sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.2")}, msg_iov(1)=[{"\10\0\312\350Y\362\00096\231\222T\0\0\0\0K+\0\0\0\0\0\0\20\21\22\23\24\25\26\27"..., 64}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 64<br>
> recvmsg(3, 0x7fff93401680, 0) = -1 EAGAIN (Resource temporarily unavailable)<br>
> gettimeofday({1418893623, 10985}, NULL) = 0<br>
> gettimeofday({1418893623, 11029}, NULL) = 0<br>
><br>
><br>
</span>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<span class="">> Date: Thu, 18 Dec 2014 09:20:26 +0100<br>
> From: <a href="mailto:avalentin@marcant.net">avalentin@marcant.net</a><br>
> To: <a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a><br>
> Subject: Re: [strongSwan] Strongswan using VTI<br>
><br>
> Hi !<br>
><br>
> I hate this vti stuff. Only trouble and much to complex.<br>
> Try disable the policies on the vti0 interface. It's under proc/sys/class/net/..vti0/*{policies|xfrm}*<br>
><br>
> Kind regards,<br>
><br>
> André<br>
><br>
> Am 18.12.2014 um 09:04 schrieb Olivier PELERIN:<br>
><br>
><br>
> Unfortunately that does not help.<br>
><br>
> Stats are not showing any drops!<br>
><br>
> manowar python # cat /sys/class/net/vti0/statistics/rx_bytes<br>
> 199752<br>
> manowar python # ping 10.0.0.2 -I vti0<br>
> PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of data.<br>
> ^C<br>
> --- 10.0.0.2 ping statistics ---<br>
> 2 packets transmitted, 0 received, 100% packet loss, time 999ms<br>
><br>
> manowar python # cat /sys/class/net/vti0/statistics/rx_bytes<br>
> 199920<br>
><br>
> All errors counters under vti0 are remaining to zero.<br>
><br>
</span>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<span class="">> Date: Wed, 17 Dec 2014 08:42:26 -0500<br>
> Subject: Re: [strongSwan] Strongswan using VTI<br>
</span>> From: <a href="mailto:ryan@ryanruel.com">ryan@ryanruel.com</a> <mailto:<a href="mailto:ryan@ryanruel.com">ryan@ryanruel.com</a>><br>
> To: <a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a> <mailto:<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a>><br>
> CC: <a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a> <mailto:<a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a>><br>
<span class="">><br>
> When I've seen this happen before (interface sees the traffic, ping or some other process does not), it usually means it's getting dropped by the Kernel.<br>
><br>
> It's usually RP-filtering... you can try to turn it off:<br>
><br>
> # echo 0 > /proc/sys/net/ipv4/conf/vti/rp_filter<br>
> # echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter<br>
><br>
> I wouldn't leave if off permanently, but it might help you get further with testing where the packets are going.<br>
><br>
> /Ryan<br>
><br>
</span><span class="">> On Wed, Dec 17, 2014 at 7:15 AM, Olivier PELERIN <<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a> <mailto:<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a>>> wrote:<br>
><br>
> Kernel wise I'm on 3.18.1. I saw few links on the internet about this prerouting mangling rules but it's very unclear if it's needed or not. I would assume the ikey in the ip tunnel command is enough.<br>
><br>
> I've modified the config by specifying the local address [ instead of using %any] now I've added left=10.1.1.1<br>
><br>
> ipsec statusall<br>
> Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux 3.18.1-gentoo, x86_64):<br>
> uptime: 2 minutes, since Dec 17 13:07:54 2014<br>
> malloc: sbrk 2416640, mmap 0, used 377184, free 2039456<br>
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2<br>
> loaded plugins: charon ldap aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic<br>
> Listening IP addresses:<br>
> 192.168.255.134<br>
> 10.1.1.1<br>
> 10.0.0.1<br>
> Connections:<br>
> VTI: 10.1.1.1...10.1.1.254 IKEv2<br>
> VTI: local: [10.1.1.1] uses pre-shared key authentication<br>
> VTI: remote: [10.1.1.254] uses pre-shared key authentication<br>
</span>> VTI: child: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> TUNNEL<br>
<span class="">> Routed Connections:<br>
> VTI{1}: ROUTED, TUNNEL<br>
</span>> VTI{1}: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
<span class="">> Security Associations (1 up, 0 connecting):<br>
> VTI[1]: ESTABLISHED 2 minutes ago, 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]<br>
> VTI[1]: IKEv2 SPIs: 2be274863074302d_i* 720fa6a0e8c28b09_r, pre-shared key reauthentication in 2 hours<br>
> VTI[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br>
> VTI{1}: INSTALLED, TUNNEL, ESP SPIs: c8da39c8_i 938ec319_o<br>
> VTI{1}: AES_CBC_256/HMAC_SHA1_96, 12848 bytes_i (152 pkts, 23s ago), 12348 bytes_o (147 pkts, 23s ago), rekeying in 39 minutes<br>
</span>> VTI{1}: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
<span class="">><br>
><br>
> Now I'm one step further. I see bytes_i and bytes_o increasing.<br>
><br>
> running tcpdump directly on the VTI interface I see the echo-reply arriving<br>
><br>
> manowar python # tcpdump -nNi vti0<br>
> error : ret -1<br>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>
> listening on vti0, link-type RAW (Raw IP), capture size 262144 bytes<br>
</span>> 13:09:37.669100 IP 10.0.0.1 > 10.0.0.2 <<a href="http://10.0.0.2" target="_blank">http://10.0.0.2</a>>: ICMP echo request, id 18052, seq 4366, length 64<br>
> 13:09:37.669564 IP 10.0.0.2 > 10.0.0.1 <<a href="http://10.0.0.1" target="_blank">http://10.0.0.1</a>>: ICMP echo reply, id 18052, seq 4366, length 64<br>
> 13:09:38.669208 IP 10.0.0.1 > 10.0.0.2 <<a href="http://10.0.0.2" target="_blank">http://10.0.0.2</a>>: ICMP echo request, id 18052, seq 4367, length 64<br>
> 13:09:38.669691 IP 10.0.0.2 > 10.0.0.1 <<a href="http://10.0.0.1" target="_blank">http://10.0.0.1</a>>: ICMP echo reply, id 18052, seq 4367, length 64<br>
<span class="">><br>
> Still traffic seems not to reach the ping process<br>
><br>
> ping 10.0.0.2 -I vti0<br>
> PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of data.<br>
><br>
> vti0 sees the traffic but not the ping process??<br>
><br>
><br>
><br>
><br>
><br>
</span>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<span class="">-<br>
> Subject: Re: [strongSwan] Strongswan using VTI<br>
</span>> From: <a href="mailto:ryan0751@gmail.com">ryan0751@gmail.com</a> <mailto:<a href="mailto:ryan0751@gmail.com">ryan0751@gmail.com</a>><br>
<span class="">> Date: Wed, 17 Dec 2014 06:50:47 -0500<br>
</span>> CC: <a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a> <mailto:<a href="mailto:users@lists.strongswan.org">users@lists.strongswan.org</a>><br>
> To: <a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a> <mailto:<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a>><br>
<span class="">><br>
> I was just trying to get this to work the other day myself and also had problems with the routing.<br>
><br>
> It wasn’t clear to me if you still need to create the PREROUTING mangle rules. such as:<br>
><br>
> # mangle PREROUTING rules:<br>
</span>> iptables -t mangle -A PREROUTING -s <a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a> <<a href="http://192.168.10.0/24" target="_blank">http://192.168.10.0/24</a>> -d <a href="http://192.168.11.0/24" target="_blank">192.168.11.0/24</a> <<a href="http://192.168.11.0/24" target="_blank">http://192.168.11.0/24</a>><br>
<span class="">> -j MARK --set-mark 32<br>
> iptables -t mangle -A PREROUTING -p esp -s 10.1.3.2 -d 10.1.1.2 -j MARK<br>
> --set-mark 32<br>
><br>
> From what I had read the Kernel might have been patched to no longer require this?<br>
><br>
> Have you checked the SA stats on the Linux box (setkey -D or using the ip xfrm command) to see if the packets are matching the SA and are being decrypted?<br>
><br>
> /Ryan<br>
><br>
</span><span class="">> On Dec 17, 2014, at 6:08 AM, Olivier PELERIN <<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a> <mailto:<a href="mailto:olivier_pelerin@hotmail.com">olivier_pelerin@hotmail.com</a>>> wrote:<br>
><br>
> Dear Strongswan alias,<br>
><br>
> I'm trying a VTI config between a linux box and a cisco router.<br>
><br>
> I've created a VTI interface on my linux<br>
><br>
> ip tunnel add vti0 mode vti local 10.1.1.1 remote 10.1.1.254 okey 32 ikey 32<br>
> ip link set vti0 up<br>
</span>> ip addr add <a href="http://10.0.0.1/30" target="_blank">10.0.0.1/30</a> <<a href="http://10.0.0.1/30" target="_blank">http://10.0.0.1/30</a>> remote <a href="http://10.0.0.2/30" target="_blank">10.0.0.2/30</a> <<a href="http://10.0.0.2/30" target="_blank">http://10.0.0.2/30</a>> dev vti0<br>
<span class="">><br>
> conn VTI<br>
> keyexchange=ikev2<br>
> ike=aes256-sha1-modp1024<br>
> esp=aes256-sha1!<br>
> leftid=10.1.1.1<br>
> leftauth=psk<br>
</span>> leftsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
> rightauth=psk<br>
> right=10.1.1.254<br>
> rightid=10.1.1.254<br>
> rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
<span class="">> mark=32<br>
> auto=route<br>
><br>
><br>
><br>
><br>
> manowar python # ipsec statusall<br>
> Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux 3.18.1-gentoo, x86_64):<br>
> uptime: 114 seconds, since Dec 17 11:53:47 2014<br>
> malloc: sbrk 2416640, mmap 0, used 373840, free 2042800<br>
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2<br>
> loaded plugins: charon ldap aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic<br>
> Listening IP addresses:<br>
> 192.168.255.134<br>
> 10.1.1.1<br>
> 10.0.0.1<br>
> Connections:<br>
> VTI: %any...10.1.1.254 IKEv2<br>
> VTI: local: [10.1.1.1] uses pre-shared key authentication<br>
> VTI: remote: [10.1.1.254] uses pre-shared key authentication<br>
</span>> VTI: child: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> TUNNEL<br>
<span class="">> Routed Connections:<br>
> VTI{1}: ROUTED, TUNNEL<br>
</span>> VTI{1}: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
<span class="">> Security Associations (1 up, 0 connecting):<br>
> VTI[1]: ESTABLISHED 109 seconds ago, 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]<br>
> VTI[1]: IKEv2 SPIs: e1e9a005055323ab_i* 78c7cc9d34a5886f_r, pre-shared key reauthentication in 2 hours<br>
> VTI[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br>
> VTI{1}: INSTALLED, TUNNEL, ESP SPIs: c8031e20_i 37b2a5a2_o<br>
> VTI{1}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 1848 bytes_o (22 pkts, 8s ago), rekeying in 44 minutes<br>
</span>> VTI{1}: <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>> === <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><br>
<span class="">><br>
><br>
> I do have ESP in<br>
><br>
> manowar python # tcpdump -nNi netio0<br>
> error : ret -1<br>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>
> listening on netio0, link-type EN10MB (Ethernet), capture size 262144 bytes<br>
</span>> 12:07:57.840726 IP 10.1.1.1 > 10.1.1.254 <<a href="http://10.1.1.254" target="_blank">http://10.1.1.254</a>>: ESP(spi=0x37b2a5a2,seq=0x2bf), length 132<br>
> 12:07:57.841405 IP 10.1.1.254 > 10.1.1.1 <<a href="http://10.1.1.1" target="_blank">http://10.1.1.1</a>>: ESP(spi=0xc8031e20,seq=0x2bf), length 132<br>
> 12:07:58.840971 IP 10.1.1.1 > 10.1.1.254 <<a href="http://10.1.1.254" target="_blank">http://10.1.1.254</a>>: ESP(spi=0x37b2a5a2,seq=0x2c0), length 132<br>
> 12:07:58.841336 IP 10.1.1.254 > 10.1.1.1 <<a href="http://10.1.1.1" target="_blank">http://10.1.1.1</a>>: ESP(spi=0xc8031e20,seq=0x2c0), length 132<br>
<span class="">><br>
><br>
> But it seems not be decapsulated by the kernel.<br>
><br>
> Any ideas why?<br>
> _______________________________________________<br>
> Users mailing list<br>
</span>> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>><br>
<span class="">> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
</span>> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>><br>
<span class="">> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
</span>> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>><br>
<span class="">> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
> Mit freundlichen Grüßen<br>
> André Valentin<br>
><br>
> Systemadministration / Projektkoordination<br>
> --<br>
> MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld<br>
> Fon: <a href="tel:%2B49%20%28521%29%2095945-0" value="+49521959450">+49 (521) 95945-0</a> | Fax: <a href="tel:%2B49%20%28521%29%2095945-18" value="+495219594518">+49 (521) 95945-18</a><br>
> URL: <a href="http://www.marcant.net" target="_blank">http://www.marcant.net</a> | <a href="http://www.global-m2m.com" target="_blank">http://www.global-m2m.com</a><br>
><br>
> Internet * Netzwerk * Mobile Daten<br>
> Citrix Silver Solution Advisor<br>
><br>
> Geschäftsführer: Thorsten Hojas<br>
> Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238<br>
> _____________________________________________________________________<br>
> Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr<br>
> bis 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir<br>
> Ihnen gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen<br>
> mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.<br>
</span>> Sie können natürlich auch gerne jederzeit unter <a href="mailto:support@marcant.net">support@marcant.net</a> <mailto:<a href="mailto:support@marcant.net">support@marcant.net</a>><br>
<span class="">> ein Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.<br>
><br>
><br>
><br>
> Mit freundlichen Grüßen<br>
> André Valentin<br>
> Systemadministrator<br>
> --<br>
> MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld<br>
> Fon: <a href="tel:%2B49%20%28521%29%2095945-0" value="+49521959450">+49 (521) 95945-0</a> | Fax: <a href="tel:%2B49%20%28521%29%2095945-18" value="+495219594518">+49 (521) 95945-18</a><br>
> URL: <a href="http://www.marcant.net" target="_blank">http://www.marcant.net</a> | <a href="http://www.global-m2m.com" target="_blank">http://www.global-m2m.com</a><br>
><br>
> Internet * Netzwerk * Mobile Daten<br>
> Citrix Silver Solution Advisor<br>
><br>
> Geschäftsführer: Thorsten Hojas<br>
> Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238<br>
> ___________________________________________________________<br>
> Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis<br>
> 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen<br>
> gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen<br>
> mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.<br>
> Sie können natürlich auch gerne jederzeit unter <a href="mailto:support@marcant.net">support@marcant.net</a> ein<br>
> Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.<br>
><br>
> _______________________________________________ Users mailing list <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
> _______________________________________________ Users mailing list <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
</span><span class="">> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
</span>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBCAAGBQJUktN3AAoJEDg5KY9j7GZYN1gP/AktHBKFVcK1ZtvuSUTwXolX<br>
SNGvPNB5NBGn2OEicmaB8GVz+++bJKaAcPCantZ31KpmteSIAekDoL8WWgFVeQlO<br>
VLyv4d0acnP7htQU9q5njRrNVcs0xG+9N+dRCcuuRis7oBsrWNiEKbWXq4c7IABL<br>
3jnmRhOYYGOw+nP9MheusaktN/StrbIBXWv9msluZmVaZSIdfqDw1kRZ2mQmzTRu<br>
i7EIxPK7AyXJT4AmBw9mn3g6p6zn177Pf2lOyioMnE3bPNkcCMBXxm+ZquDB7aIZ<br>
UWkJnEzGGdtYz5mtjKAlUgqRxN1rCIikCJ+j+YEb6qNJafdIXBB5ucZn1+jeO2Zi<br>
LsovoZb9BqvMV9BrIMvZ4X7ci9FXshS/U0AygwrWIibtYo3dPBFe5simz0MMFDfL<br>
oD7nXINnd3o1PkKttztd5MJ4OZVIlp1vy6w7bOdCvFDTAD2x06r3Yu8Bq8VL97St<br>
cLElWFLGu00bydTP/qRCyG6+WvRFagYvq33AADfouWDPh4MziJM6LP8SYjZEvozx<br>
3D8JoFL+xSeWduIzADI2ZdVKjPOWGGFsijrMmIwrzNO3Q2EhuQuF+iUuIqbcFThs<br>
eEc9wvTS/yJJwz/LvqMqXQYNoMEvmDLCpJKUGFSBPdoXxRaHlB8TNd0Wa/IlRIEn<br>
NApkhY/ZEA7tDYpyGRIF<br>
=9tsQ<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a></div></div></blockquote></div></div>