This will be ideal setup to start with. This removes the security concern we had with the single federation server. The Web Application Proxy server will be the initial contact from the external network and it will relay requests in and out from the internal AD FS server. This is still not going to provide high availability as each role holder only runs one server:

In this setup, we can separate the network functionality into perimeter and corporate networks. In the firewall, there will be following NAT and access rules:

• Map external IP address to myapp.rebeladmin.com so users can make initial request from external networks. It is recommended to use the TCP 443.
• Map external IP address to secure.rebeladmin.com and map it to IP address of Web Application Proxy server and open the TCP 443 from external to allow access.
• Allow access from Web Application Proxy server to AD FS server in the TCP port 443.

In the preceding example, once the external user accesses the application URL, it will redirect to the Web Application Proxy server. This doesn't need to be domain join as it operates from perimeter network. Proxy servers should be able to resolve the DNS name for the AD FS servers from the perimeter network. It can be done using a DNS server or a hosts file.

Similar to the previous model, this can be implemented with NLB to allow future expansion with minimum impact. We need two NLB clusters for that. The first cluster is for the Web Application Proxy and the second NLB cluster is for AD FS servers. The only change will be in the DNS records. Instead of pointing DNS and firewall rules to the server IP addresses, it needs to point to NLB cluster IP addresses: