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:[EMAIL PROTECTED]]
Sent: maandag 29 juli 2002 23:59
To: [EMAIL PROTECTED]
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:
----------------------------------------
