[Openswan Users] but no connection has been authorized with policy=PSK

[Thomas Schweikle]

Am 12.04.2011 01:52, schrieb Willie Gillespie:
> On 4/11/2011 2:56 PM, Thomas Schweikle wrote:
>> Am 11.04.2011 22:43, schrieb Paul Wouters:
>>> On Mon, 11 Apr 2011, Thomas Schweikle wrote:
>>>
>>>> packet from ww.xx.yy.zz:61986: initial\
>>>>   Main Mode message received on 222.66.77.27:500 but no connection
>>>> has been authorized with policy=PSK
>>>
>>> You wrote before:
>>>
>>>           # LOCAL
>>>           leftid=          @rz
>>>           left=            222.66.77.27
>>>           leftnexthop=     222.66.77.1
>>>           leftsubnet=      192.168.180.0/23
>>>           #
>>>           # REMOTE
>>>           rightid=         @openswan
>>>           right=           192.168.1.4
>>>           rightnexthop=    192.168.1.1
>>>           rightsubnet=     192.168.1.0/24
>>>
>>>
>>> Clearly ww.xx.yy.zz is not matching 192.168.1.4, or it is not using "openswan" as its id.
>>
>> Hmmm. My setup is as:
>>
>> openswan (192.168.1.4) -->  router/nat (with unknown IP, since it
>> changes every day once --- this is ww.xx.yy.zz) -->  RZ
>> (222.66.77.27) -->  Inside (192.168.180.27)
>>
>> on the server side:
>>          leftid=          @rz
>>          left=            222.66.77.27
>>          leftnexthop=     222.66.77.1
>>          leftsubnet=      192.168.180.0/23
>>          #
>>          # REMOTE
>>          rightid=         @openswan
>>          right=           192.168.1.4
>>          rightnexthop=    192.168.1.1
>>          rightsubnet=     192.168.1.0/24
>>
>>
>> on the client side:
>>          leftid=          @openswan
>>          left=            192.168.1.4
>>          leftnexthop=     192.168.1.1
>>          leftsubnet=      192.168.1.0/24
>>          #
>>          # REMOTE
>>          rightid=         @rz
>>          right=           222.66.77.27
>>          rightnexthop=    222.66.77.1
>>          rightsubnet=     192.168.180.0/23
>>
>> I had to switch left and right for the client, because if I left it
>> as it was (two identical config-files), I did not even see
>> connection attempts.
> 
> Okay, jumping in here.
> 
> The client side (@openswan side) looks okay.  The left needs to be an 
> address on that machine.  It is: 192.168.1.4, so that's good.
> 
> However, on the server side (@rz side), it sees the packets coming from 
> ww.xx.yy.zz, so that's what it needs defined in the connection.  Not 
> 192.168.1.4.  Unfortunately for you, it changes every day, so you are in 
> the same situation as a road-warrior configuration, where you may have 
> to use %any for right= on the @rz side of things.

I Had this setup, but searching for an other problem I have kicked
it out, producing other errors...  -.-

OK. This error is gone now. The tunnel seems to be established after
restarting daemons on both machines. But:

on the client:
# ping 192.168.180.27
PING 192.168.180.27 (192.168.180.27) 56(84) bytes of data.
64 bytes from 192.168.180.27: icmp_req=1 ttl=64 time=29.6 ms
64 bytes from 192.168.180.27: icmp_req=2 ttl=64 time=27.9 ms
^C
--- 192.168.180.27 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 27.991/28.820/29.650/0.846 ms

on the server:
$ ping 192.168.1.4
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
^C
--- 192.168.1.4 ping statistics ---
67 packets transmitted, 0 received, 100% packet loss, time 66007ms

Packets from client to server are OK, but not the other way round :-(

But even if only the client can start a connection, I need a
transparent tunnel between both! On any system within both subnets
I'd like to just ping any host. It shouldn't mater where they are
located.

I am testing with subnets:
192.168.180.0/23
192.168.1.0/24


-- 
Thomas