Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IPSec WinXP interop

6 views
Skip to first unread message

Antony Gelberg

unread,
Dec 23, 2003, 7:50:13 PM12/23/03
to
Hi all,

My first post here - long time d-u subscriber. I'm trying to set up a
VPN where WinXP roadwarriors can access a LAN that sits behind a Linux
router. I want to use X.509 certificates rather than PSKs.

So I've installed freeswan and l2tpd on the router. There is quite a
bit of documentation out there and I have read:
http://www.jacco2.dds.nl/networking/win2000xp-freeswan.html and
http://www.jacco2.dds.nl/networking/freeswan-l2tp.html. Not to mention
http://www.natecarlson.com/linux/ipsec-x509.php.

I'm running Woody, hence:
Package: freeswan
Version: 1.96-1.4
I heard that Woody l2tpd (0.67) wouldn't work, so I downloaded and
built 0.69.

I have created a .p12 certificate, which I have successfully imported
into XP. It's valid. The XP VPN connection is set up properly (e.g.
CHAP on, no PPTP etc.)

But I still can't connect, and I'm sure it's somewhere in the l2tpd/ppp
config that I have a problem. The firewall does run iptables, but I've
disabled it and tried, with the same results. I'm confident that I've
altered the iptables rules as specified in the docs.

Here's some various configs:

mailhost:~# cat /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses
roadwarrior * roadwarrior *

mailhost:~# cat /etc/ipsec.conf
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# More elaborate and more varied sample configurations can be found
# in FreeS/WAN's doc/examples file, and in the HTML documentation.

# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
# Debug-logging controls: "none" for (almost) none, "all" for
# lots.
klipsdebug=all
plutodebug=all
# Use auto= parameters in conn descriptions to control startup
# actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes

# defaults for subsequent connection descriptions
# (mostly to fix internal defaults which, in retrospect, were badly
# chosen)
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert

conn mailhost-rw
left=<firewall public IP>
leftcert=mailhostCert.pem
leftnexthop=<what it says!>
leftsubnet=10.0.0.0/8
right=%any
auto=add
keyingtries=1
pfs=yes

mailhost:~# cat /etc/l2tp/l2tpd.conf
; Sample l2tpd.conf
;
[global]
; listen-addr = 192.168.1.98

[lns default]
ip range = 10.100.100.1-10.100.100.100
local ip = 10.100.100.101
require chap = yes
refuse pap = yes
require authentication = yes
name = VPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

mailhost:~# cat /etc/ppp/options.l2tpd
ipcp-accept-local
ipcp-accept-remote
auth
crtscts
idle 1800
debug
lock
proxyarp
connect-delay 5000

When I try to log in, I get "Error 792: The L2TP connection attempt
failed because security negotiation timed out." I don't get any
"verifying username..." message.

Nothing in /var/log appears to be of much use. There's lots of klips
stuff which is very verbose, but nothing sticks out.

Any insight would be much appreciated. I must admit I'm still a little
unclear how the whole idea works, but I believe that IPSec receives the
connection, then calls l2tpd, which starts ppp. I can post more config
/ debug if needed.

A
--
Documentation - http://www.debian.org/doc/
FAQ - http://www.debian.org/doc/FAQ/
Install manual (i386) - http://www.debian.org/releases/stable/i386/install


--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Jose Luis Domingo Lopez

unread,
Dec 24, 2003, 8:50:25 AM12/24/03
to
On Wednesday, 24 December 2003, at 00:49:31 +0000,
Antony Gelberg wrote:

> When I try to log in, I get "Error 792: The L2TP connection attempt
> failed because security negotiation timed out." I don't get any
> "verifying username..." message.
>

Why do you need freeswan if you are trying to set up L2TP tunnels from
the Windows box to your Linux box ?. FreeS/WAN is an implementation of
the IPsec protocol suite, and as far as I know WXP has support by
default for it, so maybe you could have better luck with this standard
protocol than with the less one L2TP.

> Any insight would be much appreciated. I must admit I'm still a little
> unclear how the whole idea works, but I believe that IPSec receives the
> connection, then calls l2tpd, which starts ppp. I can post more config
> / debug if needed.
>

I could be way mistaken, but L2TP and IPsec (FreeS/WAN and others) are
completely different and independent tunneling mechanisms, and so there
is no mix between them. Configure just L2TP XOR IPsec.

Greetings.

--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0)

Antony Gelberg

unread,
Dec 24, 2003, 3:00:16 PM12/24/03
to
On Wed, Dec 24, 2003 at 01:40:46PM +0100, Jose Luis Domingo Lopez wrote:
> On Wednesday, 24 December 2003, at 00:49:31 +0000,
> Antony Gelberg wrote:
>
> > When I try to log in, I get "Error 792: The L2TP connection attempt
> > failed because security negotiation timed out." I don't get any
> > "verifying username..." message.
> >
> Why do you need freeswan if you are trying to set up L2TP tunnels from
> the Windows box to your Linux box ?. FreeS/WAN is an implementation of
> the IPsec protocol suite, and as far as I know WXP has support by
> default for it, so maybe you could have better luck with this standard
> protocol than with the less one L2TP.

See http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#RemovingL2TP.
I'll quote it:
!Ad 6.6: By default, the IPsec client included with Windows 2000/XP,
!Pocket PC 2003 and MacOS Panther can only be used to tunnel L2TP. You
!might want to get rid of L2TP, so that you don't have to install an L2TP
!daemon on your Linux server. This leaves you with 'plain' IPsec.
!Unfortunately, this is very difficult to do manually.

> > Any insight would be much appreciated. I must admit I'm still a little
> > unclear how the whole idea works, but I believe that IPSec receives the
> > connection, then calls l2tpd, which starts ppp. I can post more config
> > / debug if needed.
> >
> I could be way mistaken, but L2TP and IPsec (FreeS/WAN and others) are
> completely different and independent tunneling mechanisms, and so there
> is no mix between them. Configure just L2TP XOR IPsec.

From http://www.jacco2.dds.nl/networking/win2000xp-freeswan.html:
!As mentioned on one of those webpages, Windows 2000/XP can be configured
!to use IPsec without L2TP. See Nate Carlson's webpage for that. This
!page, however, is about using IPsec with L2TP.

I must admit that I didn't spot this first time around. I'm happy to
get rid of l2tpd and ppp, even though it's frustrating not having got it
to work that way.

It seems that configuring XP to use vanilla IPSec is a pain, see
http://www.snapgear.com/ftp/snapgear/documentation/IPSec/SnapGear_with_Win2k.pdf.
There is a third-party tool available at http://vpn.ebootis.de/ that
takes care of this - I was hoping to avoid any third-party software, but
it looks like it could make my life much easier.

I'll post my findings.

A

--
Now playing: Genesis - Down and Out

cd

unread,
Dec 24, 2003, 11:20:07 PM12/24/03
to
Sorry,

but tunnel ipsec in l2tp is quite normal. You need it to turn around the nat
problem of ipsec.

Valentin Vidic

unread,
Dec 25, 2003, 10:20:17 AM12/25/03
to
On Wed, Dec 24, 2003 at 12:49:31AM +0000, Antony Gelberg wrote:
> My first post here - long time d-u subscriber. I'm trying to set up a
> VPN where WinXP roadwarriors can access a LAN that sits behind a Linux
> router. I want to use X.509 certificates rather than PSKs.

I managed to set up a VPN dial-up connection from Windows Dial-up
Networking to Debian running superfreeswan and l2tpd - so it is
possible to do this (although not too easy). I used l2tpd 0.69-7jdl and
freeswan 1.99.8.

> When I try to log in, I get "Error 792: The L2TP connection attempt
> failed because security negotiation timed out." I don't get any
> "verifying username..." message.

As usual this doesn't tell much. Error messages on the Linux side are
a lot better. Also try monitoring the traffic with tcpdump on different
interfaces (depending on the part of connection you managed to get
working you should either monitor eth0, ipsec0 or ppp0). Try checking
/var/log/auth.log for IPSec messages. A successful connection looks
like this:

pluto[2272]: packet from 10.0.0.100:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000003]
pluto[2272]: "win-vpn"[13] 10.0.0.100 #52: responding to Main Mode from unknown peer 10.0.0.100
pluto[2272]: "win-vpn"[13] 10.0.0.100 #52: Main mode peer ID is ID_DER_ASN1_DN: 'C=HR, L=Zagreb, O=TEST, OU=TEST, CN=vvidic'
pluto[2272]: "win-vpn"[14] 10.0.0.100 #52: sent MR3, ISAKMP SA established
pluto[2272]: "win-vpn"[14] 10.0.0.100 #53: responding to Quick Mode
pluto[2272]: "win-vpn"[14] 10.0.0.100 #53: IPsec SA established

After that take l2tp connection is opened:

l2tpd[18343]: ourtid = 42661, entropy_buf = a6a5
l2tpd[18343]: ourcid = 25187, entropy_buf = 6263
l2tpd[18343]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[18343]: handle_avps: handling avp's for tunnel 42661, call 25187
l2tpd[18343]: message_type_avp: message type 1 (Start-Control-Connection-Request)
l2tpd[18343]: protocol_version_avp: peer is using version 1, revision 0.
l2tpd[18343]: framing_caps_avp: supported peer frames: sync
l2tpd[18343]: bearer_caps_avp: supported peer bearers:
l2tpd[18343]: firmware_rev_avp: peer reports firmware version 1280 (0x0500)
l2tpd[18343]: hostname_avp: peer reports hostname 'no'
l2tpd[18343]: vendor_avp: peer reports vendor 'Microsoft\200^H'
l2tpd[18343]: assigned_tunnel_avp: using peer's tunnel 1
l2tpd[18343]: receive_window_size_avp: peer wants RWS of 8. Will use flow control.
l2tpd[18343]: ourtid = 11890, entropy_buf = 2e72
l2tpd[18343]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[18343]: handle_avps: handling avp's for tunnel 11890, call 1886351988
l2tpd[18343]: message_type_avp: message type 1 (Start-Control-Connection-Request)
l2tpd[18343]: protocol_version_avp: peer is using version 1, revision 0.
l2tpd[18343]: framing_caps_avp: supported peer frames: sync
l2tpd[18343]: bearer_caps_avp: supported peer bearers:
l2tpd[18343]: firmware_rev_avp: peer reports firmware version 1280 (0x0500)
l2tpd[18343]: hostname_avp: peer reports hostname 'no'
l2tpd[18343]: vendor_avp: peer reports vendor 'Microsoft\200^H'
l2tpd[18343]: assigned_tunnel_avp: using peer's tunnel 1
l2tpd[18343]: receive_window_size_avp: peer wants RWS of 8. Will use flow control.
l2tpd[18343]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
l2tpd[18343]: ourtid = 4056, entropy_buf = fd8
l2tpd[18343]: ourcid = 46152, entropy_buf = b448
l2tpd[18343]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[18343]: handle_avps: handling avp's for tunnel 4056, call 46152
l2tpd[18343]: message_type_avp: message type 1 (Start-Control-Connection-Request)
l2tpd[18343]: protocol_version_avp: peer is using version 1, revision 0.
l2tpd[18343]: framing_caps_avp: supported peer frames: sync
l2tpd[18343]: bearer_caps_avp: supported peer bearers:
l2tpd[18343]: firmware_rev_avp: peer reports firmware version 1280 (0x0500)
l2tpd[18343]: hostname_avp: peer reports hostname 'no'
l2tpd[18343]: vendor_avp: peer reports vendor 'Microsoft\200^H'
l2tpd[18343]: assigned_tunnel_avp: using peer's tunnel 1
l2tpd[18343]: receive_window_size_avp: peer wants RWS of 8. Will use flow control.
l2tpd[18343]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
l2tpd[18343]: check_control: control, cid = 0, Ns = 1, Nr = 1
l2tpd[18343]: handle_avps: handling avp's for tunnel 42661, call 25187
l2tpd[18343]: message_type_avp: message type 3 (Start-Control-Connection-Connected)
l2tpd[18343]: control_finish: Connection established to 10.0.0.100, 1701. Local: 42661, Remote: 1. LNS session is 'default'
l2tpd[18343]: check_control: control, cid = 0, Ns = 2, Nr = 1
l2tpd[18343]: handle_avps: handling avp's for tunnel 42661, call 25187
l2tpd[18343]: message_type_avp: message type 10 (Incoming-Call-Request)
l2tpd[18343]: message_type_avp: new incoming call
l2tpd[18343]: ourcid = 15796, entropy_buf = 3db4
l2tpd[18343]: assigned_call_avp: using peer's call 1
l2tpd[18343]: call_serno_avp: serial number is 0
l2tpd[18343]: bearer_type_avp: peer bears: analog
l2tpd[18343]: check_control: control, cid = 0, Ns = 3, Nr = 1
l2tpd[18343]: check_control: control, cid = 1, Ns = 3, Nr = 2
l2tpd[18343]: handle_avps: handling avp's for tunnel 42661, call 15796
l2tpd[18343]: message_type_avp: message type 12 (Incoming-Call-Connected)
l2tpd[18343]: tx_speed_avp: transmit baud rate is 11000000
l2tpd[18343]: frame_type_avp: peer uses:sync frames
l2tpd[18343]: ignore_avp : Ignoring AVP
l2tpd[18343]: start_pppd: I'm running:
l2tpd[18343]: "/usr/sbin/pppd"
l2tpd[18343]: "passive"
l2tpd[18343]: "-detach"
l2tpd[18343]: "192.168.0.1:192.168.0.2"
l2tpd[18343]: "file"
l2tpd[18343]: "/etc/ppp/l2tpdopt"
l2tpd[18343]: "/dev/ttyp0"
l2tpd[18343]:
l2tpd[18343]: control_finish: Call established with 10.0.0.100, Local: 15796, Remote: 1, Serial: 0
l2tpd[18343]: check_control: control, cid = 0, Ns = 4, Nr = 2

Then pppd is started:

pppd[21430]: pppd 2.4.2b3 started by root, uid 0
pppd[21430]: Using interface ppp0
pppd[21430]: Connect: ppp0 <--> /dev/ttyp0
pppd[21430]: CHAP peer authentication succeeded for vvidic
pppd[21430]: Cannot determine ethernet address for proxy ARP
pppd[21430]: local IP address 192.168.0.1
pppd[21430]: remote IP address 192.168.0.2

Relevant part of ipsec.conf (note the *protoport options):

conn win-vpn
type=transport
authby=rsasig
pfs=no
left=10.0.0.1
leftcert=vpn.pem
leftprotoport=17/0
right=%any
rightrsasigkey=%cert
rightprotoport=17/1701
auto=add

> Nothing in /var/log appears to be of much use. There's lots of klips
> stuff which is very verbose, but nothing sticks out.

Turn of the verbosity for IPSsec- the normal log level was always
enough for me, but use debug option for pppd.

> Any insight would be much appreciated. I must admit I'm still a little
> unclear how the whole idea works, but I believe that IPSec receives the
> connection, then calls l2tpd, which starts ppp. I can post more config
> / debug if needed.

First IPSec tunnel is established. Over that tunnel L2TP connection is
created via l2tp. L2TP packets than carry standard PPP frames - that is
what pppd handles.

Hope this helps. Post some of your logs if not. :)

Valentin

Jose Luis Domingo Lopez

unread,
Dec 25, 2003, 3:40:10 PM12/25/03
to
On Thursday, 25 December 2003, at 04:32:10 +0100,
cd wrote:

> but tunnel ipsec in l2tp is quite normal. You need it to turn around the nat
> problem of ipsec.
>

Or just use "NAT traversal" support for IPsec, implemented in commercial and
free IPsec stacks alike. FreeS/WAN has (unofficial ?) NAT traversal
support, as well as native Linux kernel 2.6.x IPsec implementation if
you use FreeS/WAN for the IKE daemon.

Antony Gelberg

unread,
Dec 25, 2003, 7:20:08 PM12/25/03
to
On Thu, Dec 25, 2003 at 04:18:39PM +0100, Valentin Vidic wrote:
> On Wed, Dec 24, 2003 at 12:49:31AM +0000, Antony Gelberg wrote:
> > My first post here - long time d-u subscriber. I'm trying to set up a
> > VPN where WinXP roadwarriors can access a LAN that sits behind a Linux
> > router. I want to use X.509 certificates rather than PSKs.
>
> I managed to set up a VPN dial-up connection from Windows Dial-up
> Networking to Debian running superfreeswan and l2tpd - so it is
> possible to do this (although not too easy). I used l2tpd 0.69-7jdl and
> freeswan 1.99.8.
>
> > When I try to log in, I get "Error 792: The L2TP connection attempt
> > failed because security negotiation timed out." I don't get any
> > "verifying username..." message.
>
> As usual this doesn't tell much. Error messages on the Linux side are
> a lot better. Also try monitoring the traffic with tcpdump on different
> interfaces (depending on the part of connection you managed to get
> working you should either monitor eth0, ipsec0 or ppp0). Try checking
> /var/log/auth.log for IPSec messages. A successful connection looks

Aha. That's the logfile that I was looking for - what a help.
I've snipped some relevant stuff, and put comments inline. If you have
any ideas I'd be interested:

Dec 26 00:09:44 mailhost ipsec__plutorun: Starting Pluto subsystem...
Dec 26 00:09:44 mailhost Pluto[4416]: Starting Pluto (FreeS/WAN Version
1.96)
Dec 26 00:09:44 mailhost Pluto[4416]: including X.509 patch (Version
0.9.9)
Dec 26 00:09:44 mailhost Pluto[4416]: Changing to directory
'/etc/ipsec.d/cacerts'
Dec 26 00:09:44 mailhost Pluto[4416]: loaded cacert file 'cacert.pem'
(1647 bytes)
Dec 26 00:09:44 mailhost Pluto[4416]: Changing to directory
'/etc/ipsec.d/crls'
Dec 26 00:09:44 mailhost Pluto[4416]: loaded crl file 'crl.pem' (694
bytes)
Dec 26 00:09:44 mailhost Pluto[4416]: loaded my X.509 cert file
'/etc/x509cert.der' (700 bytes)
Dec 26 00:09:44 mailhost Pluto[4416]: | from whack: got --esp=3des
Dec 26 00:09:44 mailhost Pluto[4416]: loaded host cert file
'/etc/ipsec.d/mailhostCert.pem' (5049 bytes)
Dec 26 00:09:44 mailhost Pluto[4416]: added connection description
"mailhost-rw"
Dec 26 00:09:44 mailhost Pluto[4416]: listening for IKE messages
Dec 26 00:09:44 mailhost Pluto[4416]: adding interface ipsec0/eth1
195.54.235.74
Dec 26 00:09:44 mailhost Pluto[4416]: loading secrets from
"/etc/ipsec.secrets"
Dec 26 00:09:44 mailhost Pluto[4416]: loaded private key file
'/etc/ipsec.d/private/mailhostKey.pem' (1751 bytes)
Dec 26 00:09:44 mailhost Pluto[4416]: file coded in unknown format,
discarded
Dec 26 00:09:44 mailhost Pluto[4416]: "/etc/ipsec.secrets" line 1: error
loading RSA private key file

The above two lines don't look too good. I assume that it means that
/etc/ipsec.secrets is ok, and that there is a problem with
/etc/ipsec.d/private/mailhostKey.pem?

mailhost:~# cat /etc/ipsec.secrets
: RSA /etc/ipsec.d/private/mailhostKey.pem "xxx"

Note that the xxx is really the "export password" that I gave when I
generated the key.

Dec 26 00:10:04 mailhost Pluto[4416]: packet from 82.68.107.174:500:
ignoring Vendor ID payload
Dec 26 00:10:04 mailhost Pluto[4416]: "mailhost-rw" 82.68.107.174 #1:
responding to Main Mode from unknown peer 82.68.107.174
Dec 26 00:10:05 mailhost Pluto[4416]: "mailhost-rw" 82.68.107.174 #1:
Peer ID is ID_DER_ASN1_DN: 'C=UK, ST=Some-State, L=London, O=British
WIZO, CN=British WIZO, E=admini...@britishwizo.org.uk'
Dec 26 00:10:05 mailhost Pluto[4416]: "mailhost-rw" 82.68.107.174 #1: no
suitable connection for peer 'C=UK, ST=Some-State, L=London, O=British
WIZO, CN=British WIZO, E=admini...@britishwizo.org.uk'

I guess that the "no suitable connection" is because of the above
problem?

A

Valentin Vidic

unread,
Dec 25, 2003, 8:00:11 PM12/25/03
to
On Fri, Dec 26, 2003 at 12:18:24AM +0000, Antony Gelberg wrote:
> Dec 26 00:09:44 mailhost Pluto[4416]: loaded private key file
> '/etc/ipsec.d/private/mailhostKey.pem' (1751 bytes)
> Dec 26 00:09:44 mailhost Pluto[4416]: file coded in unknown format,
> discarded
> Dec 26 00:09:44 mailhost Pluto[4416]: "/etc/ipsec.secrets" line 1: error
> loading RSA private key file

That looks nasty. You better sort that out first. Perhaps you can find
some test certificates online and try with them. My private key file
looks like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: ...

some lines with encrypted key

-----END RSA PRIVATE KEY-----

> mailhost:~# cat /etc/ipsec.secrets
> : RSA /etc/ipsec.d/private/mailhostKey.pem "xxx"

My ipsec.secrets looks similar...

> Note that the xxx is really the "export password" that I gave when I
> generated the key.

Try doing 'openssl des -d -in mailhostKey.pem' to see if that xxx
really works.

> I guess that the "no suitable connection" is because of the above
> problem?

Perhaps... First get that private key working and then try again.

Valentin

Antony Gelberg

unread,
Dec 26, 2003, 3:30:21 PM12/26/03
to
On Fri, Dec 26, 2003 at 01:55:42AM +0100, Valentin Vidic wrote:
> On Fri, Dec 26, 2003 at 12:18:24AM +0000, Antony Gelberg wrote:
> > Dec 26 00:09:44 mailhost Pluto[4416]: loaded private key file
> > '/etc/ipsec.d/private/mailhostKey.pem' (1751 bytes)
> > Dec 26 00:09:44 mailhost Pluto[4416]: file coded in unknown format,
> > discarded
> > Dec 26 00:09:44 mailhost Pluto[4416]: "/etc/ipsec.secrets" line 1: error
> > loading RSA private key file
>
> That looks nasty. You better sort that out first. Perhaps you can find
> some test certificates online and try with them. My private key file
> looks like this:
>
> -----BEGIN RSA PRIVATE KEY-----
> Proc-Type: 4,ENCRYPTED
> DEK-Info: ...
>
> some lines with encrypted key
>
> -----END RSA PRIVATE KEY-----

Mine too.

> > mailhost:~# cat /etc/ipsec.secrets
> > : RSA /etc/ipsec.d/private/mailhostKey.pem "xxx"
>
> My ipsec.secrets looks similar...
>
> > Note that the xxx is really the "export password" that I gave when I
> > generated the key.
>
> Try doing 'openssl des -d -in mailhostKey.pem' to see if that xxx
> really works.

It didn't work. I tried it on a newly-generated key as well.

mailhost:/usr/local/sslca# openssl des -d -in ./newreq.pem
enter des-cbc decryption password:
bad magic number

What could be wrong? The password that I'm entering is the one that
CA.sh prompts me with with "Enter PEM pass phrase:".

A

Antony Gelberg

unread,
Dec 28, 2003, 10:00:14 PM12/28/03
to
On Fri, Dec 26, 2003 at 01:55:42AM +0100, Valentin Vidic wrote:
> On Fri, Dec 26, 2003 at 12:18:24AM +0000, Antony Gelberg wrote:
> Perhaps... First get that private key working and then try again.
>
> Valentin

Right, I sorted the private key problem. It loads happily now. But I
do get:
Dec 29 02:53:12 mailhost Pluto[11757]: packet from 82.68.107.174:500:
ignoring Vendor ID payload
Dec 29 02:53:12 mailhost Pluto[11757]: packet from 82.68.107.174:500:
initial Main Mode message received on 195.54.235.74:500 but no
connection has been authorized

in the logs, and predictably, still no connection. I'll keep looking,
but if you can provide any more advice, I'd be grateful.

A

--
Now playing: Led Zeppelin - Whole Lotta Love - Medley: Boogie Chillun / Fixin' to Die / That's Alright Mama / A Mess of Blues

Antony Gelberg

unread,
Dec 31, 2003, 9:30:13 AM12/31/03
to
Right, I've upgraded to freeswan 2.01 from backports.org. This was
because the 1.96 that I was using from Woody didn't recognise the
leftprotoport and rightprotoport commands. I apt-got the source,
grepped, and sure enough they weren't there. This leads me to believe
that the

But now I have a different problem. Upon reboot (recompiled the kernel
with the 2.01 patch), I couldn't ssh in. Doh! I was just able to get
onsite, and there was a problem with the routing table.

Kernel IP routing table
Destination Gateway Genmask Metric Ref Use
Iface
localnet * 255.255.255.240 0 0 0 eth1
localnet * 255.255.255.240 0 0 0 ipsec0
10.0.0.0 * 255.0.0.0 0 0 0 eth0
default 195.54.235.73 128.0.0.0 0 0 0 ipsec0
128.0.0.0 195.54.235.73 128.0.0.0 0 0 0 ipsec0
default 195.54.235.73 0.0.0.0 0 0 0 eth1

What happens is that pings in or out cause the ipsec0 packet transmit
count to increase, and that's about it. I had to /etc/init.d/stop ipsec
to get connectivity back.

I've googled a bit and don't see the answer. Best I could come up with
was http://lists.virus.org/freeswan-0307/msg00363.html. This states
that OE can cause freeswan to take over the default route. But I don't
want OE, and I can't for the life of me work out how to switch it off.
I think it has something to do with the default policies that 1.96
didn't have, but I also can't work out how to switch them off.

A

Reinhold Plew

unread,
Dec 31, 2003, 10:20:17 AM12/31/03
to

Antony Gelberg schrieb:

may be you need this in your ipsec.conf to disable OE

/---------------------------------
# auto=ignore means disable
conn block
auto=ignore

conn clear
auto=ignore

conn private
auto=ignore

conn clear-or-private
auto=ignore

conn private-or-clear
auto=ignore
conn packetdefault
auto=ignore
\----------------------------------


> A
> _______________________________________________
> FreeS/WAN Users mailing list
> us...@lists.freeswan.org
> https://mj2.freeswan.org/cgi-bin/mj_wwwusr
>

Reinhold

Andreas Steffen

unread,
Dec 31, 2003, 10:40:08 AM12/31/03
to

http://www.freeswan.org/freeswan_trees/freeswan-2.04/doc/policygroups.html#disable_oe

Disabling Opportunistic Encryption

To disable OE (eg. policy groups and packetdefault), cut and paste the following
lines to /etc/ipsec.conf:

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

Regards

Andreas

=======================================================================
Andreas Steffen e-mail: andreas...@strongsec.com
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===

Antony Gelberg

unread,
Jan 1, 2004, 8:00:06 PM1/1/04
to
On Wed, Dec 31, 2003 at 04:04:39PM +0100, Reinhold Plew wrote:
> may be you need this in your ipsec.conf to disable OE

Thanks to you and Andreas, that worked great. I'm now getting this in
my /var/log/auth.log:
Jan 2 00:30:35 mailhost pluto[7154]: "mailhost-rw"[2] 82.68.107.174 #2:
Peer ID is ID_DER_ASN1_DN: 'C=UK, ST=UK, L=London, O=British WIZO,
OU=British WIZO, CN=British WIZO, E=admini...@britishwizo.org.uk'
Jan 2 00:30:35 mailhost pluto[7154]: "mailhost-rw"[2] 82.68.107.174 #2:
no suitable connection for peer 'C=UK, ST=UK, L=London, O=British WIZO,
OU=British WIZO, CN=British WIZO, E=admini...@britishwizo.org.uk'

Here's my current ipsec.conf (excluding the OE disable part):


conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert

conn mailhost-rw
type=transport
left=195.54.235.74
leftcert=mailhostCert.pem
leftprotoport=17/0
right=%any
rightprotoport=17/1701
auto=add
keyingtries=1
pfs=no

I have tried generating a new CA, certificate, and key, but no joy. I
must be very close now, but still no cigar. This might be useful as
well:

mailhost:/usr/local/sslca# ipsec auto --status
000 interface ipsec0/eth1 195.54.235.74
000
000 debug none
000
000 "mailhost-rw": 195.54.235.74[C=UK, ST=UK, L=London, O=British WIZO,
OU=British WIZO, CN=British WIZO,
E=admini...@britishwizo.org.uk]:17/0...%any:17/1701
000 "mailhost-rw": CAs: 'C=UK, ST=UK, L=London, O=British WIZO,
OU=British WIZO, CN=British WIZO,
E=admini...@britishwizo.org.uk'...'%any'
000 "mailhost-rw": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 1
000 "mailhost-rw": policy: RSASIG+ENCRYPT; interface: eth1; unrouted
000 "mailhost-rw": newest ISAKMP SA: #0; newest IPsec SA: #0; eroute
owner: #0
000 "mailhost-rw": IKE algorithms wanted: 5_000-1-5, 5_000-2-5,
5_000-1-2, 5_000-2-2, flags=-strict
000 "mailhost-rw": IKE algorithms found: 5_192-1_128-5,
5_192-2_160-5, 5_192-1_128-2, 5_192-2_160-2,
000 "mailhost-rw": ESP algorithms wanted: 3_000-1, 3_000-2,
flags=-strict
000 "mailhost-rw": ESP algorithms loaded: 3_168-1_128, 3_168-2_160,
000
000

If there is any more log info that would be useful, please let me know
what to post.

A

Valentin Vidic

unread,
Jan 2, 2004, 5:20:20 AM1/2/04
to
On Fri, Jan 02, 2004 at 12:47:58AM +0000, Antony Gelberg wrote:
> leftprotoport=17/0

Try with leftprotoport=17/1701. This depends on what version of
Windows you're using.

> If there is any more log info that would be useful, please let me know
> what to post.

Key loading is working now? What does ipsec auto --listall say?

Valentin

Andreas Steffen

unread,
Jan 2, 2004, 6:50:09 AM1/2/04
to
Strange that the subject Distinguished Name (DN) of your mailhost
certificate seems to be identical to the DN of the CA.

Could you enable debugging by setting

klipsdebug=none
plutodebug=all

in ipsec.conf and then after you tried to start up the connection
generate a barf:

ipsec barf > barf.txt

end mail it to me. Also the output of

ipsec auto --listall

could be helpful.

Regards

Andreas

> _______________________________________________
> FreeS/WAN Users mailing list
> us...@lists.freeswan.org
> https://mj2.freeswan.org/cgi-bin/mj_wwwusr


--

=======================================================================
Andreas Steffen e-mail: andreas...@strongsec.com
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===

Jean-Francois Dive

unread,
Jan 5, 2004, 3:00:16 AM1/5/04
to
Hi,

looks like an ipsec isssue as l2tp cant connect. How does freeswan logs
looks like ?

On Wed, Dec 24, 2003 at 12:49:31AM +0000, Antony Gelberg wrote:

--

-> Jean-Francois Dive
--> j...@linuxbe.org

I think that God in creating Man somewhat overestimated his ability.
-- Oscar Wilde

0 new messages