Forums

Tom Tucker
Tom Tucker
Offline
Resolved
0 votes
I have a Clearos 5.1 Sp1 machine setup, and everything seems to be working except windows file shares.

It is setup as a gateway, with firewall, advanced firewall, mail, windows networking, etc..


Trying to connect from a windows machine with a net use ... gives an error 53

On the server itself, I tried the following, which shows that Samba is running

smbclient -L //localhost -Utom
Enter tom's password:
Domain=[CANTERBURY] OS=[Unix] Server=[Samba 3.4.7-1.1.v5]

Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC Service (Canterbury Lane Server)
test Disk Flexshare - test
shared Disk Flexshare - Shared Files
tom Disk Home Directories
Domain=[CANTERBURY] OS=[Unix] Server=[Samba 3.4.7-1.1.v5]



So I tried the following (which is the local ip address)

smbclient -L //192.168.150.1 -Utom
Enter tom's password:
Connection to 192.168.150.1 failed (Error NT_STATUS_CONNECTION_REFUSED)

It appears that samba is not binding to eth0 (the private side)..

on checking /etc/samba/smb.conf, the network section is as follows:

# Network
bind interfaces only = yes
interfaces = lo eth0
smb ports = 139


So... what am I doing wrong?
Saturday, June 26 2010, 02:28 AM
Share this post:
Responses (24)
  • Accepted Answer

    Saturday, September 18 2010, 07:07 AM - #Permalink
    Resolved
    0 votes
    Andreas,
    I am getting pretty fed up with your sniping. Most ClearOS implementations work. Generally in forums you only see people who have problems and some helpers so it is not representative of the user base as a whole.
    The firewall is standard iptables which is used in most (all?) linux distro's and it works. ClearOS have bolted on a front end which is different. Similarly for IPSec VPN's they use a standard package, Openswan. It is only their implementation of the front end which restricts its configuration and does not allow it to play with other non-ClearOS end points. I use it to two different Draytek.
    Getting back to your post, the default implementation of IPSec uses Netkey to magically route its traffic through the kernel which gives conceptually odd results like packets appear from the other end "by magic" rahter than through any interface such as eth0 which can make them harder to deal with. Netkey is built into the standard linux kernel and has nothing to do with Clearos or Openswan. There are another couple of protocols which you can use, klips and mast. Mast I know nothing about, but klips (which again I have not used) works in a different way to netkey in that it defines a VPN interface, ipsec0, which gives you a completely different set of options for routing and for the firewall as this interface can be specified in your rules. It also explicitly binds ipsec0 to one WAN interface which you can specify. Again, this could possibly be useful. Both netkey and klips have issues with their implementation and they each get round different problems but for most users you can use either. How do you know that using another protocol will not help?
    For what it is worth, Openswan is a continually moving development with updates being issued regularly, some of which are better than others (apparently keep clear of 2.6.25). In itself it is certainly not bug free, but the bugs appear to be in the more exotic regions of the implementation.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, September 04 2010, 04:50 PM - #Permalink
    Resolved
    0 votes
    Peter Baldwin wrote:
    Yes, Openswan has implemented dead peer detection, but that behaved badly last time we reviewed it.

    I think DPD got a bit of a reworking at about 2.6.25, but 2.6.25 apparently was not good for other reasons. I believe DPD is also not recommended on a congested link where the DPD responses may not come back quickly enough and can result in a VPN reset. Somewhere in recent history two more DPD actions appeared - restart_by_peer and restart. I don't think they have been particularly well documented and, in a dynamic IP environment, I think they have missed a trick by not re-reading ipsec.secrets when they restart the VPN. I do use DPD but do not rely on it and I've written my own watching script (which is overdue for a bit of a re-write).

    When evaluating IPSec, have you looked at using the klips stack instead of netkey? I have not as I did not need it. I believe it solves some problems but, as with many things, can introduce others.
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Thursday, September 02 2010, 08:39 PM - #Permalink
    Resolved
    0 votes
    And apologies for hijacking this thread!
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Thursday, September 02 2010, 08:39 PM - #Permalink
    Resolved
    0 votes
    Well I have tried both with the same results.


    And you have gone through technical support and -- as happens from time to time -- your scenario has us a bit stumped. I don't know why your connection is misbehaving. It should just work!

    A couple of years ago, we used to help manage a 20-ish node IPsec network. The nodes were configured in a hybrid hub-and-spoke / mesh configuration. The network was also global (Europe, North America, Asia). There was one route between the headquarters and a remote office that caused a lot of grief. A lot. What was especially frustrating was that this connection was over one ISP (ohhh Sprint) and only a few hops away.

    Mabybe the stuff it is doing for us is messing up the VPN. So now I have tried to disable it. It runs even without the managed VPN service.


    Doubt it since it doesn't do much when managed VPN is disabled.

    How was I to know it is depreciated? It appears in the web UI without any such warnings. The new module is worse, since I don't know how to use iptables. What is needed is something like the old one but in a better layout and better documentation.


    Agreed, it's a place in ClearOS that needs improvement. As I mentioned, we want to make sure webconfig can be used to configure some fairly advanced firewall rules without the need to drop to the command line.

    The "custom" rules are for iptables geeks and ClearCenter support. There will always be complex iptables rules required by a minority of customers. Instead of telling a customer "hey, download putty, login to this strange command line environment and edit a file", we can now just send the (albeit cryptic) iptables rules for cutting-and-pasting into webconfig. Not ideal, but it fulfills a need.

    Keep in mind, 98% of ClearOS users never need the Advanced/Custom rules. It's not even installed by default (I think).
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Thursday, September 02 2010, 08:02 PM - #Permalink
    Resolved
    0 votes
    Oh boy, I don't want to get into an argument, it's not in my genes.

    Then why is something broken included and advertised to work. Now you are saying you engage in false advertising, too?


    That's why we recommend the Dynamic VPN service. Unmanaged VPN connections are not reliable. There's even a big red warning in ClearOS 5.2 when attempting to configure an unmanaged connection.

    If that is the case then how can you explain that your "dynamic vpn service" does absolutly nothing more than update openswan config files with the IP address


    See that "vpnwatchd" daemon running? :-) It does stuff.

    - monitors the connection
    - restarts the connection
    - reconfigures (if dynamic)
    - checks the routes (critical for multiwan boxes)

    The IPsec protocol is a very loose one. That's why you can have two different vendors ship two standards compliant IPsec systems, but the systems won't interoperate. For one, IPsec does not define a "keep this connection up" protocol in detail. Even with two static IPs, you will still have IPsec connections that will require a restart from time to time. Yes, Openswan has implemented dead peer detection, but that behaved badly last time we reviewed it.

    It is talking about "source" and "destination" ports but it is not referring to the normal sense of TCP functioning.


    Ah... I think I see. Are you referring to the (deprecated) Advanced Firewall rules? That tool was a big mistake and apologize for that. It's deprecated for a reason. Instead, we'll be adding some of the more common advanced firewall rules to webconfig and leaving any other advanced trickery with just custom iptables rules (see details)
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Wednesday, September 01 2010, 10:28 PM - #Permalink
    Resolved
    0 votes
    Hi Andreas,

    I am pretty convinced that Openswan works as intended


    I am not convinced at all. In my book, Openswan doesn't work.

    Openswan works really great in 95% of the connections that I have seen over the years. It's utterly broken in the other 5%. It's not Openswan, but the whole IPsec protocol (yes, protocol) and stack in Linux. The reason we built the "Dynamic VPN" service is because IPsec is not reliable. Sad, but true. Openswan is fine on good solid networks (I can't remember the last time we had an issue with it in our environment), but utterly horrible in other environments (satellite networks, I'm looking at you).

    Quite frankly, we're tired of dealing with IPsec and all its warts. I absolutely hate IPsec... it is the spawn of the devil. I will have a *big* pitcher of beer when OpenVPN becomes the default for ClearOS-to-ClearOS connections.

    and releasing the full source code of this so-called "gpl licenced" software would not hurt either.


    Are you trolling? Okay, I'll feed you :-)

    - On the same download page where you found the ISO image, you will find the link to the source RPMS @ http://download.clearfoundation.com/clearos/enterprise/sources/5.x/

    - If you really want to geek out, click on "Developer - Source Code" in the menu. You will not only see the source code, but all the usual detailed changes that you see in a source code control system (SVN).

    - And if you really want to geek out, see some of the progress that is being made on the new build system (with more source code / developer info). You can find that in "Developer - Build" in the menu.

    There are a handful of hand-rolled packages that have to move from the really old "ClarkConnect / Point Clark Networks" SVN system. These are packages that were built internally (i.e., there is no "upstream"). Just ask, and we can provide the source code manually... no big deal. We'll migrate these packages over to the new build system. Please be patient, there are only so many hours a week that we can dedicate time to ClearFoundation :ohmy:

    I also have a feeling that you are looking for more detailed technical specifications. That would have made your multiWAN hacking a little nicer. Perhaps documents like this one are what you are looking for. Again, please give us some time to build out these documents as features pop-up for a "refresh".
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 01 2010, 10:01 PM - #Permalink
    Resolved
    0 votes
    Hi. the "automagic" is required to notify and update many of the networking services when interface details change. For example, so when a user defines a new WAN there are a lot of services which need to know what the new interface is. It does seem a little black box at times but is necessary for everything to join together

    As for source code...SVN and CVS are all here? I think the SVN has only recently come back online again.
    http://www.clearfoundation.com/docs/developer/source_code/
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 02 2010, 07:11 PM - #Permalink
    Resolved
    0 votes
    Thanks for that.

    IPSec works in strange ways and does not always do what you expect.
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Friday, July 02 2010, 06:21 PM - #Permalink
    Resolved
    0 votes
    Well, I tried it with and without, with predictable results..

    When in place, I can access from remote site

    When not in place, I cannot.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 02 2010, 06:13 PM - #Permalink
    Resolved
    0 votes
    That is exactly what I did and it worked but I don't know if it was necessary. I have tried undoing it but I do not want to ask my remote users if I have broken anything! That is why I asked you to post back.
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Friday, July 02 2010, 05:36 PM - #Permalink
    Resolved
    0 votes
    I would like to be able to access the samba shares from the remote side of the IPsec.. do I just need to add the remote subnet?

    i.e. change /etc/samba/smb.conf

    from

    # Network
    bind interfaces only = no
    hosts allow = 127.0.0.1 192.168.150.0/24
    interfaces = lo eth0
    smb ports = 139


    to

    # Network
    bind interfaces only = no
    hosts allow = 127.0.0.1 192.168.150.0/24 192.168.1.0/24
    interfaces = lo eth0
    smb ports = 139
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 02 2010, 04:50 PM - #Permalink
    Resolved
    0 votes
    If you're using IPSec, you may also have to allow your remote network for them to get access to the shares.

    Is there any chance that you can post back if you need to allow the remote network as well?
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Friday, July 02 2010, 03:48 PM - #Permalink
    Resolved
    0 votes
    Yes, I am using IPsec.. that must have been it.. I set AUTOMAGIC=off and it seems to have cured it.

    That also explains why it was working, then stopped. I didn't setup IPsec at first...


    Thanks.
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Friday, July 02 2010, 03:46 PM - #Permalink
    Resolved
    1 votes
    Thanks.

    That is what cured my problem.

    For some reason Samba was not binding to eth0

    Setting my smb.conf to the following:

    # Network
    bind interfaces only = no
    hosts allow = 127.0.0.1 192.168.150.0/24
    interfaces = lo eth0
    smb ports = 139

    seems to have fixed the problem...
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Friday, July 02 2010, 01:36 PM - #Permalink
    Resolved
    0 votes
    Just to let document the undocumented ;)

    The AUTOMAGIC="off" in /etc/sysconfig/samba is what disables the automatic changes to smb.conf.

    Automatically re-writing configuration files on the fly is not something that should be done in general! However, we do make one exception -- applying security/network policies. When changes are done in network configuration (for example, swapping around WAN/LAN roles), these changes often need to be applied to services running on the system:

    - Samba (only allows connections from the LAN)
    - Squid proxy (only allows connections from the LAN)
    - Intrusion Detection and Prevention
    - etc.

    You can disable this behavior by setting the AUTOMAGIC="off" in the appropriate /etc/sysconfig/X file. You can also disable this behavior system wide using the /etc/sysconfig/automagic file.

    Hmmm... I should probably put this in the developer docs!
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 02 2010, 11:21 AM - #Permalink
    Resolved
    0 votes
    Yes, I forgot that. If you restart Windows Networking it resets the "bind interfaces" bit (and I think some other bits) for security. Do as Pete said and re-start the two services from the command line. This bypasses the checking script.
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Thursday, July 01 2010, 09:25 PM - #Permalink
    Resolved
    0 votes
    I tried that...

    and when I restart windows networking, it changes the
    bind interfaces only = no

    back to
    bind interfaces only = yes
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 01 2010, 09:09 PM - #Permalink
    Resolved
    0 votes
    Yes, then restart Windows Networking. There is no point in adding the "hosts allow" unless you change the "bind interfaces only" to "no".
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Thursday, July 01 2010, 08:53 PM - #Permalink
    Resolved
    0 votes
    I presume I add this to the file in /etc/samba/smb.conf ??

    like so?

    # Network
    bind interfaces only = yes
    hosts allow = 127.0.0.1 192.168.150.0/24
    interfaces = lo eth0
    smb ports = 139
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 01 2010, 05:37 PM - #Permalink
    Resolved
    0 votes
    You could probably help your security a bit by using the "hosts allow" directive e.g:
    hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24

    So you still restrict the range of IP's which are allowed to connect.
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Thursday, July 01 2010, 02:00 PM - #Permalink
    Resolved
    0 votes
    Hi Tom,

    Are you using IPsec? If you are, then you might be running into this bug. It's a weird interaction between an old IPsec workaround and the way Samba handles enumerating the network interfaces.

    The IPsec workaround has been removed in ClearOS 5.2 (it doesn't look like it is needed anymore), so you won't run into this problem on 5.2. For ClearOS 5.1, a temporary workaround is to disable the automatic "bind interfaces only" configuration done on a Samba restart. In /etc/sysconfig/samba, add:

    AUTOMAGIC=off

    And then send bind interfaces only to "no" in /etc/samba/smb.conf:

    bind interfaces only = No

    Restart Samba after making the changes:

    service nmb restart; service smb restart

    You should know that you will be depending on the firewall (and only the firewall) to block connections to Samba from the Internet.
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Thursday, July 01 2010, 01:23 PM - #Permalink
    Resolved
    0 votes
    I still have not figured out what is wrong. Maybe I can remove and reinstall samba. Is there some instructions on doing that somewhere that I have missed?

    Thanks..
    The reply is currently minimized Show
  • Accepted Answer

    Tom Tucker
    Tom Tucker
    Offline
    Sunday, June 27 2010, 02:08 AM - #Permalink
    Resolved
    0 votes
    I get this from the grep IF /etc/firewall


    EXTIF="ppp0"
    LANIF="eth0"
    DMZIF=""
    WIFIF=""
    HOTIF=""
    DNSIF=""
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 26 2010, 08:40 PM - #Permalink
    Resolved
    0 votes
    Both tests for smbclient work on both the localhost and the local LAN IP work here...

    It usually means that your don't have the correct interface defined as LAN in the webconfig?

    What does this output?
    grep IF /etc/firewall
    The reply is currently minimized Show
Your Reply