[Swan] dev lo route error
Philippe Vouters
philippe.vouters at laposte.net
Mon Jan 7 22:35:07 EET 2013
It seems there is another bug with pluto loading the first file and
missing the other files:
[philippe at victor libreswan]$ sudo /usr/local/sbin/ipsec addconn
--verbose --autoall
opening file: /etc/ipsec.conf
debugging mode enabled
including file '/etc/ipsec.d/ipsec.*.conf'(/etc/ipsec.d/ipsec.*.conf)
from line /etc/ipsec.conf:36
Loading default conn
starter: case KH_NOTSET: empty
starter: case KH_NOTSET: empty
Loading conn david
loading all conns according to their auto= settings
Pass #1: Loading auto=add and auto=route connections
Pass #2: Loading auto=start connections
So addcon does not consider your /etc/ipsec.d/ipsec.unmanaged.mumin.conf
and
/etc/ipsec.d/ipsec.unmanaged.paulin.conf
and misses conf mumin and conn paulin
[philippe at victor ~]$ sudo su -c 'ls /etc/ipsec.d/'
X9000.conf.save index.txt keys private
aacerts ipsec.secrets mykey.txt reqs
cacerts ipsec.secrets.old newcerts secmod.db
cert8.db ipsec.secrets.save nsspassword serial
cert9.db ipsec.unmanaged.david.conf ocspcerts server.p12
certs ipsec.unmanaged.mumin.conf passwd tempcert
crls ipsec.unmanaged.paulin.conf pkcs11.txt tempcertreq
examples key3.db pkcs12 vouters.conf.shrew
hp.conf.save key4.db policies vouters.conf.xl2tpd
Note that in conn david:
# left=howitts.poweredbyclear.com
# is illegal as per ipsec.conf
# valid: left=<IPv4 or IPv6 address>
If someone proves above is legal with Openswan 2.6.38, then this shall
be considered as a regression.
Shall work onto this multiple conf files not opened problem first.
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org
Le 07/01/2013 20:47, Nick Howitt a écrit :
> Conns attached.
>
> PSK files are confused as we have one psk file per conn so I have (in
> three files):
>
> howitts.poweredbyclear.com 88.98.137.158 : PSK "PSK1"
> @Nick-Mum %any : PSK "PSK2"
> @Nick-Paul %any : PSK "PSK2"
> %any : PSK "PSK2"
> Note last three have the same PSK. The last one is a "spare" one
> floating around which I have not bothered disabling.
>
> Nick
>
> On 07/01/2013 19:06, Philippe Vouters wrote:
>>
>> Can you provide your full configuration including everything ? Best
>> reply to me with your files attached to your reply.
>>
>> Philippe Vouters (Fontainebleau/France)
>> URL: http://vouters.dyndns.org/
>> SIP: sip:Vouters at sip.linphone.org
>>
>> Le 06/01/2013 17:58, Nick Howitt a écrit :
>>> I'm in a bit of a mess here and I cannot get the conn to load at all
>>> to test. Using the command below I get:
>>>
>>> [root at server src]# /usr/libexec/ipsec/addconn --verbose MumIn
>>> opening file: /etc/ipsec.conf
>>> debugging mode enabled
>>> including file
>>> '/etc/ipsec.d/ipsec.*.conf'(/etc/ipsec.d/ipsec.*.conf) from line
>>> /etc/ipsec.conf:36
>>> Loading default conn
>>> starter: case KH_NOTSET: empty
>>> starter: case KH_NOTSET: empty
>>> Loading conn David
>>> starter: check what we need to do for 'howitts.poweredbyclear.com'
>>> starter: ttoaddr_num failed, not numeric 'howitts.poweredbyclear.com'
>>> starter: Resolved to howitts.poweredbyclear.com !
>>> starter: check what we need to do for '88.98.137.158'
>>> loading named conns: MumIn(notfound)[root at server src]#
>>>
>>> The ttoaddr error is coming from another conn (David) which I'm not
>>> trying to load. In that conn David if I change left to %defaultroute
>>> the 3 "howitts.poweredbyclear.com" errors go away but I don't see
>>> why MumIn is not found. My ipsec.conf is:
>>>
>>> version 2.0
>>>
>>> # Default policy
>>> #---------------
>>>
>>> config setup
>>> interfaces=%defaultroute
>>> plutodebug=none
>>> klipsdebug=none
>>> oe=no
>>> protostack=netkey
>>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.2.0/24,%v4:!192.168.3.0/24
>>>
>>>
>>>
>>> conn %default
>>> type=tunnel
>>> authby=secret
>>>
>>> # Tunnels defined in separate files
>>> #----------------------------------
>>>
>>> include /etc/ipsec.d/ipsec.*.conf
>>>
>>> And /etc/ipsec.d/ipsec.unmanaged.MumIn.conf is:
>>>
>>> conn MumIn
>>> type=tunnel
>>> authby=secret
>>> dpdtimeout=120
>>> dpddelay=30
>>> auto=add
>>> left=%defaultroute
>>> leftsourceip=192.168.2.1
>>> leftsubnet=192.168.2.0/24
>>> leftid=@FromNick
>>> right=%any
>>> rightsubnet=192.168.10.0/24
>>> salifetime=1h
>>> dpdaction=restart_by_peer
>>> ikelifetime=8h
>>> ike=aes256
>>> phase2alg=aes256
>>>
>>> Until I can get these errors to clear, I can't try to reproduce the
>>> dev lo route error.
>>>
>>> As a separate question, the command "ipsec secrets" appears to load
>>> secrets as before, but I notice we now get new files in the
>>> installation. Are we forced to use nss now or ipsec.*.secrets still
>>> OK to use.
>>>
>>> This is using your RHEL rpm. Having to roll back to the rival for
>>> the moment
>>>
>>> Regards,
>>>
>>> Nick
>>>
>>> On 04/01/2013 17:26, Paul Wouters wrote:
>>>>
>>>> On 01/04/2013 12:13 PM, Nick Howitt wrote:
>>>>> In Oguz' Yilmaz's case he appears to have a right specified
>>>>> (right=RIGHT_EXT_IP) and a leftnexthop (leftnexthop=LEFT_EXT_GW)
>>>>> rathr
>>>>> than right=%any and no leftnexthop. :(
>>>>
>>>> you can use /usr/libexec/ipsec/addconn --verbose connname to get a
>>>> verbose output that includes the routes we got back for making the
>>>> decision.
>>>>
>>>>> We have hit some minor odd issues - ipsec auto --status does not give
>>>>> any info on phase2alg unless it is specified. It may also fail if
>>>>> it is
>>>>> specified with the hash function e.g. aes256-sha1 but I need to test
>>>>> further and my time for testing is very limited. But this should
>>>>> all be
>>>>> for another thread......
>>>>
>>>> I've filed that as https://bugs.libreswan.org/show_bug.cgi?id=53
>>>> but I also have not had the time yet to look into this.
>>>>
>>>> Paul
>>>>
>>>
>>> _______________________________________________
>>> Swan mailing list
>>> Swan at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>
>>
>
More information about the Swan
mailing list