[Openswan Users] R: R: R: Multiple interfaces ipsec/l2tp vpn openswan 2.6.26 [SOLVED not at all]

Wed Jul 7 03:06:59 EDT 2010

Indeed now there is another problem:
L2TP/IPSEC connection through HDSL does not work when client is nated.
Instead it works fine on ADSL (default vpn/firewall route).

This is auth.log:

Jul  6 23:17:56 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
responding to Main Mode from unknown peer 109.52.142.29
Jul  6 23:17:56 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul  6 23:17:56 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
STATE_MAIN_R1: sent MR1, expecting MI2
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
STATE_MAIN_R2: sent MR2, expecting MI3
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492: Main
mode peer ID is ID_FQDN: '@pc1.domain.ext'
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[17] 109.52.142.29 #492:
switched from "L2TP-PSK" to "L2TP-PSK"
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
deleting connection "L2TP-PSK" instance with peer 109.52.142.29
{isakmp=#0/ipsec=#0}
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492: new
NAT mapping for #492, was 109.52.142.29:61227, now 109.52.142.29:61228
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492: peer
client type is FQDN
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
Applying workaround for MS-818043 NAT-T bug
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492: IDci
was FQDN: X*\340\316, using NAT_OA=192.168.0.127/32 as IDci
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492: the
peer proposed: x.y.z.206/32:17/1701 -> 192.168.0.127/32:17/0
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
responding to Quick Mode proposal {msgid:1384238b}
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
us: x.y.z.206/32===x.y.z.206<x.y.z.206>[+S=C]:17/1701---x.y.z.193
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
them: 109.52.142.29[@pc1.domain.ext,+S=C]:17/1701===192.168.0.127/32
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
route-host output:
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jul  6 23:17:57 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #493:
STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x3ecdcc9b
<0xa43b3052 xfrm=3DES_0-HMAC_MD5 NATOA=192.168.0.127
NATD=109.52.142.29:61228 DPD=none}

Jul  6 23:18:32 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
received Delete SA(0x3ecdcc9b) payload: deleting IPSEC State #493

Jul  6 23:18:32 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete
included errno 2: No such file or directory
Jul  6 23:18:32 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
unroute-host output: 
Jul  6 23:18:32 multifw pluto[4948]: "L2TP-PSK"[18] 109.52.142.29 #492:
received and ignored informational message

As you can see in highlighted line #492 after SA established... 
Everything seems ok... at that point (as in adsl conn) butt.. "Delete SA" is
received... don't know why! :(
FV

-----Messaggio originale-----
Da: Tuomo Soini [mailto:tis at foobar.fi] 
Inviato: mercoledì 30 giugno 2010 11:02
A: Paul Wouters
Cc: Federico Viel; 'Willie Gillespie'; users at openswan.org
Oggetto: Re: R: [Openswan Users] R: Multiple interfaces ipsec/l2tp vpn
openswan 2.6.26 [SOLVED]

Paul Wouters wrote:
> On Tue, 29 Jun 2010, Federico Viel wrote:
> 
>> This is(was) the problem
> 
> I'll wait on Tuomo's comments here. He knows this magic best....
> 
> Paul
> 
>>
>> On
>> /usr/lib/ipsec/_updown.netkey
>> .....
>> 1    # old: route via pluto_interface
>> 2    # parms2="$parms2 dev ${PLUTO_INTERFACE%:*} $IPROUTEARGS"
>> 3
>> 4    # new: route via proper interface according to routing table
>> 5    if [ "$1" = "del" ]; then
>> 6       PLUTO_PEER_INTERFACE=`ip -o route get $PLUTO_PEER_CLIENT | sed
>> "s/^.*de$
>> 7    else
>> 8       PLUTO_PEER_INTERFACE=`ip -o route get $PLUTO_PEER | sed "s/^.*dev
>> \([^ $
>> 9    fi
>> 10   if [ -z "$PLUTO_PEER_INTERFACE" ]; then
>> 11        PLUTO_PEER_INTERFACE=$PLUTO_INTERFACE
>> 12    fi
>> 13    parms2="$parms2 dev ${PLUTO_PEER_INTERFACE%:*} $IPROUTEARGS"
>> ...
>>
>>
>> Commenting lines 5,6,7,8,9 solved the problem.
>>
>>
>>
>> Maybe this is a "issue" to fix? (in openswan 2.4.6 _updown script works
>> fine)
>>
>> The question now is: Why net2net connections work without this patch?
>> Thank you.
>>

This was a change which was done to force route via correct interface.
That means your routig configuration is not correct if this doesn't
work. Routing should always point to same interface packet arrived from.
I use shorewall based multi-isp setup and this works ok there, Shorewall
das packet marking trickery to make sure route out is via same interface
initial contact was from.

--
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>