[Openswan Users]

[Paul Wouters]

On Tue, 16 May 2006, Rodrigo Weymar Fonseca wrote:

> I am not sure if the problem is due to a potential right/left subnets
> misconfiguration in the ipsec.conf or if it is a NAT-T problem. I also adjusted
> the IPSec policies in the ASL V5 server to match those of the client. One
> limitation of ASL Version 5.0 is the IKE algorithm. It does not support
> 3DES_CBC_192 as used by the client, but 3DES-CBC 168 bits. Could it be a problem?

> 000 "road":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 32,32; interface: eth0;
> 000 "road":   newest ISAKMP SA: #5; newest IPsec SA: #0;
> 000 "road":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536

> 192.168.1.122:4500 #194: sent MR3, ISAKMP SA established
> 2006:05:16-10:22:37 firewall pluto[23491]: "D_suse10__vpn__test_0"[1]
> 192.168.1.122:4500 #195: IPsec Transform [ESP_AES (128),
> AUTH_ALGORITHM_HMAC_SHA1] refused due to strict flag
> 2006:05:16-10:22:37 firewall pluto[23491]: "D_suse10__vpn__test_0"[1]

> conn road
>          left=192.168.1.122             # Picks up our dynamic IP
>          #leftsubnet=192.168.1.0/24
>          #leftnexthop=192.168.1.1
>          leftid=@suse10.domain.de       # Local information
>          leftrsasigkey=0sAQ...
>          #rightnexthop=192.168.1.1
>          right=xxx.yyy.16.19            # Remote information
>          rightid=@firewall.domain.de
>          rightrsasigkey=0sAQN7...
>          auto=add                       # authorizes but doesn't start this

I am not sure why a proposal is not found. One would say that it should,
unless the ASL has a very strange non-standard entry in their esp= line.
Unfortunately, you did not tell us the ASL esp= line. It seems that you
are worried about 3DES variations, while your client is told it can not
do AES. I am not sure why it then would not try 3des though, it should,
unless the config files and the logfiles are not in fact belonging together.

Perhaps try adding to your client:  esp=3des-md5-modp1568

Paul