I recently ran into a deployment problem for a customer where we attempted to use just two network interfaces for a single Edge Server configuration. If you follow the deployment documentation for the Office Communications Server 2007 Edge server, you'll see that they require the Edge server to have up to four separate network interface ports, one for internal and one for each of the three Edge Server Roles. From a network bandwidth standpoint in a high-usage scenario this many interfaces can be helpful, but when installing a single Edge Server containing all 3 roles it could be more efficient to potentially reduce the amount of hardware requirements.
Since the new hardware we were using to deploy the Edge server currently only had a single dual-port network interface (the additional card was back-ordered), we decided that we would locate the public IP address for the A/V Edge Server on one port, and then include the remaining three IP addresses for the Edge Access Server, Web Conferencing Server, and host's primary "internal" address all on the second port, like so:
NIC #1
10.1.1.10 - Host
10.1.1.11 - Access Edge Server
10.1.1.12 - Web Conferencing Edge Server
NIC #2
12.1.2.34 - A/V Edge Server
Because the host's internal IP and the two NAT-compatible Edge IPs are in the same subnet, then Windows Server will allow them to be bound to the same physical interface. The router that NIC #1 is plugged into was configured to route traffic to/from 10.1.1.10 back to the internal firewall, but route traffic for the other .11 and .12 addresses to the external firewall which was set to NAT both behind dedicated public IP addresses. The second interface would be connected to a dedicated port on the external firewall appliance and traffic would be routed without any address translation directly to the Edge Server.
After deployment and configuration of the Edge Access role I was having problems getting external clients to successfully login to OCS. I rechecked the configuration and all the settings were correct, the certificates were assigned and working, and there were no IP routing issues. I could telnet to both ports 443 and 5061 on both the Edge and Front-End servers from any location on either side of both firewalls. Using performance monitor on the Edge server I could see the inbound connections coming in from the external clients, but the connection was failing to make the next-hop to the internal pool. The complete lack of errors or warnings in the event log didn't help much either.
The next morning my client notified me that the additional dual-port NIC had arrived and was installed, so I went about reconfiguring the network utilizing a third interface:
NIC #1
10.1.1.10 - Host
NIC #2
12.1.2.34 - A/V Edge Server
NIC #3
10.1.1.11 - Access Edge Server
10.1.1.12 - Web Conferencing Edge Server
At this point Office Communicator on the external test client connected immediately. So even though my internal and external IP addresses are on the same subnet and both interfaces connect back to the same router, OCS apparently requires separate physical interfaces or will just not function correctly.
Theoretically the first configuration should have worked, but I originally had my reservations about whether OCS would not like the internal and external route sharing the same physical interface, even though I saw no connectivity problems between the Edge and Front-End servers over various ports.