FreeSwan VPN using Samba

Lapers Stefan Stefan.Lapers at GB.BE
Mon Jul 29 23:59:01 GMT 2002


Hi guys, I don't have that much experience with freeswan and samba playing
together.

Just a thought:
I had been testing freeswan for several day's and found ipsec as is to have
some shortcomings. ( not shooting at freeswan here :-) )
I don't know if you can apply this in your environment, but wouldn't
combining a tunneling protocol and ipsec be your solution ?
If you use GRE or L2TP you will obtain an interface which you can use for
routing etc. (one of the things i didn't manage to get working 100 % with
ipsec alone).
(overhead by using a tunneling protocol inside ipsec is minimal, CISCO has a
document describing this)



Greets,


Lapers Stefan

> -----Original Message-----
> From:	Alex @ Avantel Systems [SMTP:alex at avantel.ca]
> Sent:	maandag 29 juli 2002 23:59
> To:	samba-technical at lists.samba.org
> Subject:	Re: FreeSwan VPN using Samba
> 
> Steve 
> 
> Sounds like we were working on similar projects. Same task, same problems
> but 
> we had it working pretty well. Haven't looked at it recently but as I
> recall 
> we resolved the problem you describe *without* a patch to samba!  If you
> bind 
> to the interface ipsec*, you should get the behaviour you are looking for.
> 
> 	interfaces = ipsec* eth1 lo
> 	bind interfaces only = yes
> We had other problems though and if you can add to my understanding of
> those 
> that would be cool. See
> 
> http://www.avantel.ca/samba.html
> 
> Can anyone add something to that . . . 
> 
> And AFAIK samba wins does still not replicate so the problem persists
> today.
> 
> Cheers;
> 
> Alex Vandenham
> Avantel Systems
> 
> On July 29, 2002 12:12 pm, you wrote:
> > Greetings.
> >
> > Early in 2000, I was involved with a project to bring out of the box,
> > installable, VPNs to a shrink-wrap RedHat linux.  The project ended
> because
> > the leader, a brilliant idea man, was a paranoid freak.  However, I was
> > fascinated by the idea of bringing together a Windows Workgroup over a
> > secure VPN using FreeSwan and Samba.
> >
> > All of the messages and web pages I looked at for making this happen
> with
> > Samba indicated ways to hack around in the config file.  None of the
> > solutions ever worked thoroughly and the indication was that you had to
> > live with it when it didn't.  The real problem was with the Samba code.
> >
> > I don't remember which Samba release I worked on to make this happen but
> I
> > do know it was the release that was included with RedHat 6.1.  I had to
> > make some specific configuration adjustments and small modifications to
> two
> > of the core Samba modules.  A WINS server is, of course, necessary for
> > cross-subnet browsing and I use Samba for this.  I had Win95, Win98,
> WinME,
> > and Win2000 machines on this network but no Win2000 or WinNT Servers.
> >
> > All of this worked great.
> >
> > I have recently configured a three-network VPN using RedHat 7.3,
> FreeSwan
> > 1.97, and Samba 2.2.3a.  I waited so long to upgrade because I was
> afraid
> > that the latest release of Samba included with RedHat would still have
> the
> > problem.  It did.
> >
> > Consider this network:
> >
> >                     Network NORTH
> >                     --------------------------------
> >                     eth0  20.30.40.50    RedHat 7.3
> >                     eth1  10.1.10.254
> >                     --------------------------------
> >                     ipsec 10.1.10.254 -> 10.1.11.254
> >                     ipsec 10.1.10.254 -> 10.1.20.254
> >                           --------------------------
> >                           Workgroup NORTH
> >                           --------------------------
> >                           10.1.10.254    DMB WINS
> >                           10.1.10.1      Win2000
> >                           10.1.10.11     Win2000
> >                           10.1.10.12     Win98
> >
> >
> > Network WEST                        Network EAST
> > --------------------------------    -------------------------------
> > eth0  30.40.50.60    RedHat 7.3     eth0  40.50.60.70    RedHat 7.3
> > eth1  10.1.11.254				eth1  10.1.20.254
> >       --------------------------          --------------------------
> > ipsec 10.1.11.254 -> 10.1.10.254    ipsec 10.1.20.254 -> 10.1.10.254
> > ipsec 10.1.11.254 -> 10.1.20.254    ipsec 10.1.20.254 -> 10.1.11.254
> >       --------------------------          --------------------------
> >       Workgroup WEST	                  Workgroup EAST
> >       --------------------------          --------------------------
> >       10.1.11.254    DMB                  10.1.20.254    DMB
> >       10.1.11.1      Win2000 Svr          10.1.20.1      Win98
> >       10.1.11.2      WinME                10.1.20.2      SUSe 8.0
> >       10.1.11.3      Win2000 Pro          10.1.20.3      Win98
> >                                           10.1.20.4      SUSe 8.0
> >
> > As you can see, there are ipsec tunnels between each network.  The
> problem
> > was in the synchronization of Domain Master Browsers.  Even when BIND
> > INTERFACES ONLY was set to YES, Samba would not bind to the INTERFACES
> > listed but to the first interface, eth0.  Therefore, the source IP for
> the
> > DMB Sync communications was for the external interface.  Since there was
> no
> > ipsec route for this, the sync failed.
> >
> > The solution to this problem was, when BIND INTERFACES ONLY is set to
> YES,
> > Samba should bind outgoing packets to the first valid INTERFACES ip
> > address. At least, this appeared to be the solution used in another part
> of
> > nmbd_packets.c.  queue_query_name() was using this method.  I simply
> moved
> > this to create_and_init_netbios_packet().  A similar change was needed
> in
> > open_socket_out() in module util_sock.c.
> >
> > Attached is the patch file "samba-2.2.3a-socketbinding.patch" and the
> spec
> > file I used to create the new RPM "samba-slc.spec".  This network is
> > working perfectly.  All machines can see each other as if they were in
> the
> > same room.
> >
> > Perhaps a more consistent solution would have been to look for the
> SOCKET
> > ADDRESS parameter and use the indicated IP.  This was how it was done in
> > smbclient's namequery.c but I don't know enough about Samba to make this
> > decision.  The one I chose seemed appropriate and worked for me.
> >
> > Here are the relevant config file parameters:
> >
> > LOCAL MASTER = YES
> > PREFERRED MASTER = YES
> > DOMAIN MASTER = YES
> > OS LEVEL = 80
> > INTERFACES = eth1 lo (lo to allow SWAT)
> > BIND INTERFACES ONLY = YES
> > SOCKET ADDRESS = (eth1 IP address) (needed for SMBCLIENT)
> > -----------------------------------------------------------
> >
> > I sent all this Andrew Tridgell last year.  I got back no response and
> no
> > change was made to Samba to fix this problem.  Could someone please
> respond
> > to me and let me know if this change will be in the next release of
> Samba?
> > I would prefer not to have to modify Samba to fix this problem, again.
> >
> > Cheers!
> > Steve Thames
> > Softlife Consulting, Inc.
> >
> > PS - Can Samba handle WINS propagation, as yet?
> 
> ----------------------------------------
> Content-Type: application/octet-stream; charset="iso-8859-1"; 
> name="samba-2.2.3a-socketbinding.patch"
> Content-Transfer-Encoding: quoted-printable
> Content-Description: 
> ----------------------------------------
> 
> ----------------------------------------
> Content-Type: application/octet-stream; charset="iso-8859-1"; 
> name="samba-slc.spec"
> Content-Transfer-Encoding: quoted-printable
> Content-Description: 
> ----------------------------------------
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the samba-technical mailing list