[Openswan Users] Cannot make openswan working...

Thu May 1 14:50:33 EDT 2008

>> Okey, the problems seems to be solved... partially! I added
>> leftnexthop=x2.x2.x2.x2 The server network interfaces are: eth0:
>> x2.x2.x2.x2 - external interface with real IP
>>     
> I still don't understand your setup. The server has a leftnexthop
> to its own network interface?
>   
Actually, yes... Is this not good? I do not understand well what 
leftnexthop is for as far as I'm new to Openswan...

Let me describe by server in details once again (real "world" IP 
addresses are replaced for privacy):

eth0: 68.68.44.42 (net 68.68.44.0/24; external gw 68.68.44.41)
eth1: 68.68.12.1 (net 68.68.12.0/24)
eth1:0-2 (virtual interfaces): 192.168.0.1 (192.168.0.0/20); 10.44.68.1 
(10.44.68.0/24) and 172.27.172.1 (172.27.172.0/24)
ipsec0 (=eth1): 68.68.12.1 (net 68.68.12.0/24)

eth0 is external interface connected to our ISP. eth1 is internal 
interface which does have real world IP addresses.

Openswan listens to 68.68.12.1. L2TP server also listens to 68.68.12.1.

What value should be for leftnexthop? I don't know which should be but 
with the current value (68.68.44.42) IPSec works just fine.
> What is it exactly that you want to achieve? Allow VPN users in
> from the Internet to the internal network? Allow VPN users on
> the internal (possibly untrusted such as wireless?) network out
> to the Internet?
>   
Ideally I want both... But currently I want to have VPN for external 
(from Internet) users.
>> eth1: x.x.x.x - internal interface with real IP and networks:
>>     
> The internal interface has a real world IP address?
>   
Right! 68.68.12.1 from the config above.
>> Packets arriving to L2TPd server on ipsec0 visually go from client's router
>> real IP (y.y.y.y) and port 1701 and go to x.x.x.x:1701. They are leaving
>> the server from interface eth0. I can understand why they do...
>>     
> L2TP packets should not leave the server unencrypted unless you
> explicitly forward them to some other L2TP server (which is rare).
>   
I do know this... But they do.

As I understand L2TP packets go to the server through IPSec. There they 
are decrypted and transfered to L2TP server through ipsec0 interface 
(and I do see them there).

The problem is that they are leaving the server (the response actually) 
from eth0. This is actually correct because the default route points to 
68.68.44.41 (that is to interface eth0). And therefore (I guess) they 
are not encrypted. They should be leaving the server from ipsec0, right?

Here is tcpdump:

Packets arriving to ipsec0:

1:33:57.905681 IP 92.30.44.50.1701 > 68.68.12.1.1701:  
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) 
*BEARER_CAP() |...
21:33:58.920239 IP 92.30.44.50.1701 > 68.68.12.1.1701:  
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) 
*BEARER_CAP() |...
21:34:00.908124 IP 92.30.44.50.1701 > 68.68.12.1.1701:  
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) 
*BEARER_CAP() |...

Packets leaving from eth0:

21:33:57.906384 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *BEARER_CAP() |...
21:33:58.912664 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *BEARER_CAP() |...
21:33:58.920973 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 ZLB
21:33:59.920664 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *BEARER_CAP() |...
21:34:00.908905 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 ZLB
21:34:00.928642 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *BEARER_CAP() |...
21:34:01.936666 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *BEARER_CAP() |...
21:34:02.944765 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(36263) 
*RESULT_CODE(1/0 Timeout)
21:34:03.952657 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(36263) 
*RESULT_CODE(1/0 Timeout)
21:34:04.922763 IP 68.68.12.1.1701 > 92.30.44.50.1701:  
l2tp:[TLS](51/0)Ns=0,Nr=1 ZLB

Currently I think about playing with iproute/iptables to make packets 
leave from ipsec0 (changing route for them)...
>> PPTP (as an alternative to IPSec/L2TP) can be used in local network for
>> providing Internet access (like PPPoE). In this case the client connects
>> from the zone which is actually used on the server. So I wonder if
>> IPSec/L2TP can be used as VPN over Ethernet
>>     
> I don't know what you mean exactly, but L2TP/IPsec can do the same
> things as PPTP.
>   
Actually here I was wondering if it is possible to have the following:

VPN client (eg, 192.168.0.25, that is eth1) -> VPN server (68.68.12.1, 
also eth1)
In this case the client would get some special IP (eg, 10.44.68.25) 
through L2TP/PPP and will be able to use Internet through this new 
channel. Seems this is possible.

Here are my updated configs:

ipsec.conf:

version 2.0

config setup
    nat_traversal=yes
    interfaces=ipsec0=eth1
    rp_filter=0
    syslog=local6.info
    dumpdir=/etc/ipsec.d

virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.44.68.0/24,%v4:!192.168.0.0/20,%v4:!172.27.172.0/24
    strictcrlpolicy=yes

conn nung-server
    type=tunnel
    left=68.68.12.1
    leftnexthop=68.68.44.42
    leftcert=ipsec-cert.pem
    right=%any
    rightsubnet=vhost:%no,%priv
    rightrsasigkey=%cert
    leftprotoport=17/1701
    rightprotoport=17/1701
    authby=rsasig
    keyingtries=3
    pfs=no
    auto=add
    rekey=no

# Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

l2tpd.conf:

[global]
listen-addr = 68.68.12.1
port = 1701
auth file = /etc/l2tpd/l2tp-secrets
rand source = dev

[lns default]
exclusive = no
ip range = 10.44.68.3-10.44.68.254
local ip = 10.44.68.2
require chap = yes
refuse pap = yes
require authentication = yes
name = base.domain
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

I guess there is no problem with Openswan/IPSec for now... Currently I 
have a problem with L2TP...

Thanks,
Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080501/fff5f6af/attachment.html 