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
> 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)
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
but tunnel ipsec in l2tp is quite normal. You need it to turn around the nat
problem of ipsec.
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
> 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.
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
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
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
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
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
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
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]===
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
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
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]===
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