Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Have Win2008 Terminal Server. Works fine if only public NIC is enabled.

But you want to enable the private NIC as well. What happens? Boom, nobody can access the Terminal Server (via public NIC).

Have tried:

  • Setting a persistent static route (didn't work)
  • Giving the private NIC a higher metric (didn't work either)
  • Setting "Consider Unidentified networks as private" in local security policy (Computer configration -->Windows Settings -->Security Settings -->select Network list manager policies)
  • Enabling weakhostsend/receive mode on each interface, as follows: (didn't work either)
    netsh interface ipv4 set interface "Private NIC" weakhostsend=enabled store=persistent
    netsh interface ipv4 set interface "Private NIC" weakhostreceive=enabled store=persistent
    netsh interface ipv4 set interface "Public NIC" weakhostsend=enabled store=persistent
    netsh interface ipv4 set interface "Public NIC" weakhostreceive=enabled store=persistent

None of these worked.

route print output:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    111.222.333.1   111.222.333.99     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
    192.168.244.0    255.255.255.0         On-link     192.168.244.1    502
    192.168.244.1  255.255.255.255         On-link     192.168.244.1    756
  192.168.244.255  255.255.255.255         On-link     192.168.244.1    756
    111.222.333.0    255.255.255.0         On-link    111.222.333.99    276
   111.222.333.99  255.255.255.255         On-link    111.222.333.99    276
  111.222.333.255  255.255.255.255         On-link    111.222.333.99    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link    111.222.333.99    276
        224.0.0.0        240.0.0.0         On-link     192.168.244.1    756
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link    111.222.333.99    276
  255.255.255.255  255.255.255.255         On-link     192.168.244.1    756
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0    111.222.333.1       1
    192.168.244.0    255.255.255.0    192.168.244.1       2
===========================================================================

Update: After the suggestion below, I checked the binding order and corrected it. This made it work -- until the server was restarted.

After a reboot, nobody could connect again. The binding order is still correct, with Remote Access Connections followed by Public NIC followed by Private NIC.

The difference is, AFTER THE RESTART, the Persistent Routes order in route print above reversed itself. So it becomes:

Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
192.168.244.0    255.255.255.0    192.168.244.1       2
0.0.0.0          0.0.0.0    111.222.333.1       1

Any ideas on how to get the previous Persistent Routes order to stick?

share|improve this question
    
I assume you have removed the Default Gateway from the internal NIC? –  Vick Vega Mar 25 '11 at 21:40
    
Yes, default gateway is blank on the internal NIC. –  ane Mar 25 '11 at 22:07
add comment

2 Answers

up vote 2 down vote accepted

Have you looked at the network adapter binding order, maybe there is something wrong is this case?

share|improve this answer
    
Thanks shadowman12, that was it! The network binding order was the reversed of what it should of been, with the Private NIC hogging the top spot. I moved "Remote Access Connections" to the top, followed by "Public NIC", followed by "Private NIC". It works! For those wondering how to get to the binding order settings, go to Start - Run - ncpa.cpl - Advanced menu - Advanced. –  ane Mar 23 '11 at 22:08
    
HOLD ON -- UPDATE -- after a reboot, nobody could connect again. The binding order is still correct, with Remote Access Connections followed by Public NIC followed by Private NIC. The difference is, AFTER THE RESTART, the Persistent Routes order in route print above reversed itself. So it becomes 192.168.244.0 ... Metric 2 followed by 0.0.0.0 Metric 1. Is there any way to get the Persistent Routes order to stick? –  ane Mar 24 '11 at 13:55
    
You can do route add -p. Have you done that? –  Guido van Brakel Mar 24 '11 at 16:23
    
Yes, both routes are persistent and were created with route add -p. But the order of the persistent routes is reversed. How can I get the persistent routes to show up in the correct order - across reboots? –  ane Mar 24 '11 at 21:34
    
I even added each individual interface to the end of the route add -p - it still only works if the Persistent Routes order in route print is 0.0.0.0 on the first line, and then the 192.168.244.0 on the second line. After every reboot, the order is reversed and the private network is unroutable. –  ane Mar 25 '11 at 22:00
show 4 more comments

Try put the network cables/settings of the public network on the nic used on the private and viceversa... I fixed it this way

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.