Re: [strongSwan] Signature verification failed

2009-09-03 Thread Andreas Steffen
Hi Vivek,

could you send a log file generated with the options

charondebug="chd 2, knl2"

on the linux machine so the reason for the delete becomes
apparent.

Regards

Andreas

vivek bairathi wrote:
> Hi,
> 
> I just got the solution of my problem. Its actually the problem of
> endianness as the endianness is not getting set in the sha1_hasher.c
> and also the code on qnx is compiled using armbe which is big endian.
> So I just set the BIG_ENDIAN in the sha1_hasher.c and finally the
> authentication is successful.
> 
> But now I am getting a new error, as soon as the CHILD_SA is created
> the linux machine sends a delete request for the CHILD_SA to the qnx
> machine. I don't know why this is happening. My ikeliftime, keylife
> and rekeymargin are all in hours so how could this happen.
> 
> Can you tell me or give a possible condition because of which this is
> happening and ofcourse if possible a solution also?
> 
> Thanks & Regards,
> Vivek

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org

Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


[strongSwan] Some problems with charon

2009-09-03 Thread Sasha Chashinski
Hello,
I try to add ability to use my custom cipher algorithm with charon ESP in 
strongSwan4.3.4.
First, I have edited linux kernel to add this algorithm via CryptoAPI and 
XFRM interface.
Then I have use this commands to test that this algorithm is can be used by 
the kernel:

# ip xfrm state add src 192.168.95.203 dst 192.168.95.131 proto esp spi 
0x201 mode tunnel enc "cbc(belt)" 
0x303631383332833323233633833323233633833323233633833323233633323
# ip -s xfrm state
src 192.168.95.203 dst 192.168.95.131
 proto esp spi 0x0201(513) reqid 0(0x) mode tunnel
 replay-window 0 seq 0x flag  (0x)
 enc cbc(belt) 
0x0303631383332833323233633833323233633833323233633833323233633323 (256 
bits)
 sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
 lifetime config:
   limit: soft (INF)(bytes), hard (INF)(bytes)
   limit: soft (INF)(packets), hard (INF)(packets)
   expire add: soft 0(sec), hard 0(sec)
   expire use: soft 0(sec), hard 0(sec)
 lifetime current:
   0(bytes), 0(packets)
   add 2009-09-03 17:32:44 use -
 stats:
   replay-window 0 replay 0 failed 0
# lsmod | grep belt
belt3208  1

Then I’ve applied this patch to strongSwan src:

diff -uNrp 
strongswan-4.3.4.orig/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c 
strongswan-4.3.4.new/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
--- 
strongswan-4.3.4.orig/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c 
 2009-08-31 19:27:18.0 +0300
+++ 
strongswan-4.3.4.new/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c 
  2009-09-01 19:44:45.0 +0300
@@ -177,6 +177,7 @@ static kernel_algorithm_t encryption_alg
 {ENCR_AES_GCM_ICV16,"rfc4106(gcm(aes))" },
  /* {ENCR_NULL_AUTH_AES_GMAC,   "***"   }, 
*/
 {ENCR_CAMELLIA_CBC, "cbc(camellia)" },
+   {ENCR_BELT_CBC, "cbc(belt)" },
  /* {ENCR_CAMELLIA_CTR, "***" 
  }, */
  /* {ENCR_CAMELLIA_CCM_ICV8,"***"   }, 
*/
  /* {ENCR_CAMELLIA_CCM_ICV12,   "***"   }, 
*/
diff -uNrp strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.c 
strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.c
--- strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.c 
  2009-08-31 19:27:18.0 +0300
+++ strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.c 
   2009-09-02 18:31:26.0 +0300
@@ -46,12 +46,13 @@ ENUM_NEXT(encryption_algorithm_names, EN
 "CAMELLIA_CCM_8",
 "CAMELLIA_CCM_12",
 "CAMELLIA_CCM_16");
-ENUM_NEXT(encryption_algorithm_names, ENCR_UNDEFINED, ENCR_TWOFISH_CBC, 
ENCR_CAMELLIA_CCM_ICV16,
+ENUM_NEXT(encryption_algorithm_names, ENCR_UNDEFINED, ENCR_BELT_CBC, 
ENCR_CAMELLIA_CCM_ICV16,
 "UNDEFINED",
 "DES_ECB",
 "SERPENT_CBC",
-   "TWOFISH_CBC");
-ENUM_END(encryption_algorithm_names, ENCR_TWOFISH_CBC);
+   "TWOFISH_CBC",
+   "BELT_CBC");
+ENUM_END(encryption_algorithm_names, ENCR_BELT_CBC);

  /*
   * Described in header.
diff -uNrp strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.h 
strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.h
--- strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.h 
  2009-08-31 19:27:18.0 +0300
+++ strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.h 
   2009-09-01 19:43:07.0 +0300
@@ -58,7 +58,8 @@ enum encryption_algorithm_t {
 ENCR_UNDEFINED =1024,
  ENCR_DES_ECB =  1025,
 ENCR_SERPENT_CBC =  1026,
-ENCR_TWOFISH_CBC =  1027
+ENCR_TWOFISH_CBC =  1027,
+ENCR_BELT_CBC = 1028
  };

  #define DES_BLOCK_SIZE  8
diff -uNrp 
strongswan-4.3.4.orig/src/libstrongswan/crypto/proposal/proposal_keywords.txt 
strongswan-4.3.4.new/src/libstrongswan/crypto/proposal/proposal_keywords.txt
--- 
strongswan-4.3.4.orig/src/libstrongswan/crypto/proposal/proposal_keywords.txt 
  2009-08-31 19:27:18.0 +0300
+++ 
strongswan-4.3.4.new/src/libstrongswan/crypto/proposal/proposal_keywords.txt 
   2009-09-02 19:15:58.0 +0300
@@ -116,3 +116,4 @@ ecp224,   DIFFIE_HELLMAN_GROUP,
  ecp256,   DIFFIE_HELLMAN_GROUP, ECP_256_BIT,  0
  ecp384,   DIFFIE_HELLMAN_GROUP, ECP_384_BIT,  0
  ecp521,   DIFFIE_HELLMAN_GROUP, ECP_521_BIT,  0
+belt, ENCRYPTION_ALGORITHM, ENCR_BELT_CBC,  256
\ No newline at end of file

I’ve tested this patched strongSwan connection between two hosts.

# /etc/ipsec.conf - strongSwan IPsec configuration file
config setup
 crlcheckinterval=180
 strictcrlpolicy=no
 plutostart=no

conn %default
 

Re: [strongSwan] Some problems with charon

2009-09-03 Thread Andreas Steffen
Hello Sasha,

yeah, the proposal parser does not recognize your belt cipher
defined by

esp=belt-sha1!

the error message is

> Sep  3 15:57:27 samar charon:
 02[CFG] skipped invalid proposal string: belt-sha1

The new entry in libstrongswan/crypto/proposal/proposal_keywords.txt
>   ecp384,   DIFFIE_HELLMAN_GROUP, ECP_384_BIT,  0
>   ecp521,   DIFFIE_HELLMAN_GROUP, ECP_521_BIT,  0
>   belt, ENCRYPTION_ALGORITHM, ENCR_BELT_CBC,  256

seems correct, I hope that the warning

> \ No newline at end of file

does not prevent gperf from parsing the last line in the file.
If you checked strongSwan out of our git repository then "make" should
call "gperf" to build an updated file

  libstrongswan/crypto/proposal_keywords.c

which is of the form:

static const struct proposal_token wordlist[] =
  {
{"null", ENCRYPTION_ALGORITHM, ENCR_NULL,0},
{"aes192",   ENCRYPTION_ALGORITHM, ENCR_AES_CBC,   192},
{"aesxcbc",  INTEGRITY_ALGORITHM,  AUTH_AES_XCBC_96, 0},
{"aes",  ENCRYPTION_ALGORITHM, ENCR_AES_CBC,   128},
{"aes128",   ENCRYPTION_ALGORITHM, ENCR_AES_CBC,   128},
{"des",  ENCRYPTION_ALGORITHM, ENCR_DES, 0},
{"aes192ctr",ENCRYPTION_ALGORITHM, ENCR_AES_CTR,   192},

and contain the belt entry somewhere. If you made your changes based
on a strongSwan tarball then you must call gperf manually:

gperf -N proposal_get_token -m 10 -C -G -c -t -D  \
   < proposal_keywords.txt > proposal_keywords.c

Best regards

Andreas

Sasha Chashinski wrote:
> Hello,
> I try to add ability to use my custom cipher algorithm with charon ESP in 
> strongSwan4.3.4.
> First, I have edited linux kernel to add this algorithm via CryptoAPI and 
> XFRM interface.
> Then I have use this commands to test that this algorithm is can be used by 
> the kernel:
> 
> # ip xfrm state add src 192.168.95.203 dst 192.168.95.131 proto esp spi 
> 0x201 mode tunnel enc "cbc(belt)" 
> 0x303631383332833323233633833323233633833323233633833323233633323
> # ip -s xfrm state
> src 192.168.95.203 dst 192.168.95.131
>  proto esp spi 0x0201(513) reqid 0(0x) mode tunnel
>  replay-window 0 seq 0x flag  (0x)
>  enc cbc(belt) 
> 0x0303631383332833323233633833323233633833323233633833323233633323 (256 
> bits)
>  sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
>  lifetime config:
>limit: soft (INF)(bytes), hard (INF)(bytes)
>limit: soft (INF)(packets), hard (INF)(packets)
>expire add: soft 0(sec), hard 0(sec)
>expire use: soft 0(sec), hard 0(sec)
>  lifetime current:
>0(bytes), 0(packets)
>add 2009-09-03 17:32:44 use -
>  stats:
>replay-window 0 replay 0 failed 0
> # lsmod | grep belt
> belt3208  1
> 
> Then I’ve applied this patch to strongSwan src:
> 
> diff -uNrp 
> strongswan-4.3.4.orig/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
>  
> strongswan-4.3.4.new/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
> --- 
> strongswan-4.3.4.orig/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
>  
>  2009-08-31 19:27:18.0 +0300
> +++ 
> strongswan-4.3.4.new/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c 
>   2009-09-01 19:44:45.0 +0300
> @@ -177,6 +177,7 @@ static kernel_algorithm_t encryption_alg
>  {ENCR_AES_GCM_ICV16,"rfc4106(gcm(aes))" },
>   /* {ENCR_NULL_AUTH_AES_GMAC,   "***"   }, 
> */
>  {ENCR_CAMELLIA_CBC, "cbc(camellia)" },
> +   {ENCR_BELT_CBC, "cbc(belt)" },
>   /* {ENCR_CAMELLIA_CTR, "***" 
>   }, */
>   /* {ENCR_CAMELLIA_CCM_ICV8,"***"   }, 
> */
>   /* {ENCR_CAMELLIA_CCM_ICV12,   "***"   }, 
> */
> diff -uNrp strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.c 
> strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.c
> --- strongswan-4.3.4.orig/src/libstrongswan/crypto/crypters/crypter.c 
>   2009-08-31 19:27:18.0 +0300
> +++ strongswan-4.3.4.new/src/libstrongswan/crypto/crypters/crypter.c 
>2009-09-02 18:31:26.0 +0300
> @@ -46,12 +46,13 @@ ENUM_NEXT(encryption_algorithm_names, EN
>  "CAMELLIA_CCM_8",
>  "CAMELLIA_CCM_12",
>  "CAMELLIA_CCM_16");
> -ENUM_NEXT(encryption_algorithm_names, ENCR_UNDEFINED, ENCR_TWOFISH_CBC, 
> ENCR_CAMELLIA_CCM_ICV16,
> +ENUM_NEXT(encryption_algorithm_names, ENCR_UNDEFINED, ENCR_BELT_CBC, 
> ENCR_CAMELLIA_CCM_ICV16,
>  "UNDEFINED",
>  "DES_ECB",
>  "SERPENT_CBC",
> -   "TWOFISH_CBC");
> -ENUM_END(encryption_algorithm_names, ENCR_TWOFI

Re: [strongSwan] Signature verification failed

2009-09-03 Thread vivek bairathi
Hi,

I just got the solution of my problem. Its actually the problem of
endianness as the endianness is not getting set in the sha1_hasher.c
and also the code on qnx is compiled using armbe which is big endian.
So I just set the BIG_ENDIAN in the sha1_hasher.c and finally the
authentication is successful.

But now I am getting a new error, as soon as the CHILD_SA is created
the linux machine sends a delete request for the CHILD_SA to the qnx
machine. I don't know why this is happening. My ikeliftime, keylife
and rekeymargin are all in hours so how could this happen.

Can you tell me or give a possible condition because of which this is
happening and ofcourse if possible a solution also?

Thanks & Regards,
Vivek

On 9/3/09, vivek bairathi  wrote:
> Hi,
>
> Thanks for your reply.
>
> I am trying to establish SA between two machines of which one is QNX
> machine and the other is Linux machine. I am able to transmit the
> IKE_SA_INIT request and response messages from one machine to another
> but when IKE_AUTH request is received by any of the machine it says
> that the "signature verification failed".
>
> Here are the logs of IKE_AUTH request message sent from QNX machine to
> linux machine:-
>
> IKE_AUTH request message sent by QNX machine:-
>
> (gdb) x/208b data.ptr
>
> 0x808c7c0:  0x670x410xc80xe90xb40x1f0x51
> 0x61
>
> 0x808c7c8:  0x8c0x410xa50x410x490xa00x5b
> 0x21
>
> 0x808c7d0:  0x2e0x200x230x080x000x000x00
> 0x01
>
> 0x808c7d8:  0x000x000x000xdc0x230x000x00
> 0xc0
>
> 0x808c7e0:  0x9f0x800xd50x480x140x850x2a
> 0xe0
>
> 0x808c7e8:  0x210x5b0x300x680xd30xf10xe6
> 0xff
>
> 0x808c7f0:  0xa40x410xfa0x030x530x6c0x9a
> 0xe9
>
> 0x808c7f8:  0x550xce0x4b0x320x890x040x27
> 0xc3
>
> 0x808c800:  0x270x080x1d0xf50x880x2b0x60
> 0xd1
>
> 0x808c808:  0xc70x740xe60x4e0x130x470x06
> 0xf7
>
> 0x808c810:  0xdf0xfe0xb80x850xc10x300x65
> 0x91
>
> 0x808c818:  0x3e0xef0x120xce0xda0x070x7d
> 0xd6
>
> 0x808c820:  0x1a0x9c0xfe0x280x840x420xa8
> 0x43
>
> 0x808c828:  0xd10x900x090xbe0x2d0xf30x61
> 0x8a
>
> 0x808c830:  0x3c0xf50xa70x450x450x390x01
> 0x1b
>
> 0x808c838:  0x800x110xd50x7b0xad0x5c0x09
> 0xef
>
> 0x808c840:  0xd10x070xab0x330x450xd80xeb
> 0x9c
>
> 0x808c848:  0xe10xb30xc00xe80x830xb10x01
> 0x1f
>
> 0x808c850:  0x870xec0xe80x190xeb0xec0xa3
> 0xf1
>
> 0x808c858:  0x780x570xa70x1b0xfb0x0b0xba
> 0x2b
>
> 0x808c860:  0xce0x0c0xb40x630xd60xc00x46
> 0xa8
>
> 0x808c868:  0x890x060xec0x160x8a0xf50x16
> 0x2c
>
> 0x808c870:  0xf40xeb0xb10xa00x640x070xc6
> 0x9b
>
> 0x808c878:  0x290x240x230xe80x350xcf0xca
> 0x79
>
> 0x808c880:  0xd50x5a0x2f0x7e0x7d0x240x8d
> 0x7b
>
> 0x808c888:  0x080x560x0f0xf80x590x990xe6
> 0xfc
>
>
>
>
> signature sent from QNX machine to the linux machine in the IKE_AUTH
> message:-
>
> (gdb) x/12b signature.ptr
>
> 0x808c890:  0xe70x530xd30x870x8b0x160xe2
> 0xda
>
> 0x808c898:  0x650x230xe30x45
>
>
>
>
>
> Here's the log on the Linux machine of the IKE_AUTH request received
> from QNX machine:-
>
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET] received IPv4 packet => 252
> bytes @ 0xb5553e04
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]0: 45 00 00 FC 0B 1C 00
> 00 40 11 B6 62 0A 76 D1 BA  e...@..b.v..
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   16: 0A 76 D1 CC 11 94 11
> 94 00 E8 63 47 00 00 00 00  .vcG
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   32: 67 41 C8 E9 B4 1F 51
> 61 8C 41 A5 41 49 A0 5B 21  gAQa.A.AI.[!
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   48: 2E 20 23 08 00 00 00
> 01 00 00 00 DC 23 00 00 C0  . #.#...
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   64: 9F 80 D5 48 14 85 2A
> E0 21 5B 30 68 D3 F1 E6 FF  ...H..*.![0h
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   80: A4 41 FA 03 53 6C 9A
> E9 55 CE 4B 32 89 04 27 C3  .A..Sl..U.K2..'.
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   96: 27 08 1D F5 88 2B 60
> D1 C7 74 E6 4E 13 47 06 F7  '+`..t.N.G..
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  112: DF FE B8 85 C1 30 65
> 91 3E EF 12 CE DA 07 7D D6  .0e.>.}.
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  128: 1A 9C FE 28 84 42 A8
> 43 D1 90 09 BE 2D F3 61 8A  ...(.B.C-.a.
>
> Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  144: 3C F5 A7 45 45 39 01
> 1B 80 11 D5 7B AD 

Re: [strongSwan] Some problems with charon

2009-09-03 Thread Martin Willi
Hi,

> received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built

Your peer does not like the proposal you offer. Have you included the
belt cipher in your peers proposal, too?

Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


Re: [strongSwan] IPv4 only and minimal kernel modules

2009-09-03 Thread Martin Willi
Hi,

> 1) upgrade to kernel 2.6.29 and apply patch [1] from above, to the linux 
> kernel.

No, 2.6.29 already contains the patch.

> 2) stick with kernel 2.6.28 and apply the disable-iaf-tunnels patch to 
> charon, (this patch will brake v6/v4 mixed operation)

Yes, then no kernel patch is required.

3) Apply the patch [1] to your 2.6.28 kernel. No userland patch
required.


Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


[strongSwan] Signature verification failed

2009-09-03 Thread vivek bairathi
Hi,

Thanks for your reply.

I am trying to establish SA between two machines of which one is QNX
machine and the other is Linux machine. I am able to transmit the
IKE_SA_INIT request and response messages from one machine to another
but when IKE_AUTH request is received by any of the machine it says
that the "signature verification failed".

Here are the logs of IKE_AUTH request message sent from QNX machine to
linux machine:-

IKE_AUTH request message sent by QNX machine:-

(gdb) x/208b data.ptr

0x808c7c0:  0x670x410xc80xe90xb40x1f0x510x61

0x808c7c8:  0x8c0x410xa50x410x490xa00x5b0x21

0x808c7d0:  0x2e0x200x230x080x000x000x000x01

0x808c7d8:  0x000x000x000xdc0x230x000x000xc0

0x808c7e0:  0x9f0x800xd50x480x140x850x2a0xe0

0x808c7e8:  0x210x5b0x300x680xd30xf10xe60xff

0x808c7f0:  0xa40x410xfa0x030x530x6c0x9a0xe9

0x808c7f8:  0x550xce0x4b0x320x890x040x270xc3

0x808c800:  0x270x080x1d0xf50x880x2b0x600xd1

0x808c808:  0xc70x740xe60x4e0x130x470x060xf7

0x808c810:  0xdf0xfe0xb80x850xc10x300x650x91

0x808c818:  0x3e0xef0x120xce0xda0x070x7d0xd6

0x808c820:  0x1a0x9c0xfe0x280x840x420xa80x43

0x808c828:  0xd10x900x090xbe0x2d0xf30x610x8a

0x808c830:  0x3c0xf50xa70x450x450x390x010x1b

0x808c838:  0x800x110xd50x7b0xad0x5c0x090xef

0x808c840:  0xd10x070xab0x330x450xd80xeb0x9c

0x808c848:  0xe10xb30xc00xe80x830xb10x010x1f

0x808c850:  0x870xec0xe80x190xeb0xec0xa30xf1

0x808c858:  0x780x570xa70x1b0xfb0x0b0xba0x2b

0x808c860:  0xce0x0c0xb40x630xd60xc00x460xa8

0x808c868:  0x890x060xec0x160x8a0xf50x160x2c

0x808c870:  0xf40xeb0xb10xa00x640x070xc60x9b

0x808c878:  0x290x240x230xe80x350xcf0xca0x79

0x808c880:  0xd50x5a0x2f0x7e0x7d0x240x8d0x7b

0x808c888:  0x080x560x0f0xf80x590x990xe60xfc




signature sent from QNX machine to the linux machine in the IKE_AUTH message:-

(gdb) x/12b signature.ptr

0x808c890:  0xe70x530xd30x870x8b0x160xe20xda

0x808c898:  0x650x230xe30x45





Here's the log on the Linux machine of the IKE_AUTH request received
from QNX machine:-


Sep  3 00:00:21 ggn-pg-001 charon: 07[NET] received IPv4 packet => 252
bytes @ 0xb5553e04

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]0: 45 00 00 FC 0B 1C 00
00 40 11 B6 62 0A 76 D1 BA  e...@..b.v..

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   16: 0A 76 D1 CC 11 94 11
94 00 E8 63 47 00 00 00 00  .vcG

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   32: 67 41 C8 E9 B4 1F 51
61 8C 41 A5 41 49 A0 5B 21  gAQa.A.AI.[!

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   48: 2E 20 23 08 00 00 00
01 00 00 00 DC 23 00 00 C0  . #.#...

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   64: 9F 80 D5 48 14 85 2A
E0 21 5B 30 68 D3 F1 E6 FF  ...H..*.![0h

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   80: A4 41 FA 03 53 6C 9A
E9 55 CE 4B 32 89 04 27 C3  .A..Sl..U.K2..'.

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]   96: 27 08 1D F5 88 2B 60
D1 C7 74 E6 4E 13 47 06 F7  '+`..t.N.G..

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  112: DF FE B8 85 C1 30 65
91 3E EF 12 CE DA 07 7D D6  .0e.>.}.

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  128: 1A 9C FE 28 84 42 A8
43 D1 90 09 BE 2D F3 61 8A  ...(.B.C-.a.

Sep  3 00:00:21 ggn-pg-001 charon: 07[NET]  144: 3C F5 A7 45 45 39 01
1B 80 11 D5 7B AD 5C 09 EF  <..EE9.{.\..

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  160: D1 07 AB 33 45 D8 EB
9C E1 B3 C0 E8 83 B1 01 1F  ...3E...

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  176: 87 EC E8 19 EB EC A3
F1 78 57 A7 1B FB 0B BA 2B  xW.+

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  192: CE 0C B4 63 D6 C0 46
A8 89 06 EC 16 8A F5 16 2C  ...c..F,

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  208: F4 EB B1 A0 64 07 C6
9B 29 24 23 E8 35 CF CA 79  d...)$#.5..y

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  224: D5 5A 2F 7E 7D 24 8D
7B 08 56 0F F8 59 99 E6 FC  .Z/~}$.{.V..Y...

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET]  240: E7 53 D3 87 8B 16 E2
DA 65 23 E3 45  .S..e#.E

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET] received packet: from
10.118.209.186[4500] to 10.118.209.204[4500]

Sep  3 00:00:23 ggn-pg-001 charon: 07[NET] waiting for data on raw sockets

Sep  3 00

Re: [strongSwan] does strongSwan support Solaris

2009-09-03 Thread Andreas Steffen
ZHi Roger,

strongSwan team member Tobias Brunner is currently working on the
OpenSolaris port.

Regards

Andreas

hang, Long (Roger) wrote:
> Hi,
> 
> I see strongSwan has been ported to support FreeBSD, seems like it is
> not supported on Solaris. Is there a plan to port it to Solaris?
> 
> Thanks, Roger

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org

Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users