FreeSwan VPN using Samba

Steve Thames steve at softlife.com
Mon Jul 29 09:23:35 GMT 2002


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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: samba-2.2.3a-socketbinding.patch
Type: application/octet-stream
Size: 7050 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020729/ad5bcec3/samba-2.2.3a-socketbinding.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samba-slc.spec
Type: application/octet-stream
Size: 26927 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020729/ad5bcec3/samba-slc.obj


More information about the samba-technical mailing list