[Openswan Users] L2TP using wrong connection
Matthias Haas
mh at pompase.net
Fri Apr 1 16:30:29 CEST 2005
Hello Jacco,
I did some additional testing and found out that this problem is unrelated
to L2TP connections.
I configured a normal vpn connection like this:
server ipsec.conf:
version 2
config setup
plutowait=no
uniqueids=yes
nat_traversal=yes
overridemtu=1418
interfaces="ipsec0=eth0"
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
conn client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0
leftsubnet=192.168.20.0/255.255.255.0
left=192.168.0.204
leftnexthop=%direct
right=%any
authby=rsasig
leftcert=/etc/ipsec.d/server.crt
leftsendcert=yes
auto=add
auth=esp
pfs=yes
keylife=9h
keyingtries=3
ikelifetime=6h
disablearrivalcheck=no
rightcert=/etc/ipsec.d/client-1-Empty_EmptyCert.crt
conn client_1-OK_OKCert_gw-gw_192.168.0.204-0.0.0.0
left=192.168.0.204
leftnexthop=%direct
right=%any
type=tunnel
authby=rsasig
leftcert=/etc/ipsec.d/server.crt
leftsendcert=yes
auto=add
auth=esp
pfs=yes
keylife=9h
keyingtries=3
ikelifetime=6h
disablearrivalcheck=no
rightcert=/etc/ipsec.d/client-1-OK_OKCert.crt
client ipsec.conf:
version 2
config setup
plutowait=no
uniqueids=yes
nat_traversal=yes
overridemtu=1418
interfaces="ipsec0=eth0"
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
conn server_1-test_gw-sn_192.168.0.242-192.168.20.0_24
left=192.168.0.242
leftnexthop=%direct
right=192.168.0.204
rightsubnet=192.168.20.0/255.255.255.0
authby=rsasig
leftcert=/etc/ipsec.d/server.crt
leftsendcert=yes
auto=start
auth=esp
pfs=yes
keylife=9h
keyingtries=0
ikelifetime=6h
disablearrivalcheck=no
rightcert=/etc/ipsec.d/server-1-test.crt
Where OKCert is a valid certificate and EmptyCert is simply an empty file.
The syslog output looks like this:
Server syslog:
pluto[29983]: packet from 192.168.0.242:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03]
pluto[29983]: packet from 192.168.0.242:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 108
pluto[29983]: packet from 192.168.0.242:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-00]
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: responding to Main Mode from unknown peer 192.168.0.242
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: transition from state (null) to state STATE_MAIN_R1
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: transition from state STATE_MAIN_R1 to state
STATE_MAIN_R2
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: Peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Bayern, L=Augsburg,
OU=Technik, CN=VPN, E=vpn at test.de'
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: issuer cacert not found
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[1]
192.168.0.242 #1: X.509 certificate rejected
pluto[29983]: "client_1-OK_OKCert_gw-gw_192.168.0.204-0.0.0.0"[1]
192.168.0.242 #1: deleting connection
"client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0" instance with
peer 192.168.0.242 {isak
mp=#0/ipsec=#0}
pluto[29983]: "client_1-OK_OKCert_gw-gw_192.168.0.204-0.0.0.0"[1]
192.168.0.242 #1: transition from state STATE_MAIN_R2 to state
STATE_MAIN_R3
pluto[29983]: "client_1-OK_OKCert_gw-gw_192.168.0.204-0.0.0.0"[1]
192.168.0.242 #1: sent MR3, ISAKMP SA established
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[2]
192.168.0.242 #2: responding to Quick Mode
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[2]
192.168.0.242 #2: transition from state (null) to state STATE_QUICK_R1
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[2]
192.168.0.242 #2: transition from state STATE_QUICK_R1 to state
STATE_QUICK_R2
pluto[29983]: "client_1-Empty_EmptyCert_sn-gw_192.168.20.0_24-0.0.0.0"[2]
192.168.0.242 #2: IPsec SA established {ESP=>0xe7d11e6e <0xa91496f4}
As you can see at first it uses the connection with the correct
certificate, but the wrong connection settings up to ISAKMP is
established. After that the connection with the correct connection
settings (subnet) is used to establish the connection with the empty cert.
This is I think a security issue as it is not assured by any ipsec process
that this file is not world writebale and noone is able to empty an
existing cert to use it as a wildcard connection.
> Matthias Haas wrote:
>
>> I am using openswan 2.1.4. The problem I have is that I have configured
>> some L2TP connections. They differ in the type of connections I allow.
>> One
>> connection is configured using the leftsubnetwithin parameter which
>> should
>> not work with l2tp. The other one is a l2tp connection configured
>> correctly to be used for l2tp.
>
> I suggest you post your ipsec.conf.
>
>> The first connection has a valid certificate. The second one references
>> a empty file.
>
> An empty certificate file? You mean it is 0 bytes? Sounds odd to me.
> What do you hope to achieve with this?
In my case the config files and certificates are generated and therefore
the cert files can be empty. As long as there is no valid certificate in
the file it has the same effect. This means it must not ba empty. It is
sufficient to have just a broken certificate to make the associated
connection a wildcarded one. I think this increases the level of threat to
this issue.
>
> Jacco
cu
Matthias
More information about the Users
mailing list