FreeSwan VPN using Samba

Alex at Avantel Systems alex at
Mon Jul 29 15:01:01 GMT 2002


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

Can anyone add something to that . . . 

And AFAIK samba wins does still not replicate so the problem persists today.


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    RedHat 7.3
>                     eth1
>                     --------------------------------
>                     ipsec ->
>                     ipsec ->
>                           --------------------------
>                           Workgroup NORTH
>                           --------------------------
>                     DMB WINS
>                       Win2000
>                      Win2000
>                      Win98
> Network WEST                        Network EAST
> --------------------------------    -------------------------------
> eth0    RedHat 7.3     eth0    RedHat 7.3
> eth1				eth1
>       --------------------------          --------------------------
> ipsec ->    ipsec ->
> ipsec ->    ipsec ->
>       --------------------------          --------------------------
>       Workgroup WEST	                  Workgroup EAST
>       --------------------------          --------------------------
>    DMB            DMB
>      Win2000 Svr      Win98
>      WinME            SUSe 8.0
>      Win2000 Pro      Win98
>                                       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:
> OS LEVEL = 80
> INTERFACES = eth1 lo (lo to allow SWAT)
> 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"; 
Content-Transfer-Encoding: quoted-printable

Content-Type: application/octet-stream; charset="iso-8859-1"; 
Content-Transfer-Encoding: quoted-printable

More information about the samba-technical mailing list