SME Server Local Networks and VPN's

Understanding the Default Mail Restrictions in SME Server

SME Server, the popular Linux distribution that replaces the older E‑Smith, is built with a strong emphasis on keeping mail flow under tight control. When a client connects to the server from an address outside the local LAN, the mail daemon automatically refuses to relay any messages to external domains. This behaviour isn’t an arbitrary rule; it is a safeguard against the server being abused as an open relay for spam.

An open relay would let anyone on the internet send email through your server without authentication. In most cases that would trigger immediate blacklisting by major spam‑filter providers, and it would quickly tarnish your domain’s reputation. By blocking external relaying, SME Server forces users to either send mail directly from the server’s own machines or authenticate properly with the built‑in mail system.

When you first install SME Server, you see the “Local Networks” section in the Administrative browser. That list defines the ranges of IP addresses that are considered safe for direct mail relaying. Every machine inside those ranges can use the server as a relay without authentication, and the server will happily forward their mail to the outside world.

For most small businesses, the default list is limited to a single subnet, such as 192.168.0.0/24. If you only have a few workstations on that network, this setup works perfectly. However, in a modern environment you often need to allow other networks - sub‑nets on a separate VLAN, a remote office, or a set of devices that connect through a VPN - to have the same freedom. In that case you need to add the new ranges to the “Local Networks” list.

Adding a new network is straightforward. Log into the Administrative browser, navigate to the “Local Networks” tab, and click the “Add” button. A dialog will prompt you for the network address and subnet mask. For example, if you have a remote office on 10.20.30.0/24, you would enter 10.20.30.0 for the address and 255.255.255.0 for the mask. Once you hit “Save,” the server recognises those machines as part of the local domain and will permit mail relay.

When you add multiple networks, keep an eye on the ordering. The server scans the list from top to bottom, so if two networks overlap you might inadvertently block legitimate traffic. If you need to allow a subnet that partially overlaps with an existing one, place the more specific entry higher in the list.

Another point to consider is that the “Local Networks” list is separate from the firewall configuration. Even if a machine is in the approved range, it still must pass through the firewall rules to reach the mail port. Most default installations allow all traffic on the internal interface, but if you have custom rules you might need to add a rule permitting SMTP (port 25) from the new network.

Beyond the immediate impact on mail relay, updating the Local Networks list also affects other services that rely on local address verification. For instance, SMB/CIFS shares, printer queues, and web applications that use local authentication can all treat those IP ranges as trusted. If you encounter unexpected access problems after adding a network, double‑check that the address ranges are correct and that the firewall permits the necessary traffic.

In practice, the process of extending local network access is one of the easiest ways to maintain control over who can send mail through SME Server. It keeps the system secure, prevents accidental spam, and offers the flexibility needed for modern, distributed work environments. By keeping the list up‑to‑date and making sure the firewall rules line up, you’ll have a robust mail flow that meets both security and usability goals.

Extending Secure Mail Access to VPN Clients and Subnets

When the business grows, many organizations turn to VPNs to give remote workers a secure channel into the corporate network. A VPN typically routes traffic through a private IP space - often 10.x.x.x or 192.168.x.x - so that remote machines appear as if they sit inside the internal LAN. However, that convenience can create subtle routing pitfalls, especially when users try to access the mail server from their client applications.

Consider a remote site that connects to your SME Server over the internet. The VPN client on that site pushes a default route that points all traffic to the VPN gateway. At the same time, the client’s routing table still contains a direct route to its own local subnet (for example, 192.168.2.0/24). The problem arises when a user’s email client, such as Outlook, is configured to use a public hostname like mail.xyz.com. The client will resolve that hostname to the server’s public IP address, and the resulting traffic will leave the VPN tunnel and travel over the public internet. The mail server receives the request from the public IP, which is not on the approved Local Networks list, so it rejects the connection.

Because the VPN tunnel is meant to keep traffic inside the private network, the user should instead point the mail client to the server’s internal IP address, such as 192.168.3.1. The internal address exists only on the corporate LAN, so traffic destined for it will stay within the VPN tunnel. From the perspective of the SME Server, the connection appears to come from the 192.168.2.0/24 network, which has already been whitelisted. The server then accepts the connection and allows mail relay without any authentication, just like a local workstation would do.

Implementing this fix requires a few adjustments on the remote site. First, locate the VPN client configuration file or the GUI that manages the tunnel. Look for the “DNS suffix” or “hostname resolution” settings. You’ll want to set the SMTP server hostname to the internal address. In Outlook, open the account settings, find the server address field, and replace mail.xyz.com with 192.168.3.1. If the server uses SSL on port 465 or STARTTLS on port 587, make sure the client still points to those ports on the internal IP.

Another consideration is the VPN gateway’s own routing. The gateway should have a static route that sends any traffic to 192.168.3.0/24 back to the SME Server over the VPN link. If that route is missing, the traffic will attempt to reach the internal network via the public internet, which defeats the purpose of the tunnel. Verify that the gateway’s routing table contains the correct subnet entries before pushing clients into the environment.

For those who prefer to keep the external hostname, an alternative is to set up split tunneling on the VPN. In split tunneling, only traffic destined for the corporate subnets goes through the VPN; all other traffic goes directly to the internet. This allows the mail client to resolve mail.xyz.com to the public IP while still keeping internal traffic inside the tunnel. However, split tunneling can expose the VPN to certain security risks, so it should only be used after a thorough risk assessment.

Beyond Outlook, other mail clients - Thunderbird, Apple Mail, or mobile mail apps - face the same issue. The key is to ensure that the server address used by the client is the internal IP, not the public one. In environments where the corporate domain has both internal and external DNS records (for example, mail.xyz.com for internal and mail.xyz.com for external), you might need to create a split‑DNS setup. In this configuration, the VPN client’s DNS server resolves mail.xyz.com to the internal IP, while external clients see the public IP. Most VPN providers support pushing a custom DNS server to connected clients, making this approach straightforward.

Once the internal address is in place, the mail server will accept connections from the VPN clients just like any other local machine. The user experience remains unchanged, but the underlying traffic stays encrypted and confined within the corporate network. This approach also protects the SME Server from accidental or malicious exposure through the public interface, keeping the mail flow secure.

In summary, allowing VPN clients to relay mail through SME Server hinges on two simple adjustments: (1) add the VPN subnet to the Local Networks list in the Administrative browser; (2) configure client mail settings to use the server’s internal IP address. By keeping the routing tables correct and the DNS resolution consistent, you can provide remote workers with seamless access to corporate email without compromising security or reliability.

For more detailed guidance on configuring SME Server, or if you need help tailoring the setup to your specific environment, you can consult resources like pcunix.com, which offers expert advice on Unix and Linux systems.