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'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 *
# 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
[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
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.
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)
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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.
----- Original Message ----- From: "Jose Luis Domingo Lopez" <debian-secur...@24x7linux.com> To: <debian-secur...@lists.debian.org> Sent: Wednesday, December 24, 2003 1:40 PM Subject: Re: IPSec WinXP interop
> 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)
> -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact
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):
> 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
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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.
Greetings.
-- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0)
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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?
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:
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:
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
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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.
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
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 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.
> 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.
may be you need this in your ipsec.conf to disable OE
/--------------------------------- # auto=ignore means disable conn block auto=ignore
Antony Gelberg wrote: > 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.
> 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.
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=administra...@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=administra...@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
Antony Gelberg wrote: > 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=administra...@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=administra...@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
On Wed, Dec 24, 2003 at 12:49:31AM +0000, Antony Gelberg wrote: > 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.
> 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 *
> # 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
> 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.
> -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
