[Openswan Users] %defaultroute and %any

Wed Aug 9 06:21:05 EDT 2006

On Wed, 2006-08-09 at 16:50 +0200, Paul Wouters wrote:
> On Wed, 9 Aug 2006, Andy Gay wrote:
> 
> > > You cannot use both %defaultroute and %any, because then openswan
> > > cannot determine if it is left or right.
> >
> > You sure? I use that on a few systems, works OK.
> >
> > Quote from ipsec.conf(5):
> > "If  it  is %defaultroute, and the config setup section's, interfaces
> > specification contains %defaultroute, left will be filled in
> > automatically with the local address of the default-route interface (as
> > determined at IPsec startup time)"
> 
> Show me an "ipsec auto --replace conn" of such a connection :)
> 
OK:

# ipsec --version
Linux Openswan U2.4.6/K2.6.17.7 (netkey)
See `ipsec --copyright' for copyright information.

# cat /etc/ipsec.conf

version 2.0     # conforms to second version of ipsec.conf specification

config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        dumpdir=/home/tmp
        nhelpers=0
        plutoopts="--interface eth1"
        nat_traversal=yes
        forwardcontrol=yes

conn %default
        left=%defaultroute
        leftnexthop=%defaultroute
        leftsubnet=10.242.9.0/24
        leftsourceip=10.242.9.1

include /etc/ipsec.d/*.conf

# cat /etc/ipsec.d/tnj.conf
conn tnj
        authby=rsasig
        leftcert=hchent.pem
        leftupdown="/etc/ipsec.d/scripts/m-updown 1396"
        right=%any
        rightid="<snipped>"
        rightrsasigkey=%cert
        rightsubnet=10.242.42.0/24
        rekey=no
        auto=add

# ipsec auto --replace tnj
#

/var/log/auth.log:

Aug  9 11:05:19 fwri pluto[330]: "tnj": deleting connection
Aug  9 11:05:19 fwri pluto[330]:   loaded host cert file '/etc/ipsec.d/certs/hchent.pem' (3095 bytes)
Aug  9 11:05:19 fwri pluto[330]: added connection description "tnj"
Aug  9 11:05:19 fwri pluto[330]: packet from 70.18.162.156:500: Informational Exchange is for an unknown (expired?) SA
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: ignoring unknown Vendor ID payload [4f456e4d43757f784f704063]
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [Dead Peer Detection]
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [RFC 3947] method set to=110 
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Aug  9 11:05:28 fwri pluto[330]: packet from 70.18.162.156:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: responding to Main Mode from unknown peer 70.18.162.156
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: STATE_MAIN_R1: sent MR1, expecting MI2
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: NAT-Traversal: Result using 3: no NAT detected
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: STATE_MAIN_R2: sent MR2, expecting MI3
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: Main mode peer ID is ID_DER_ASN1_DN: '<snipped>'
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: I am sending my cert
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #170: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #171: responding to Quick Mode {msgid:24803ed4}
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #171: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Aug  9 11:05:28 fwri pluto[330]: "tnj"[1] 70.18.162.156 #171: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Aug  9 11:05:29 fwri pluto[330]: "tnj"[1] 70.18.162.156 #171: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug  9 11:05:29 fwri pluto[330]: "tnj"[1] 70.18.162.156 #171: STATE_QUICK_R2: IPsec SA established {ESP=>0x21b674e6 <0x2fda48b6 xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}

# ipsec auto --status
 ...
000 "tnj"[1]: 10.242.9.0/24===<left public IP>[<ID snipped>]---<left default GW>...70.18.162.156[<ID snipped>]===10.242.42.0/24; erouted; eroute owner: #171

 ...

> the problem is not grabbing a local IP address. The problem is how can
> pluto know that it is the "server" or "client" in such a connection.
> 
Not sure what you mean by that. If right=%any we can't initiate, so we
must be a responder. Using your terminology that means we have to be a
"server", I would think.

> Paul
> -- 
> Building and integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> 