Hi Walid, to me it seems that your problem is related to the one described in
https://lists.strongswan.org/pipermail/users/2008-September/002705.html The only thing I can suggest is to upgrade your kernel or to apply the patch that was posted in the e-mail mentioned above. But be aware that this patch might break other features of strongSwan. I would go for the first option if possible: Upgrade the kernel. Regards, Daniel Walid Aweiwi wrote: > Hi Daniel, > > Exactly I have CentOS5/RHEL5 machine, actually it is a trixbox 2.6.13, is > this my problem? > > ip xfrm monitor > > > > Deleted src 192.168.14.1 dst 82.102.240.47 > proto esp spi 0x6909a1ff reqid 16385 mode tunnel > replay-window 32 > auth sha1 0xfea69a74cab82ffbd8d34456f8e7c80ee2a40873 > enc aes 0xbe25c4cfb9248829fec842d816684234 > encap type espinudp sport 4500 dport 10559 addr 0.0.0.0 > Deleted src 82.102.240.47 dst 192.168.14.1 > proto esp spi 0xf40155fb reqid 16385 mode tunnel > replay-window 32 > auth sha1 0x444138c885b07307d384a66367566db0e61f3c42 > enc aes 0x15cfdeaff19184eb252aff99ce34e115 > encap type espinudp sport 10559 dport 4500 addr 0.0.0.0 > > > -- > Best Regards > Walid Aweiwi > Systems Engineer > Network Department > Bisan Systems Ltd. > Tel +97222985941 ext 202 > Fax +97222985942 > Mobile +972599673507 > http://www.bisan.com > http://www.bisan.ps > > ---------- Original Message ----------- > From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com> > To: Walid Aweiwi <wa...@bisan.com> > Cc: users@lists.strongswan.org > Sent: Fri, 02 Jan 2009 16:18:10 +0100 > Subject: Re: [strongSwan] Problem with ikev1 net2net-psk, both VPN > servers are behind NAT > >> Hi Walid, >> >> I must admit that I still have no idea what the reason for this problem is. >> >> But I found a message on this mailing list in which a very similar >> problem is described: >> >> https://lists.strongswan.org/pipermail/users/2008-February/002258.html >> >> The author was using a CentOS5/RHEL5 machine. Are you using the same >> distribution? >> >> He says that the command "ipsec status" deletes entries in the SPD. >> Could you please run "ip xfrm policy" before executing "ipsec status"? >> Also please run "ip xfrm monitor" while you're running strongSwan. "ip >> xfrm monitor" is like "tail -f". It prints all the changes that were >> made to the SPD. So you need to run this on a separate tty while you're >> starting strongSwan. >> >> Please send us the output of "ip xfrm monitor". >> >> Daniel >> >> Walid Aweiwi wrote: >>> Hi Daniel, >>> >>> I forgot to mentioned that I'm using virtual interface (eth0, eth0:1) not >>> two NICs, eth0 >>> is the WAN "external" NIC and the eth0:1 is the LAN "internal" NIC. >>> >>> -- >>> Best Regards >>> Walid Aweiwi >>> Systems Engineer >>> Network Department >>> Bisan Systems Ltd. >>> Tel +97222985941 ext 202 >>> Fax +97222985942 >>> Mobile +972599673507 >>> http://www.bisan.com >>> http://www.bisan.ps >>> >>> ---------- Original Message ----------- >>> From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com> >>> To: Walid Aweiwi <wa...@bisan.com> >>> Cc: users@lists.strongswan.org >>> Sent: Fri, 02 Jan 2009 13:14:12 +0100 >>> Subject: Re: [strongSwan] Problem with ikev1 net2net-psk, both VPN >>> servers are > behind NAT >>>> Hi Walid, >>>> >>>> thanks for the debug output. >>>> The command "ip xfrm policy" printed the contents of the so called >>>> Security Policy Database or SPD. To me it seems that the correct entries >>>> are missing in this database. It's over my head why those entries are >>>> missing. Also, the routing table misses necessary entries as well. >>>> >>>> From the tcpdump output you provided I can see that the packets are not >>>> encrypted which is a consequence of the fact that those SPD entries are >>>> missing. >>>> >>>> I would like to ask you again to provide additional data: You enabled >>>> >>>> plutodebug=control >>>> >>>> which is a good thing. Could you please provide us with the data from >>>> the syslog output. This is in /var/log/auth.log on my debian system but >>>> it might be located in a different file depending on your distribution. >>>> I'm interested in the lines containing "pluto[xxxx]". >>>> >>>> Thanks >>>> Daniel >>>> >>>> Walid Aweiwi wrote: >>>>> Hi Daniel, >>>>> >>>>> RED output logs: >>>>> ip route list >>>>> 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.100 >>>>> 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.254 >>>>> 169.254.0.0/16 dev eth0 scope link >>>>> default via 192.168.2.1 dev eth0 >>>>> >>>>> ipsec status >>>>> 000 "net-net": >>>>> > 192.168.100.0/24===192.168.2.254:45...@moon.strongswan.org]...213.6.10.244:45...@sun.strongswan.org]===192.168.25.0/24; >>>>> erouted; eroute owner: #4 >>>>> 000 "net-net": newest ISAKMP SA: #3; newest IPsec SA: #4; >>>>> 000 >>>>> 000 #2: "net-net" STATE_QUICK_I2 (sent QI2, IPsec SA established); >>>>> EVENT_SA_REPLACE >>> in 722s >>>>> 000 #2: "net-net" esp.a1da8...@213.6.10.244 (0 bytes) >>>>> esp.70034...@192.168.2.254 (0 >>>>> bytes); tunnel >>>>> 000 #1: "net-net" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE >>>>> in 3136s >>>>> 000 #4: "net-net" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE >>>>> in 871s; >>>>> newest IPSEC; eroute owner >>>>> 000 #4: "net-net" esp.c1322...@213.6.10.244 (0 bytes) >>>>> esp.c5b53...@192.168.2.254; > tunnel >>>>> 000 #3: "net-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); >>>>> EVENT_SA_REPLACE in >>>>> 3271s; newest ISAKMP >>>>> 000 >>>>> >>>>> ip xfrm policy >>>>> src ::/0 dst ::/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src ::/0 dst ::/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> >>>>> ip xfrm state >>>>> src 213.6.10.244 dst 192.168.2.254 >>>>> proto esp spi 0xc5b532b7 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x5c0a3d0f315b36ad2210bbabfe90202ea27a9012 >>>>> enc aes 0xaee1287ed6439f8f7f06e9608a3bc044 >>>>> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 >>>>> src 213.6.10.244 dst 192.168.2.254 >>>>> proto esp spi 0x700349d6 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x127407c58db393cffcbfdea180fa8d5018bac1d4 >>>>> enc aes 0xa477d0b7b8393a8ccd643f43a4f379d6 >>>>> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 >>>>> src 192.168.2.254 dst 213.6.10.244 >>>>> proto esp spi 0xc13228b8 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x9ca5f62b66e851411b0e7304533f510d2ed81f55 >>>>> enc aes 0xfe00b0f04372a74c1f8a0fd5e732e8ce >>>>> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 >>>>> src 192.168.2.254 dst 213.6.10.244 >>>>> proto esp spi 0xa1da8e02 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x8fee90346508a1cf1e4a3fc7f194ec1563223eb6 >>>>> enc aes 0x99188eda96220f3faad60b9bd6bbf717 >>>>> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 >>>>> >>>>> >>>>> >>>>> >>>>> BLUE output logs: >>>>> >>>>> ip route list >>>>> 192.168.14.0/24 dev eth0 proto kernel scope link src 192.168.14.1 >>>>> 192.168.25.0/24 dev eth0 proto kernel scope link src 192.168.25.25 >>>>> 169.254.0.0/16 dev eth0 scope link >>>>> default via 192.168.14.254 dev eth0 >>>>> >>>>> ipsec status >>>>> 000 "net-net": >>>>> > 192.168.25.0/24===192.168.14.1:45...@sun.strongswan.org]...82.102.240.47:101...@moon.strongswan.org]===192.168.100.0/24; >>>>> erouted; eroute owner: #4 >>>>> 000 "net-net": newest ISAKMP SA: #1; newest IPsec SA: #4; >>>>> 000 >>>>> 000 #4: "net-net" STATE_QUICK_I2 (sent QI2, IPsec SA established); >>>>> EVENT_SA_REPLACE in >>>>> 488s; newest IPSEC; eroute owner >>>>> 000 #4: "net-net" esp.c5b53...@82.102.240.47 (0 bytes) >>>>> esp.c1322...@192.168.14.1 (0 >>>>> bytes); tunnel >>>>> 000 #1: "net-net" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE >>>>> in 3011s; >>>>> newest ISAKMP >>>>> 000 #3: "net-net" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE >>>>> in 727s >>>>> 000 #3: "net-net" esp.70034...@82.102.240.47 (0 bytes) >>>>> esp.a1da8...@192.168.14.1 (0 >>>>> bytes); tunnel >>>>> 000 #2: "net-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); >>>>> EVENT_SA_REPLACE >>> in 3126s >>>>> 000 >>>>> >>>>> src ::/0 dst ::/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir in priority 0 >>>>> src ::/0 dst ::/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 >>>>> dir out priority 0 >>>>> >>>>> src 192.168.14.1 dst 82.102.240.47 >>>>> proto esp spi 0xc5b532b7 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x5c0a3d0f315b36ad2210bbabfe90202ea27a9012 >>>>> enc aes 0xaee1287ed6439f8f7f06e9608a3bc044 >>>>> encap type espinudp sport 4500 dport 10171 addr 0.0.0.0 >>>>> src 192.168.14.1 dst 82.102.240.47 >>>>> proto esp spi 0x700349d6 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x127407c58db393cffcbfdea180fa8d5018bac1d4 >>>>> enc aes 0xa477d0b7b8393a8ccd643f43a4f379d6 >>>>> encap type espinudp sport 4500 dport 10171 addr 0.0.0.0 >>>>> src 82.102.240.47 dst 192.168.14.1 >>>>> proto esp spi 0xc13228b8 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x9ca5f62b66e851411b0e7304533f510d2ed81f55 >>>>> enc aes 0xfe00b0f04372a74c1f8a0fd5e732e8ce >>>>> encap type espinudp sport 10171 dport 4500 addr 0.0.0.0 >>>>> src 82.102.240.47 dst 192.168.14.1 >>>>> proto esp spi 0xa1da8e02 reqid 16385 mode tunnel >>>>> replay-window 32 >>>>> auth sha1 0x8fee90346508a1cf1e4a3fc7f194ec1563223eb6 >>>>> enc aes 0x99188eda96220f3faad60b9bd6bbf717 >>>>> encap type espinudp sport 10171 dport 4500 addr 0.0.0.0 >>>>> >>>>> >>>>> >>>>> >>>>> the tcpdump logs on RED. >>>>> >>>>> tcpdump -i eth0 not port ssh and not port domain and not arp >>>>> >>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >>>>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes >>>>> 13:15:32.213144 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:15:32.815520 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>>> Request from >>>>> 00:13:ce:e1:90:39 (oui Unknown), length: 300 >>>>> 13:15:32.822317 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>>> Request from >>>>> 00:13:ce:e1:90:39 (oui Unknown), length: 326 >>>>> 13:15:33.214593 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:15:35.696800 IP 192.168.2.100 > IGMP.MCAST.NET: igmp v3 report, 1 >>>>> group record(s) >>>>> 13:15:35.733188 IP 192.168.2.100.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): REGISTRATION; REQUEST; BROADCAST >>>>> 13:15:41.256312 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:41.256475 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:42.005718 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:42.005887 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:42.756095 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:42.756299 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:43.505142 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:44.255700 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:45.005950 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:15:45.575554 IP a10-244.adsl.paltel.net.ipsec-nat-t > >>>>> 192.168.2.254.ipsec-nat-t: >>>>> isakmp-nat-keep-alive >>>>> 13:15:46.607604 IP 192.168.2.254.ipsec-nat-t > >>>>> a10-244.adsl.paltel.net.ipsec-nat-t: >>>>> isakmp-nat-keep-alive >>>>> 13:15:52.214772 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:15:53.216956 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:16:00.755893 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:00.756295 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:01.505012 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:01.505198 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:02.255106 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:02.255466 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:03.004167 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:03.753917 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:04.505081 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:05.263502 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:05.592182 IP a10-244.adsl.paltel.net.ipsec-nat-t > >>>>> 192.168.2.254.ipsec-nat-t: >>>>> isakmp-nat-keep-alive >>>>> 13:16:06.012609 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:06.747796 IP 192.168.2.254.ipsec-nat-t > >>>>> a10-244.adsl.paltel.net.ipsec-nat-t: >>>>> isakmp-nat-keep-alive >>>>> 13:16:06.761678 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: >>>>> NBT UDP >>>>> PACKET(137): QUERY; REQUEST; BROADCAST >>>>> 13:16:12.218682 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:16:12.971620 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id >>>>> 36124, seq 1, >>>>> length 64 >>>>> 13:16:13.220735 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12 >>>>> 13:16:13.971711 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id >>>>> 36124, seq 2, >>>>> length 64 >>>>> 13:16:14.972435 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id >>>>> -- >>>>> Best Regards >>>>> Walid Aweiwi >>>>> Systems Engineer >>>>> Network Department >>>>> Bisan Systems Ltd. >>>>> Tel +97222985941 ext 202 >>>>> Fax +97222985942 >>>>> Mobile +972599673507 >>>>> http://www.bisan.com >>>>> http://www.bisan.ps >>>>> >>>>> ---------- Original Message ----------- >>>>> From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com> >>>>> To: Walid Aweiwi <wa...@bisan.com> >>>>> Cc: users@lists.strongswan.org >>>>> Sent: Fri, 02 Jan 2009 10:26:08 +0100 >>>>> Subject: Re: [strongSwan] Problem with ikev1 net2net-psk, both VPN >>>>> servers are >>> behind NAT >>>>>> Walid Aweiwi wrote: >>>>>> > but my problem is no route nor ping from RED server to BLUE. >>>>>> >>>>>> Hi Walid, >>>>>> >>>>>> could you please provide us with the output of the command >>>>>> >>>>>> ip route list >>>>>> >>>>>> It should contain something like >>>>>> >>>>>> 192.168.25.0/24 dev ppp0 scope link src 192.168.100.100 >>>>>> >>>>>> The outlook will look differently on your machine because you're >>>>>> probably using an ethernet link instead of PPP. >>>>>> >>>>>> The output of "ipsec status" looks very promising. >>>>>> What's the exact output of the ping command? Does it say "no route to >>>>>> host" or is it just not getting any reply (100% packet loss) ? >>>>>> >>>>>> Please run tcpdump on the external interfaces of RED and BLUE in order >>>>>> to see if those boxes transmit ESP packets or just unencrypted ICMP >>>>>> packets. >>>>>> >>>>>> For the sake of completeness you could also include the output of the >>>>>> two following commands: >>>>>> >>>>>> ip xfrm state >>>>>> ip xfrm policy >>>>>> >>>>>> Regards, >>>>>> Daniel >>>>>> >>>>>> ************* >>>>>> This message has been scanned for viruses and dangerous content by >>>>>> Bisan >>>>>> Systems Ltd MailScanner, and is believed to be clean.Bisan Systems Ltd >>>>>> does >>>>>> not represent that any attachment is free from computer viruses or >>>>>> defects and the user assumes all responsibility for any loss, damage >>>>>> or >>>>>> consequence resulting directly or indirectly from the use of any >>>>>> attachment. The information contained in any email does not >>>>>> necessarily >>>>>> reflect the views of Bisan systems or any other related entities or >>>>>> persons. >>>>> ------- End of Original Message ------- >>>>> >>>> ************* >>>> This message has been scanned for viruses and dangerous content by Bisan >>>> Systems Ltd MailScanner, and is believed to be clean.Bisan Systems Ltd >>>> does >>>> not represent that any attachment is free from computer viruses or >>>> defects and the user assumes all responsibility for any loss, damage or >>>> consequence resulting directly or indirectly from the use of any >>>> attachment. The information contained in any email does not >>>> necessarily >>>> reflect the views of Bisan systems or any other related entities or >>>> persons. >>> ------- End of Original Message ------- >>> >> ************* >> This message has been scanned for viruses and dangerous content by Bisan >> Systems Ltd MailScanner, and is believed to be clean.Bisan Systems Ltd >> does >> not represent that any attachment is free from computer viruses or >> defects and the user assumes all responsibility for any loss, damage or >> consequence resulting directly or indirectly from the use of any >> attachment. The information contained in any email does not necessarily >> reflect the views of Bisan systems or any other related entities or persons. > ------- End of Original Message ------- > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
