Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - aacevedo

Pages: [1]
You know? That is a fine quote! I'm going to print it out, frame it and hang it on the wall  ;)

Problem was that the names of the Members of the Objects had blank spaces within them. I remembered having read something about this in the forum, so out of lucky inspiration I checked the names, erased all the blank spaces and now is working.

I suppose it has to do with the "valid hostname" part.

Thanks for your interest, Sam!

I have two separate Zentyal installations on separate networks. A 2.0.16 version and a more recent 2.0.21 installation.

I noticed there is a difference in the DHCP screen where the fixed addresses are configured. In the older version there is a table where one inputs directly the information for the fixed addresses: name, MAC Address, Ip Address and an optional description. On this server I have no dynamic ranges and the fixed addresses work just fine. All the client computers (mix of windows and ubuntus) keep their defined fixed addresses even when the lease is renewed.

On the 2.0.21 installation the interface was changed. Now it asks for an object, but even though I configured the objects and their members accordingly it is not assigning the fixed address.

This is my setup:
Object: Computer1
Member of computer1 --> IP address:, MAC Address: uu:vv:ww:xx:yy:zz
Object: Computer2
Member of computer2 --> IP address:, MAC Address: aa:bb:cc:dd:ee:ff
and so forth...

DHCP Static interface on eth1
DHCP Ranges
Interface IP Address:
Available range: -

From: to

Fixed Addresses
I added objects Computer1 and Computer2

I have tried three differente scenarios:
Scenario1: I deleted the dynamic ranges
Result: could not connect to the server, did not obtain an IP address

Scenario 2: I added the dynamic range shown above
Result: Computer1 got IP and computer2 got IP (dynamically assigned ignoring the fixed address from the object)

Scenario 3: I changed the IP address in the objects configuration to:
I did this following the note on the screen that says: "Only those objects whose IP address is a host, a valid MAC, the IP address is not used by the available range and whose name is unique as fixed address will be used". I wasn't sure about the "available range" part, so I tried a differente subnet but ...
Result: Computer1 got IP and computer2 got IP (dynamically assigned again).

I read the manual but it still shows the way it was done in version 2.0.16 which is working for me in my other network. The IPs are hosts addresses (/32) and the MAC addresses were double checked, I tried assigning IPs not in the ranges for the object but nothing works. Is anybody else having the same problem?

What am I missing here?

Kind regards,

I could be wrong, but it is my understanding that MS servers are able to switch from secure (HTTPS by SSL servers) to plain HTTP "at will". My guess is that if the client cannot connect securely it will go the other way.

Are we talking about the same thing?

Hi Escorpiom,

A few days back I posted this:
I did a quick test banning in Proxy. It effectively blocked all on-line access to any "" related service like hotmail, skydrive, on-line messenger, etc. But in my case it did not block access through MSN client nor Pidgin. At least it blocked one of the venues  :) I should say that for this test I have no other blocking mechanism in place. It definitely needs a combination!

If you want to block access to web messenger and the entire hotmail page just ban at the proxy level. It will block all microsoft's live services. Josep's is no doubt another way to go. Haven't tried that either. Please tell us how it goes.

I was able to spend a good part of the day yesterday setting up my lab and testing the different ways MSN connects and the different ways to try to block it following Sam's recommendation for a systematic approach.

Obviously the right time to block it is when a user tries to connect. So my set up includes, besides my Zentyal box, two Windows XP clients, one with MSN ver 2009 (build 14.0.8...) and the other with an older client ver 2004, build 4.7. (I know, I know I still need to get my hands on a Windows 7 machine, hope to accomplish that today). On the first XP machine I also configured Pidgin for Windows ver 2.7.11. Finally I have my Ubuntu Karmic (this is my desktop machine) with Pidgin 2.6.2 and Psi 0.12.1. I haven't mentioned this before but I also have an Openfire Jabber server on the same box as Zentyal (BTW, it's ver 2.0.16) in substitution of ejabberd. On Openfire I have Kraken plugin configured with MSN gateway. Both clients on Karmic go through Openfire and Kraken's gateway to connect to MSN. What I'm actually trying to achieve is to have this connection the only one allowed, since I can administer it with Openfire.

One last note: I opened Wireshark on the internal interface on the server to observe what was going on in each case as the clients connected through their different methods. Though I'm no network protocol expert I discovered something very interesting. Grossly oversimplifying, all clients go through the following basic steps at connection time:

1 client --> Zentyal: Does a standard query A for domain:
2. Zentyal --> client: Gives a standard query response with the CNAME:
3. Zentyal --> DNS service: since it's a CNAME ( is an alias, basically) it does another query A for
4. DNS service --> Zentyal: comes back with 8 different IPs (which may vary from connection to connection)
5. client --> first IP given on port 443/80: authenticates with service, does handshaking and what not in order to login.
6. client --> MSN service on port 1863: downloads contacts, presence information, etc. using protocol MSNMS
I examined Dansguardian access.log and noticed that all of this goes on using MIME type text/xml, so forget about blocking by MIME types.

At this point I realized the following:
a. blocking in the Proxy is no good (it's just an alias)
b. blocking port 1863 in the firewall from internal networks to Zentyal is no good (only DNS traffic goes by)

so, I tried the following:
i. block in the Proxy. Did'nt work. Still have to understand why but I suspect it is because the connection goes on from Zentyal to MSN Service but the proxy sits before this.
ii. block port 1863 in the firewall at the filtering rules for internal networks. It worked!!  :D The reason it was effective was because once login is accomplished the client talks directly to MSN service at the IP given by the DNS, it does not go from the client to Zentyal and then to MSN Service. It's not perfect because the client is able to login to the service but then when it tries to use MSNMS protocol to talk to the service it fails and comes back with a Network error.

In my particular case apparently it is also blocking Openfire's communications with MSN Service which is no good for me. I'll keep sniffing around to see if can manage to block at login time, will post back.


Thanks Sam,

Currently this is one of my priorities. I have my testing server which is not as clean but have another box which I am reinstalling as I write this. I'll be doing my "systematic" approach in the next couple of days but if you have the time to give me some pointers I'll be more than happy to put them in practice. After all I'm only a Zen Apprentice  ;D

If you prefer please contact me by IM so as not to clutter this thread...


I think you're onto something here Sam. As I see it, the key to nailing this down is in all the "variables" at stake. Off the top of my mind I can think of these:

Ways to access MSN
  • Directly by MSN client
  • By a generic jabber client as Pidgin
  • Online via eBuddy or site

Ways to block MSN
  • Blocking ports in Firewall
  • Banning sites (like in Proxy
  • Blocking MIME Types (BTW, I still don't know how to use this)
  • A combination of the above

Before responding, I did a quick test banning in Proxy. It effectively blocked all on-line access to any "" related service like hotmail, skydrive, on-line messenger, etc. But in my case it did not block access through MSN client nor Pidgin. At least it blocked one of the venues  :) I should say that for this test I have no other blocking mechanism in place. It definitely needs a combination!

I, for one, second Sam's proposal to use this thread to approach the subject systematically to learn how to effectively block MSN (and may I add, any other Instant Messaging service). I invite the audience to review the variables listed above and complete them to build a cause and effect matrix.

Any ideas?

Hi Josep, thanks for your quick reply!

I did try to block by ports and/or URLs although not all that are in your link (it's indeed tricky  ;)). I blocked ports 1863, 6891-6901, 5190 and 7001 as well as the following URLs:,, and

Unfortunately this blocking did not work. That's the reason I was trying to go by MIME Types.

Thanks again!

Good day to everyone. My Zentyal version is 2.0.16, everything working well.

I've been trying to block MSN Messenger. I read that the most effective way is to do it by filtering its MIME Type: "application/x-msn-messenger".  My confusion comes when I go to MIME Types Filtering tab in Http Proxy --> Filter Profiles --> Default. I am unsure how to proceed from here. Am I safe to assume that all MIME Types in the list are the only ones allowed since the Allow checkbox is ticked? Therefore any MIME Type not listed would by definition not be allowed. This is not so, since "application/x-msn-messenger" is not in the list and all my users chat away freely all day.

Based on that I figured that by adding "application/x-msn-messenger" to the list and not ticking the allow checkbox I would be disallowing it. I tried that but to no avail. Users keep chatting to their hearts content.

I have searched the forum up and down as well as the documentation but all references just say to "disallow the MIME Type". How exactly does this thing work? Any help will be greatly appreciated!


In case it is any help to anyone who may have a similar problem, let me tell you how I finally solved it.

I went back to the source installation, set both NICs to "no set" and generated a new image. After recovering the new image in the new machine I went to /etc/udev/rules.d and removed the file 70-persistent-net.rules, rebooted the machine and went to the network module to configure the cards. This time the error went away and I was able to configure the cards.

The lesson learned is that when you are making an image of an installation network cards need to be disabled because they are being identified by their MAC address. The new installation gets confused by having MAC addresses of cards that do not exist.


Hi folks,
I have core version 2.0.16, which I setup in the lab for a customer. After being done with a complete configuration (plus a bunch of other stuff on the machine, which I really would not want to go over configuring again) I did a disk image with Clonezilla. This image I recovered on the server that is going to the customer. Both machines are identical (HP Proliant Microserver).

On my lab setup I have 2 NICs:
eth2 on the WAN with DHCP
eth3 internal static with IP (DHCP is then configured on this interface for the rest of the LAN).

The customer network setup should be:
eth0 WAN static (fixed IP and gateway given by their ISP)
eth1 internal static (no DHCP here, they have a Windows Server that is taking care of networking).

When I installed the machine in the customer's network the two cards had been renamed and settings were gone in Network Module (Method not set). I should have known this was bound to happen because the source image had two different NICs in it. I figured no sweat! I just need to reconfigure the module with the customer's settings.

My problem is that I am unable to reconfigure the network module. If I try to change the settings on the interfaces it reverts to Method not set and I get the "Interface eth2 does not exist" error.

After Ubuntu research (my knowledge is really basic) and tried to edit /etc/network/interfaces with the desired configuration. I also went into /etc/udev/rules.ds and edited 70-persistent-net.rules.

My interfaces file on the new machine had just this:

Code: [Select]
auto lo
iface lo inet loopback
on which I manually added the configuration of the two new cards. I have also learned now that this is to no avail since restarting the network module wipes the file back.

On the 70-persistent-net.rules file I, of course, found the two cards from the source machine plus the two new cards that were renamed. I deleted the lines of the old cards and gave the new cards their eth0 and eth1 names. This file was not wiped by Zentyal on restart.

Where is Zentyal reading the eth2 existence from? How can I reset the whole networking setup after the image recovery? Or should I just forget to use imaging software for something like this, install Zentyal from scratch and start the whole configuration process?

Thanks a lot for bearing with me on this long post and any help that you could give me. I'm sure I'm making some silly rookie mistake but that's how we all learn, isn't it? My customer is expecting the new machine anytime now!


Pages: [1]