There are several possible explanations to this problem. Your network may be running a firewall or your computer may be behind a router. See the section on I am connected to the internet through a router. How should I configure my router to allow FTP traffic? for more information.
If you are using a router with Cable or DSL to connect your home computer to the internet, you may need to enable Port Forwarding. Consult your router documentation on how to enable Port forwarding for FTP.
Finally, if you can, instruct your clients to connect using passive FTP mode (initiated by the client using the PASV command). Active FTP (initiated by the client with the PORT command), tends to cause problems with older hardware routers and software firewalls.
Q2: I'm running Cerberus FTP Server as a service and it can't access mapped network drives or UNC path. Why?
Mapped Drives, UNC paths, and Services
Mapped drives are established on a per-user basis and are only restored when a user logs in (also called an interactive login). Cerberus FTP Server runs as a Windows Service, and persists outside of a logged in session. This allows Cerberus to run even when no users are logged into the system, but it also means that Cerberus cannot access a user's mapped drives. This is not a limitation of Cerberus FTP Server, but a restriction imposed by Windows on all programs that run as a Windows Service.
However, Cerberus can access network shares using the standard UNC path format - provided the Cerberus Windows Service has permission to access that network share. The default configuration for a Windows Service uses the Local System account. While this account has broad access to the local machine, it does not have permission to access resources on a network unless that resource requires no authentication. This can present a problem for accessing network shares using UNC paths.
There are two solutions to this problem:
The first solution is to always use the UNC path to access the network resource, and to make sure the Windows Service account that Cerberus is running under has permission to access that share. By default, the Local System account can only access anonymous or null shares (shares that require no permissions). If the Local System account does not have permission to access the network share, the Cerberus log file will likely show an access denied error, or simply be unable to find the network path.
If you see an access denied error, you will probably need to change the Cerberus FTP Server Windows Service to use an account that has permission to access that share. You can change the service account that Cerberus runs under using the following instructions:
Changing the Cerberus Windows Service Account
You can manually change your service's account by viewing its properties in the Services system component.
To open Services, click Start, click Control Panel, click Administrative Tools, and then double-click Services.
- Open Services
- Right-click the service to which you want to assign a user or group account, and then click Properties.
- Click the Log On tab, and then do one of the following:
- To specify that the service use the Local System account, click Local System account.
- To specify that the service use the Local Service account, click This account:, and then type NT AUTHORITY\LocalService.
- To specify that the service use the Network Service account, click This account:, and then type NT AUTHORITY\NetworkService.
- To specify another account, click This account:, click Browse, and then specify a user account in the Select User dialog box. When you are finished, click OK.
- Type the password for the user account in the Password box and in the Confirm password box, and then click OK.
There are two caveats to changing the underlying service account.
• One is that the existing Cerberus settings files were created under the Local System account, so switching the Cerberus Windows Service to another account will probably mean that the service will not be able to overwrite the existing Local System account-created Cerberus settings files. This will lead to errors when the service tries to save and settings or user changes. The problem is relatively easy to fix. You just have to adjust the ownership of the Cerberus settings directory, and all sub directories and files in the directory, the new account running the service.
The Cerberus settings directory is located at:
C:\ProgramData\Cerberus LLC\Cerberus FTP Server
on Windows Vista, Windows 2008 and above
• The second issue is that the service will always be reset to use Local System account whenever you upgrade. You have to switch the service account back to the domain account after upgrading to a new version.
We've mentioned before that the Local System account has very limited capabilities to access network resources. However, Cerberus also has the ability to impersonate an actual logged in user and access network resources as if they were that user for the duration of a connection. This feature is accomplished using Active Directory authentication.
When a user logs into the server (through FTP/S, SSH SFTP, or HTTP/S) using an Active Directory account, Cerberus uses the provided username and password to authenticate the user account with the configured Windows domain and can then carry out all file operations for that user as if they were the actual user. This ensures that Windows enforces the correct file permissions for that user, and also allows the user to access any network resources that they would normally have access to.
You can learn more about configuring Active Directory Authentication in our online help
Q3: I've correctly configured passive FTP but passive data connections still fail. What else could be wrong?
Many of the newer, "smarter" routers and firewalls attempt to detect passive FTP traffic and automatically modify the FTP commands to work correctly with the router or firewall device. Specifying the public IP for passive command responses can cause problems with these routers and firewalls. If you are certain that you've correctly setup port forwarding and you are still having problems with passive FTP then this might be your problem.
One way to diagnose this issue is to monitor the log file from Cerberus and the FTP client as a passive connection is attempted. The log file excerpts below are from a connection attempt from a popular FTP client to Cerberus FTP Server. The client is located outside of the local network Cerberus FTP Server is installed on.
May 01 13:12:04 42 257 "/" is the current directory
May 01 13:12:04 42 TYPE A
May 01 13:12:04 42 200 Type ASCII
May 01 13:12:04 42 PASV
May 01 13:12:04 42 227 Entering Passive Mode (X,X,X,X, 7,255)
May 01 13:12:04 42 LIST
Command: TYPE A
Response: 200 Type ASCII
Response: 227 Entering Passive Mode (X,X,X,X,130,128)
The indication that the router is changing the FTP command is the difference in the ports listed between the client log and the server log. See "Steps to resolve" below for a solution.
Sometimes the router does not change the ports but still has problems when the external or public IP is used for the passive command. Many stateful packet inspection firewalls will deny the connection when they see the public IP address used in the FTP command. The firewall expects the local address to be used and will modify the FTP passive command in-route to use the public IP. If the public IP has already been specified then the firewall will often block the connection. See "Steps to resolve "below for a solution.
Steps to resolve:
To resolve either issue you have to change Cerberus FTP Server's PASV IP setting to be your internal LAN IP and not the external or public IP visible from outside your local network. You may need to perform these steps for each FTP interface.
- Go to Server Manager and select the Interfaces page
- Click on the FTP or FTPS listener that matches your internal IP. Do NOT select the Default FTP or FTPS listener. Modifying the Default listener will not change existing listeners.
- In the PASV Options section click the Specify PASV IP radio button and in the textbox that appears put in the same IP as the interface (your local IP address). i.e. If your local IP is 192.168.0.110 then make the passive IP 192.168.0.110.
- Click the Ok button
There are two possible problems, both relating to running Cerberus as a service. On Windows Vista and higher operating systems, you cannot access the Cerberus FTP Server GUI while running as a service when running versions of Cerberus prior to 3.1. You must first stop the service and start Cerberus as a normal application.
On Windows 2003 and earlier operating systems, this limitation is only present when running Cerberus as a terminal server session. When Cerberus is running as a Windows service, access to the FTP server window through a terminal server session is not possible. The reason for that conflict is because the Cerberus service always has to be running on the desktop of the console session. When connecting through terminal services, Windows creates a new self-contained desktop for the terminal server session, so the FTP server window cannot be accessed from that desktop.
You can solve this with one of the following solutions:
- Upgrade to Cerberus FTP Server 3.1 or higher
- Access the FTP server directly on the console screen rather than using a terminal server session to access the FTP server.
- Use a different remote access software (i.e. PCAnywhere or PCDuo) instead of a terminal server session to access the FTP server.
- Stop the FTP server service and start the FTP server in application mode by double-clicking the Cerberus FTP server icon on the desktop. That way you can also access the FTP server through a terminal server session. It is recommended to start the FTP server as a service again before you leave your terminal server session.
Connect to the console session:
To connect to the console session, administrators can choose one of the following methods:
- NOTE: This is no longer valid on Windows XP Service Pack 3, Windows Vista Service Pack 1 and Windows Server 2008.
- Use the Remote Desktop Microsoft Management Console (MMC) snap-in.
- Run the Remote Desktop Connection (mstsc.exe) program with the /console switch (or the /admin switch on some later versions of Windows).
- Create Remote Desktop Web Connection pages that set the ConnectToServerConsole property.
The short answer is that FTPS and firewalls (and devices performing NAT) do not always interact well. The control connection happens on a well-known port, and has no issues; it is the data connection that poses problems for FTP-aware firewalls. In a non-FTPS session, the firewall can inspect the FTP server's responses on the control connection to a client's PASV or PORT command, and thus know which on which ports/addresses the data connection will be established.
In an FTPS session, though, those control connection messages are encrypted, and so the FTP-aware firewall cannot peek. Hence, it cannot know on which ports the data connection will be established. For firewalls that are configured to always allow a certain range of ports (such as might be configured using passive mode), FTPS should function without issue.
To configure for passive FTP (the preferred method), see Q2: My IP address begins with 192.168.xxx.xxx. Is there anything special I have to do for people to see my FTP Server on the Internet?
Q6: I cannot use a remote share as an NT home directory when authenticating a user against a domain.
NOTE: This no longer applies to Cerberus FTP Server 18.104.22.168 or higher. The latest version of Cerberus FTP Server can now access virtual directories mapped to remote shares for domain users.
The following comments apply only for users using domain authentication to login to the FTP server.
The login method used to authenticate a user against the domain does not allow access to network shares. The technical reason is that the token granted through the logon method Cerberus is using is a network logon for the user with no network credentials. You can use the resulting token on the local machine, but can't impersonate a user using this token in order to authenticate with remote servers. When Cerberus tries, it ends up establishing a null session (how Windows represents an anonymous user) with the remote server instead.
There are two options to resolve the problem:
- Upgrade to Cerberus FTP Server 22.214.171.124 or higher, - or -
- Make the share anonymous.
See the Microsoft kb article 931130 about running with the "Routing and Remote Access" or the "Application Layer Gateway" service enabled. http://support.microsoft.com/kb/931130.
Normally, users are upgraded automatically from version 2.X when installing the latest Cerberus release. However, in some instances the users file is not upgraded and a manual upgrade is necessary. To manually convert over the old users file:
- Install the latest release of Cerberus FTP Server
- Locate the Cerberus FTP Server 2.X "users.pro" file, usually in C:\Program Files\Cerberus
- From the Cerberus FTP Server Tools menu, use the Restore Settings and Users option to import the old users file
You are probably using an FTP client that is neither RFC959 (the FTP standard) nor RFC2640 (International FTP) compliant. Some FTP clients incorrectly assume that text information will be transferred in their native character set. The FTP specification specifically states that all text will be transferred in ASCII or, for servers supporting the newer international FTP standard, UTF-8. Clients that make the assumption that text is being transferred in their native character set will see incorrect letters for non-Latin based characters.
The recommended fix is to upgrade to an FTP client that correctly supports UTF-8 encoding. FTP clients that support UTF-8 (and most major FTP clients do) will have no trouble with any file or directory name in any language or character set.
Another option is to turn off UTF-8 encoding for the client session. A client can do this by issuing an OPTS UTF OFF command after logging in. This will cause the FTP client to send text in whatever character set is native to the computer the server is running on. This is non-standard an not recommended. Upgrading to a client that supports UTF-8 is the better option.
The remote access settings control HTTP and HTTPS web administration and SOAP access to Cerberus FTP Server. When Cerberus is running as a Windows Service, the GUI connects to and communicates with the Cerberus Windows Service through a remote access API called SOAP. The Cerberus Windows Service listens for SOAP connections on the Port specified under the Remote settings page of the Server Manager. That port must be available for Cerberus to listen on or the GUI will be unable to connect to the local Windows Service.
Most users will never see the Remote Access connection dialog because it is only shown when the Cerberus GUI can't connect to the underlying Windows Service. This usually happens because:
- A DLL needs updating after installation and the service and GUI cannot communicate properly until it does
- --or-- The GUI and Windows Service passwords are out of sync (or one had never been set)
Before going any further, restart the machine to ensure the problem is not a DLL issue. This will usually fix the problem. If the problem persists after restarting, continue with the instructions below.
If a remote access password had never been set, or the UI password has been lost, then the UI may not be able to connect to the underlying Windows Service. The solution is to temporarily shut down the Cerberus Windows Service, start Cerberus in application mode, and then set a remote access password so that the GUI and Windows Service can communicate. Here are the steps:
- Open up the Service Control Manager and stop the Cerberus FTP Server Service. You will see "Cerberus FTP Server" listed in the services list. You can access the Service Control Manager by going into the Control Panel, selecting Administrative Tools, and then Services. Once the Service Control Manager is open, right-click on the Cerberus FTP Server service and select Stop.
- You can now start Cerberus in application mode by right clicking on the Cerberus FTP Server icon on the desktop, or through the Program Manager, and selecting "Run as Administrator". Cerberus should startup in application mode without any prompts for passwords. Selecting "Run as Administrator" is important to ensure the application is started with the correct privileges to save your changes.
- If you are prompted to start the Cerberus FTP Server Windows Service, select No.
- In Cerberus FTP Server, open the Server Manager and select the Remote page. There is a button to set an Admin password. Set it to anything you like and click Save to close the Server Manager.
- You can now go to the File menu and select Exit from the menu. This will shut down Cerberus FTP Server and close the application.
- Restart the Cerberus FTP Server service from the Service Control Panel. Right-click on the service and select Start.
You should now be able to start and connect to Cerberus FTP Server normally by clicking on the Desktop application icon.
Q11: Why do I get an error when I try to enumerate Active Directory (AD) users through the
User Manager's AD page,
or why does AD authentication take so long?
If you are certain the domain name is correct then one problem might be a connection problem with certain Active Directory services. These can be a result of DNS problems on the server running Cerberus FTP Server, or internal firewall problems reaching certain AD services on the Domain Server. The Microsoft APIs use several different protocols to query AD, and if those protocols are not properly traversing internal firewalls and can't communicate with the Domain Server, then enumeration can fail. The SMB protocol can sometimes be the problem. Try checking that you can reach port 445 on the Domain Server from the machine running Cerberus FTP Server.
Other symptoms of communication problems with the Domain Server are long delays while trying to authenticate a domain user. Ensuring the appropriate ports are open for communication with the Domain Server, and that DNS is correctly configured for the domain, can make a dramatic speed improvement in the time it takes to authenticate a user via Active Directory (from 30 seconds or longer to less than a second).
SFTP will almost always be significantly slower than FTP or FTPS (usually by several orders of magnitude). The reason for the difference is that there is a lot of additional packet, encryption and handshaking overhead inherent in the SSH2 protocol that FTP doesn't have to worry about. FTP is a very lean and comparatively simple protocol with almost no data transfer overhead, and the protocol was specifically designed for transferring files quickly. Encryption will slow FTP down, but not nearly to the level of SFTP.
SFTP runs over SSH2 and is much more susceptible to network latency and client and server machine resource constraints. This increased susceptibility is due to the extra data handshaking involved with every packet sent between the client and server, and with the additional complexity inherent in decoding an SSH2 packet. SSH2 was designed as a replacement for Telnet and other insecure remote shells, not for very high speed communications. The flexibility that SSH2 provides for securely packaging and transferring almost any type of data also contributes a great deal of additional complexity and overhead to the protocol.
However, it is still possible to get a data transfer rate of several MB/s between client and server using SFTP if the right network conditions are present. The following are items to check when trying to maximize SFTP transfer speeds:
- Is there a firewall or network device inspecting or throttling SSH2 traffic on your network? That might be slowing things down. Check you firewall settings. We've had users report solving extremely slow SFTP file transfers by modifying their firewall rules.
- The SFTP client you use can make a big difference. Try several different SFTP clients and see if you get different results.
- Network latency will drastically affect SFTP. If the link you are on has a high degree of latency then that is going to be a problem for fast transfers.
- How powerful is the server machine? Encryption with SFTP is very intensive. Make sure you have a sufficiently powerful machine that isn't being overtaxed during SFTP file transfers (high CPU utilization).
Q13: Why do I see "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full." error mesasges in the log file?
This error message comes from Windows network API calls, rather than Cerberus FTP Server directly, and has two well-understood root causes. However, it still stumps people because there is no single source which easily explains both root cause and offers a solution. This error is usually the result of the server's resources being exhausted by too many server processes (database and file servers, web and FTP servers, and any other server process which accepts connections) running on the machine . We've also heard of it happening on some buggy virtual machines.
Here are two common situations where you may see this error, and quick solutions for each:
OS runs out of memory for TCP buffers
When a powerful client machine, especially one with lots of RAM, is running an x86 version of Windows, administrators sometimes use the /PAE switch in the c:\boot.ini file to allow applications on that machine to be able to address the full range of memory. One other switch often used to give more memory to applications is the /3gb switch in the boot.ini file. The problem comes when these two are combined: the /3gb switch gives more memory to applications by reducing the amount of memory available to the OS. When it is used on a powerful machine where the applications require many OS resources, such as by opening many TCP connections, this can cause the OS to run out of memory for resources like TCP buffers. When that happens, Winsock throws the error WSAENOBUFS.
Solution: Remove the /3gb switch from c:\boot.ini. The root problem in this case is memory pressure on the OS, so removing the /3gb switch will give more memory to the OS and will alleviate this problem.
OS runs out of available TCP “ephemeral” ports
When the machine is opening many TCP connections and is running Windows Server 2008, 2003, Windows XP, or any earlier version of Windows, it may run out of TCP “ephemeral” ports. In Windows Server 2003, Windows XP, and earlier versions, Windows limits the number of available ephemeral ports to approximately 5000 across the machine. It is especially common to hit this problem for applications which do not use connection pooling.
Solution: To make more ephemeral ports available, follow the directions in this KB which describe how to create the MaxUserPort registry key: http://support.microsoft.com/kb/196271
If neither of the above solutions apply or fix the problem
The simplest fix is to reduce some other service process or move it to a dedicated machine but there are some other tips you can follow with Cerberus FTP Server to reduce the likelyhood of this issue occurring.
This error is related to high levels of network traffic on your server and you can reduce local network traffic by not leaving the Cerberus GUI open when you are not using it to administer the server. When running as a service, Cerberus is split into two processes. One process is the Windows Service that is always running and doesn't have a GUI, and the other is started whenever you launch the Cerberus GUI. The Windows Service and GUI communicate over a protocol called SOAP. It's an HTTP/S-based protocol for remote communication.
On the service side, there is SOAP service waiting for connections on port 10001 (the default). When the GUI is started it begins connecting to the service and exchanging data back and forth. This happens anytime the GUI requests data from the server. This happens about every 1 - 2 seconds to retrieve status information from the service and anytime you open or close server or user manager pages. Currently, a new connection is opened and closed for each operation and this additional local traffic on an already taxed sever can eventually exhaust ephemeral ports.
There is no SOAP traffic when the server is started in application mode(not an option for most people), and no SOAP traffic when the server is started in service mode and the GUI is not running. As long as you shutdown the GUI when you are not administering the server then local network traffic will be significantly reduced and this should help with the queue full error.
If an internal NIC is not being properly detected then you can manually specify an IP to bind to in the Cerberus FTP Server. There are two ways to accomplish this.
The easiest method to add additional IP addresses to bind to is to go the Advanced page of the Server Manager in Web Administration. There is an edit box where you can specify additional IP addresses to bind to.
The other option is to directly modify ons of the Cerberus FTP Server configuration files to add the additional IP addresses.
- Shutdown the Cerberus FTP Server Admin Console from the File menu and select Exit.
- Go to the Services control panel in Windows (accessible from Administrative Tools in the Windows Control Panel) and stop the Cerberus FTP Server Windows Service. This step is important.
- Open the file settings.xml under:
C:\ProgramData\Cerberus LLC\Cerberus FTP Serveron Windows Vista, Windows 2008 and above
C:\Documents and Settings\All Users\Application Data\Cerberus LLC\Cerberus FTP Serveron Windows 2003, XP, and 2000.
- Look for the <manualInterfaces></manualInterfaces> or <manualInterfaces/> XML tag
You can add a list of comma separated IP address. For example, to add the IP address 126.96.36.199 and 188.8.131.52:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <cerberus> <settings version="1.0"> <interface> <manualInterfaces>184.108.40.206, 220.127.116.11</manualInterfaces> </interface> </settings> </cerberus>
- Save the settings.xml file and then start the Cerberus FTP Server Windows Service.
Q15: IE7 and IE8 browsers on Windows XP and 2003 get an error when they try to connect to the HTTPS web client. How do I fix it?
This appears to be a problem with the cipher suites present with SChannel on XP and 2003. Firefox, Chrome, and Opera don't use SChannel and therefore don't have this problem.
Enabling FIPS 140-2 mode from the Security page of the Server Manager will restrict Cerberus to only using the TLS cipher suites and will resolve the problem for IE clients.
Q16: Files Uploaded through the HTTP/S web client can only be modified by the user that uploaded the file.
Files uploaded using the HTTP/S client are first created in the temporary files directory for the user account. The file is then moved to the destination directory after the upload is completed. Because the file is created in the temporary files folder, the permissions for that file are inherited from that directory. This can sometimes cause problems for users that log in using Active Directory authentication.
Take a look at the temporary files folder, and try modifying the default permissions for that folder to have the desired permissions to allow all AD users read/write permission. The temp folder would be the temporary files folder associated with the account of the AD user, for AD authenticated users, or the temp folder associated with the service account running Cerberus, for native users.
It could be:
on Windows 2008 R2 for AD users, or
For the Local System account. Many systems are configured so that even the AD users temporary files are created in
Cerberus FTP Server 6.0.1 now includes the ability to override the default location where temporary HTTP upload files are created. You can access this setting in the Advanced page of the Server Manager. A reboot of the server is required after changing the temporary HTTP upload folder location.
Active Directory (AD) users are impersonated by Cerberus when they login to the server. User impersonation means that all file access and file operations carried out by that AD user are done as if it were the actual AD user logged into the machine and carrying out those operations.
For native Cerberus users, there is no impersonation going on. The Cerberus FTP Server Windows Service is performing file access operations under whatever account is running the service. Cerberus runs under the Local System account by default. This means that directories and files are created under and owned by the Local System account whenever Cerberus users perform file operations.
Problems can occur because AD users usually do not have permission to delete files or directories created under the Local System account. This problem is common when mixing AD users and native users.
One solution is to run the Cerberus FTP Server Windows Service under a different account from Local System. Perhaps under a domain user account.
There are two caveats to changing the underlying service account. One is that the existing Cerberus settings files were created under the Local System account, so switching the Cerberus Windows Service to another account will probably mean that the service will not be able to overwrite the existing Local System account-created settings files. This will lead to errors when the service tries to save and settings or user changes. The problem is relatively easy to fix. You just have to adjust the ownership of the Cerberus settings directory and all sub directories and files to the new account running the service.
The settings files are all in
C:\ProgramData\Cerberus LLC\Cerberus FTP Server
on Windows Vista, Windows 2008 and above
The second issue is that the service will always be reset to use Local System account whenever you upgrade. You have to switch the service account back to the domain account after upgrading to a new version.
Q18: Why can't public file links shared by Active Directory users be downloaded? An "Access Denied" error appears in the log when an anonymous connection tries to download the publicly shared file link.
The server will impersonate Active Directory (AD) users when they login, and carry out all server operations as that AD user. The server does not impersonate an AD user when an anonymous connection is established to download a publicly shared file. The connection accessing the publicly shared file is accessing that file under the same account the Cerberus FTP Server Windows Service is running under.
The account that the Cerberus FTP Server Windows Service (the default is Local System) is running under has to have read permission on the publicly shared file to allow the anonymous connection to open and download the file.
Another common problem occurs when files are on a NAS or network share. AD users have permission to access the network share, but the Local System account that Cerberus FTP Server runs under often does not have network priviledges. The solution is to run the Cerberus FTP Server Windows Service as another account that has permission to access the network share. Take a look at this FAQ entry for common issues encountered when changing the underlying Cerberus Service account.
If you are having issue sending email outside of your email domain, your Exchange server may not be setup to relay email. There are some simple steps outlined below that you can follow to add a connector that can relay email outside of your organization:
- Create a new Receive Connector, name it whatever you want (we use the name TEST in the example below), and then select "Custom" for the intended use for the receive connector.
- On the Local Network settings, leave it as is. It will listen on all local IP's on port 25.
- On the Remote Network Settings, clear 0.0.0.0-255.255.255.255, and then add the IP Address of the remote server that requires relaying permissions.
- Once the new Custom Receive Connector is created, go into the properties of this connector, go to the Permission Groups Tab and Add "Anonymous Users".
Issue the following cmdlet to allow anonymous users to relay via this connector :
Get-ReceiveConnector “TEST” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
Thia command retrieves the receive connector that you created, adds a permission into Active Directory for the Anonymous Logon group, and assigna that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector.
Why should you create this new connector? Exchange will always look to see how specific you are on a connector. For example, if you have a SharePoint Server at 192.168.10.125. We would create a relay connector and allow ONLY 192.168.10.125 to relay. When Exchange receives SMTP from an address of 192.168.10.125, it will see there are a few connectors. One being the Default Receive Connector and one being the Relay Connector.
The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.10.125. Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint, and your SharePoint Server will now be able to relay off of Exchange.