[Swan] dev lo route error
Philippe Vouters
philippe.vouters at laposte.net
Mon Jan 7 15:47:03 EET 2013
Nick,
I do not know whether this will make a difference with MumIn conn but,
as far as I know, the correct syntax ought to be:
*leftid=@[FromNick]*
instead of
leftid=@FromNick
(see rightid specification inside conn Philippe_XAUTH_PSK_DHCP at
http://vouters.dyndns.org/tima/Linux-Libreswan-Shrew-VPN-Testing_PAM_XAUTH_DHCP_with_Shrew.html)
As far as I am doing tests, David conn should only be an issue if addcon
uses the unbound library. This does NOT seem to be your case.
Provided you rebuild from sources, make sure you read in Makefile.inc:
USE_DNSSEC?=false
instead of the default:
USE_DNSSEC?=true
For this ipsec configuration:
# Mutual PSK
conn Philippe_PSK
authby=secret
also=FIXED_RIGHT_IP
conn FIXED_RIGHT_IP
type=tunnel
pfs=yes
dpddelay=30
dpdtimeout=120
dpdaction=restart
*left=victor.vouters.dyndns.org*
leftnexthop=%defaultroute
leftsubnet=0.0.0.0/0
leftupdown="ipsec _updown --route yes"
right=%any
rightsubnet=vhost:%no,%priv
rekey=no
auto=add
WITHOUT the unbound library, I read:
[philippe at victor libreswan-3.0]$ *sudo /usr/local/sbin/ipsec addconn
--verbose --autoall*
opening file: /etc/ipsec.conf
debugging mode enabled
including file '/etc/ipsec.d/*.conf'(/etc/ipsec.d/*.conf) from line
/etc/ipsec.conf:26
Loading conn Philippe_PSK
while loading conn 'Philippe_PSK' also including 'FIXED_RIGHT_IP'
starter: check what we need to do for 'victor.vouters.dyndns.org'
starter: ttoaddr_num failed, not numeric 'victor.vouters.dyndns.org'
starter: Resolved to victor.vouters.dyndns.org !
Loading conn FIXED_RIGHT_IP
starter: check what we need to do for 'victor.vouters.dyndns.org'
starter: ttoaddr_num failed, not numeric 'victor.vouters.dyndns.org'
*starter: Resolved to victor.vouters.dyndns.org !*
loading all conns according to their auto= settings
Pass #1: Loading auto=add and auto=route connections
*Philippe_PSK*
parse_src = 0, parse_gateway = 1, has_dst = 0
dst via 192.168.1.1 dev eth0 src
set nexthop: 192.168.1.1
dst 169.254.0.0 via dev eth0 src
dst 192.168.1.0 via dev eth0 src 192.168.1.2
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.1 via dev lo src 127.0.0.1
dst 127.255.255.255 via dev lo src 127.0.0.1
dst 192.168.1.0 via dev eth0 src 192.168.1.2
dst 192.168.1.2 via dev eth0 src 192.168.1.2
dst 192.168.1.255 via dev eth0 src 192.168.1.2
022 connection Philippe_PSK must specify host IP address for our side
037 attempt to load incomplete connection
FIXED_RIGHT_IP
parse_src = 0, parse_gateway = 1, has_dst = 0
dst via 192.168.1.1 dev eth0 src
set nexthop: 192.168.1.1
dst 169.254.0.0 via dev eth0 src
dst 192.168.1.0 via dev eth0 src 192.168.1.2
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.0 via dev lo src 127.0.0.1
dst 127.0.0.1 via dev lo src 127.0.0.1
dst 127.255.255.255 via dev lo src 127.0.0.1
dst 192.168.1.0 via dev eth0 src 192.168.1.2
dst 192.168.1.2 via dev eth0 src 192.168.1.2
dst 192.168.1.255 via dev eth0 src 192.168.1.2
022 connection FIXED_RIGHT_IP must specify host IP address for our side
037 attempt to load incomplete connection
Pass #2: Loading auto=start connections
What I do wonder is why I read from above:
022 connection Philippe_PSK must specify host IP address for our side
037 attempt to load incomplete connection
At first glance, they appear meaningless messages as I correctly read
src 192.168.1.2 which victor.vouters.dyndns.org translates to.
I have to do more tests regarding this problem to ensure these messages
are actually harmless.
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org
Le 06/01/2013 20:45, Nick Howitt a écrit :
> Philippe,
>
> ClearOS (maybe RHEL as well) does not normally put anything under
> /usr/local. I have lots of directories under it and olly share has
> anything in it. Paul Wouters in a parallel reply gave me the other
> command. I've just checked the RHEL rpm and Paul's syntax is correct.
>
> What is curious about the command is why is it even looking at the
> auto=ignore case. It is in a conn called David. As I am trying to load
> a conn called MumIn directly from the command, why is it looking at
> conn David at all?
>
> Nick
>
> On 06/01/2013 19:24, Philippe Vouters wrote:
>> 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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20130107/06f47bb3/attachment.html>
More information about the Swan
mailing list