Remote Outlook Client

[BigBirdy]

What ports/services or other settings are required in order to make a connection to the Scalix server, from outside of the LAN? Although I have been using the web interface, with appropriate open ports for SSH Tomcat operation, I was curious as to what would need to be opened in order to directly connect with Outlook. Would this simply be the IMAP (143) port?

[ls-al]

..Would this simply be the IMAP (143) port?

For Scalix Connect (MAPI) you should open the scalixual port (5729).

In addition you might think about securing your MAPI connections with stunnel.

[ScalixSupport]

Complete list from the Installation Guide:

- Scalix UAL (5729)
- Scalix UAL FreeBusy (5757)
- LDAP (389)
- HTTP (80)
- HTTPS (443)
- SMTP (25)
- POP (110)
- IMAP (143)
- Kerberos ‐ Single Sign‐on only (88 and 749)

Regards,

Matthew
Scalix Support

[kenrinc]

Maybe you should clarify that: what does it take for a client running Scalix Outlook connect to connect from the Internet to Scalix. I would assume were back to the "Exchange" RPC/MAPI port issue. Not too cool to leave that port open on a firewall without problems. This is an area where Scalix could kick some butt by modifying Outlook connect so that behind the seens, it sets up a Stunnel connection to the server and then does it's thing.

The RPC/HTTP functionality of Exchange is nicer than the way we used to do it before (with MAPI/RPC ports) but the work involved in getting it to work, not to mention the "classic" MS mentality to use a separate box for every stupid additional function is just mind boggling.

The ability to do some type of "handsoff" cached exchange mode would be cool too.

$.02

Ken-

[bproven]

Guess I'm not the first to ask for this one. I just posted this question. Is this in the works?

For Scalix Connect (MAPI) you should open the scalixual port (5729).

In addition you might think about securing your MAPI connections with stunnel.

How can you secure these ports using stunnel? Has anyone done it?[/quote]

[ScalixSupport]

This is a question that we've been asked on a number of occasions and we're definitely looking into how we can achieve this but it's going to require a rearchitecture of the current protocol to do it. It's not going to be a solution available for a couple of releases.

Stunnel will not help if it is listening on the server port. SSH port forwarding could be used but not without problems.

The UAL conversation is not encrypted. This means that having stunnel listening on port 5729 on the server will not solve your requirements because the client will never send encrypted data. stunnel works for IMAP and POP because the clients are capable of encrypting the protocol.

SSH port forwarding allows you to send an encrypted conversation but you have to install ssh on each machine that you want to use. You would then set up a profile to connect to localhost and the connection would be forwarded.

This might work if you never want to do delegate access.

When a delegate connection is requested, the MAPI connector needs to know on what server the principal mailbox resides. This is done via a mailnode mapping on the server. So the client will request the principal's server name and then make a connection to that server. If you have port forwarding on your server, the MAPI connector will never make a connection to the localhost address because it has a server name. Because of this, the connection will not be encrypted and, most likely, will be refused because port 5729 is not open on the firewall.

There is the added complication that the server name which is returned as part of the delegate lookup will be an internal server name. You could possibly get around this by making sure that your machines are called the same thing from the inside as they are from the outside. It's achievable but I've only worked for a couple of big companies that have ever done this. Every other customer I've worked with has different internal names from the the ones accessible from the outside.

Assuming that you don't have the same inside and outside names, this will cause problems with any SSL certificate because the server name on the certificate is likely not to match the server name requested.

When you have multiple servers in your Scalix network, this becomes more of a problem because you then have to look to get hardware that is capable of receiving packets for multiple IP addresses and then forward them on to individual servers inside of the firewall. It's usually the case that when you can buy equipment like that, you have the ability to provide a VPN (either IPSEC or PPTP/L2TP).

Cheers

Dave

[kanderson]

In the last part, Dave mentiones that a VPN can allow this capability, and it does, we use it regularly.

IPcop is a free linux based, software firewall which also supports certificate based VPNs. It provides rock solid VPNs, and is entirely managed by a web interface, so it's easy to use. Setting up road warrior (laptop) VPNs is a bit ugly on the Windows side, but it's getting better all the time.

This is the best solution we've found for allowing remote users to connect via Outlook. It means there are no open ports on the firewall, and it has zero incrimental cost.

Until the connector provides an integrated solution, And that will be a while as Dave outlined above, this alternative is the one I use and recommend. It just works.

Be aware, the VPN creates some overhead. This borders on being useless over a 56K dial up connection, and there's a HUGE performance hit for even a broadband connection. I believe Scalix is looking to add client side caching to an upcoming release, which should make this work far better, particularly on slow connections.

[kali]

Just my 2 cents here... But authentication is "secure" (as has been indicated many times) and yes - the data stream would be unencrypted. That said - 99% of the mail is arriving and departing over unencrypted channels anyway (smtp to/from others). So, other than possibly sensitive internal mail - it is worth asking how far to go to encrypt all traffic (which arguably has already gone plain text across the internet anyway).

Not that it's useless, but worth asking the overall cost/benefit questions, and being perhaps somewhat realistic given the current environment for mail delivery. Obviously, secure authentication is critical by any standard and in this day, plain text authentication should not be allowed.

[bproven]

Yes, I agree email is already passing unsecure around the i-net. And yes the scalix authentication is encrypted - that is good. My concern would be the groupware stuff. What if someone had sensitive information in a calendar, task, contact, etc.? This is traveling across the i-net unencrypted. I would like to avoid that if possible and exchange lets me do that using http/rpc.

On another note, I was successfully able to pass the 5729 over a secure port between client and server. We installed stunnel windows binary on the client forwarding all outbound over a fictuous 5730. On the server side (scalix) I configured stunnel to listen on 5730 and forward to 5729. Seemed to work and encrypted this traffic over the i-net.

Just ran into one problem. I found out that Scalix doesn't support offline public folders in the outlook connector - that killed my evaluation. Now it looks like I have to stay with Exchange ( :cry: ) unless I can get this feature in scalix. Bummer.

[aenternet]

An integrated solution to this mobility issue would indeed be a huge asset to the Scalix future. You're all right - the majority of email delivery today happens in the clear, even though the initial auth may be encrypted. Aside from Banks, Hospitals, Feds, proprietary info, the rest of us really don't seem to care much about that. Having said that, it *would* be nice to have the whole session encrypted point-to-point. That would solve the overhead issues with VPNs in terms of time configuring them, and the additional load / lower performance.

...just another 2 cents. Scalix would be way ahead to be working on this ASAP. 8)

[florian]

Thanks for all the useful input in the thread; this is very helpful for our ongoing product planning.

I believe I can positively confirm that we're working on upgrading the available options for connecting Outlook to Scalix Server in a secure way for situations when a VPN cannot be used. I can't give any final statement though on when these will become available.

We certainly want to make deployment of such a solution easier - and, by choice of protocols, etc. eventually more secure - than Microsoft's current solution for Exchange that usually requires more infrastructure than full VPN access.

Also, we're absolutely committed to even further enhance your offline working experience; stay tuned!

-- Florian.

[les.piggot]

We currently use ssh port forwarding (using Vandyke's EnTunnel) on our remote laptop but also tweak the hosts file.

The UAL Ports are forwarded on the laptops to the internal name of the Scalix Server
The Hosts file is updated so that the internal name of the Scalix server points to localhost

i.e.

Outlook -- port 5729 --> scalix.domain.com:5729--> localhost:5927--> SSH Tunnel --> scalix.domain.com:5729 (referenced by IP address)

So far everything seems to be working properly as it can connect etc. LDAP post is also forwarded so that the address books are also available

Les

[R1200GS]

In regards to "RPC/HTTP" like functionality (or more so, UAL/ HTTPS)

How does one handle ports in use?

I've gotten all this working very nicely but it appears that each clients remote source port must unique. I don't wanna do port managment (x3 = UAL, Free/Busy, LDAP)

Am I missing something here??