The article called "An Overview of System Security" contains the following diagram.

I wrote then

"It is likely that an implementation will require you to think about how users will access the system from beyond the corporate network. In these circumstances Sage CRM's web server is likely to be placed within the organisations Demilitarized Zone (DMZ). This can be either a implemented as a physical or logical subnetwork that exposes the web server to the Internet."

These are some additional thoughts that should help understand this diagram a little more.

1)

A third party load balancer will typically have the capability to root requests to wherever you want. This might be based on the originating IP range. Within a Sage CRM environment with multiple CRM servers then some requests will be routed to one server and another to another server. The different instances of the CRM server could be within different areas of the corporate network.

One or more of the Sage CRM instances could be added to the DMZ.

Multiple instances of Sage CRM/IIS would still require a multiserver Sage CRM license and if you want everyone user to be using the same 'system' then the database would have to be the same. The instance would need to be able to create a TCP/IP connection to the database server (the eWare DLL, via ADO and the SQL Server client tools will use TCP/IP as a first option by default). It is assuming that their database server is in the main network segment rather than the DMZ.

A customer would need to carefully consider the Sage CRM user and database user permissions.

This is similar to the example Self Service architecture I have discussed in other articles. This should be fairly secure because you can not 'spoof' IP addresses as part of a HTTP request. Therefore there are actually two requests involved meaning that the IP would be validated.

If a mixed implementation with different instances in different segments of the corporate network including the DMZ they this is likely to prevent them using the IIS autologin feature, or other Active Directory features. There may be some scope for more investigation around this area.

But you don't actually have to have all users go through the same load balancer or even go through it at all as some users could just access Sage CRM via the hostname on the LAN.

NB. A network administrator may consider it better to have everything go through the same route e.g. the load balancer for consistency.

Also within a multi server Sage CRM environment where one or more of the Sage CRM instances are in different segments or the DMZ then the network administrator would need to consider where the document library needs to go and how authenticate on the library would be carried out.

2)

Then there are reverse proxies. There are products like CloudFlare (that is just an example) that provide content delivery networks and distributed domain name server services. They sit between the user trying to access Sage CRM and the actual CRM servers acting and they act as a reverse proxy for Sage CRM.

This could be designed to 'port forward' requests through the DMZ to the CRM server.

You could also proxy HTTP requests to the CRM server using URL Rewrite (Application Request Routing) from an instance of IIS installed in the DMZ. This is quite a common practice. But the main potential issues would be the need to add the host-name that is used to access Sage CRM to the hosts file on the actual Sage CRM server so that it resolves locally. This is to prevent confusion with Sage CRM's own proxy's requests to the CRM web apps.

Care would need to be taken not to be over complex with Sage CRM's rewrite rules as this is a common area that generates support issues.