From owner-freebsd-net Wed Apr 25 20:23:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from skippyii.compar.com (mail.compar.com [216.208.38.130]) by hub.freebsd.org (Postfix) with ESMTP id 3E4B437B422 for ; Wed, 25 Apr 2001 20:23:13 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (kwppp49.enoreo.on.ca [216.94.25.196]) by skippyii.compar.com (8.11.3/8.11.3) with SMTP id f3Q3RW040224; Wed, 25 Apr 2001 23:27:32 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <008101c0cdff$e7185520$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Brian Somers" Cc: "Gunther Schadow" , , References: <200104260212.f3Q2CxM08889@hak.lan.Awfulhak.org> Subject: Re: VPN tunnel with DHCP ... Date: Wed, 25 Apr 2001 23:15:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Hi, > > > > > > about my SOHO router project, I came accross a tough problem, may > > > be I overlook that there is a solution already? The VPN gateway > > > at the small office / home office (SOHO) has an IPsec tunnel > > > connecting it to its headquarter: > > > > > > setkey -c < > > spdadd ${sohonet} ${homenet} -P out ipsec > > > esp/tunnel/${sohoip}-${homeip}/require; > > > spdadd ${homenet} ${sohonet} -P in ipsec > > > esp/tunnel/${homeip}-${sohoip}/require; > > > END > > > > > > now, the problem is that the ${sohoip} is dynamically assigned > > > with DHCP. How can the gateway at the headquarter know that > > > ${sohoip} address? > > > > I had a similar situation which I had to work with a while ago, although I > > used ssh tunnels instead of IPSec. I'm not sure if my method will work, but > > it's worth an try. > > > > Here's what I did: > > 1) Set the headquarters machine up with static IP and DNS. > > 2) Configure headquarters machine to allow PPP over TCP > > 3) Have remote hosts (with dynamic addresses) connect to headquarters > > machine (static address) using PPP over TCP. The endpoints of this PPP > > connection use "private" IPs, say 10.x.x.x or 192.168.x.x. Note that once > > the connection is established, the addresses of both endpoints are known. > > 4) Create SSH tunnels in each direction > > 5) Forward all traffic over the SSH tunnel > > > > In your case, you could probably use IPsec over the PPP connection instead > > of SSH. > > This is a good solution because (as you say) ppp will negotiate an > address with the other side and the setkey stuff can be done in > ppp.linkup. > > Of course it's a bad solution because of the per-packet overhead and > the two layers of tcp you'll get with any tcp connection through your > tunnel (I really must write a udp mux program for ppp). The plan was designed for 4 remote sites using 1Mbit DSL terminating at an HQ with 2.2Mbit DSL, all for running a character-based app and pushing email out to these remote sites of ~5 users. With this in mind, the overhead wasn't a concern. > You need to be careful however. The ppp.linkup on the side with > the static IP number should blow away any other ppp sessions that are > active with the peer (it's ok to do this in ppp.linkup as you've > authenticated the client at that point). The problem is that ppp > will never bring the link fully up if there's a stale connection via > the previous dynamic IP if the negotiated IP numbers are the same. > > So make sure that the side with the static IP has something like this > in it's config: > > set ifaddr x.x.x.x a.a.a.a-b.b.b.b > > where x.x.x.x doesn't matter much (it's what the other end will route > packets to) and a.a.a.a-b.b.b.b is a range of IP numbers that can be > used by the side with the dynamic IP (for the top-side of the tunnel). Ahh, yes, I can see how this would have been a problem. I think I got around this by having the "server" accepting PPP over TCP connection on 4 different ports, with each remote site assigned a different port, hence keeping everyone in line. In addition, I must say that I never did implement this although I was really looking forward to it. (My boss felt it neccessary to describe the technical intricacies of it to the client, who just got confused and dropped the project.) However, this was the defining moment in time where I truly began to appreciate the cool stuff that FreeBSD can do for me. Now, back to Gunther's request - could you do IPSec over PPP over TCP? -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message