Friday, October 16, 2009 9:44 PMI have a test server running Windows Server R2 running RRAS. It has two NIC cards. One NIC is connected to the public network and one to the domain network. The default gateway is on the public NIC. This is to test incoming VPN connections from the public side and is strictly a test. I want to use the advanced firewall to restrict ports to the machine by location (e.g. block all public except for VPN required ports).
The network location for both NIC's is set to "Domain". Further, it lists both NIC's to the right of the Domain Network icon so each NIC doesn't have a "location" per se.
I've modified group policy to allow the editing of locations (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Network List Manager Policies, All networks, network location -> User can change location)
Even after forcing a gpupdate I cannot change the location.
The DNS entries for both NIC's is the internal DC.
Any way to get this value where I can change it? How can I get NLAS to properly recognize the network? Clearly the public IP is not a "Domain Network"!
Saturday, October 17, 2009 2:21 PM
I think that the design of this feature is flawed. There appears to be a cache of tests done in stored in the registry and even when I have been able to hack a machine to change it the way it should it gets overriddden by the NLA service. On a server I should be able to define the network profile as more restrictive without having to change every rule in the Windows Advanced Firewall or hack the registry. I should be able to click on the profile and change it. I can even do this on my Windows 7 machine!
I can see how NLA is very useful for a desktop machine...but these are servers. An administrator should be able to define the profile and configure the firewall to lock down that profile. Some machines on a domain network we may want to have set to a public profile. That is an administrator's privilege (note the role, administrator).
Of course, maybe I'm just missing a simple thing on how to change this "feature" and set the profile manually?
Monday, October 19, 2009 10:15 AM
Thanks for the post.
Here is something we need to understand on this issue:
1. By default, Windows Server 2008 and Windows Server 2008 R2 use Network Location Awareness service (nlasvc) to identify networks and find the associated saved settings for the network, the NLA service will use a Default Gateway or SSID to identify a network. This identification is conducted by system automatically due to security consideration. We cannot change the network profile manually. Otherwise, the server will be unsafe if a local administrator right is leak even we have domain group policy to define firewall settings in public profile. A hacker can change a public profile to domain profile to allow unwanted traffic.
2. In Windows 7 and Windows Server 2008 R2, more than one profile can be active at the same time according to which networks the computer is connected. As a result, if the server cannot contact the domain via the public NIC, it will not be identified to connect to domain network.
Now I am wondering if the system can contact domain via the public NIC. If so, this is the expected behavior. As you just need to do RRAS test, please connect the public network adapter to another network which could not contact DC.
Hope this helps.
Monday, October 19, 2009 7:51 PM
Here are my comments.
1. I can understand not allowing it to be changed from public to domain (or any more secure profile if you like). But this does not mean you cannot change a profile from domain to public to lock it down further. This is the way Server 2008, Vista, Windows 7 work but NOT Server 2008 R2. To say I cannot lock down the profile goes against what you're advocating. I want to change the profile to be a tighter security than what the system "detects" it should be. It also allows us to protect the system against an incorrect identification like we have now. So if the machine incorrectly identifies a public connection as domain you have a much greater security hole than worrying about someone hacking into the system. Essentially the "OS intelligence" just opened up all the ports for the hacker. Based on the inability of the system to correctly identify the location I'd prefer to just have to worry about the hacker . Further, the default behavior in the system is that when a program or role is installed it opens up a hole in the firewall to listen on the port, normally for all profiles (just dumb). So the idea that the "OS knows best" is a falacy at best. Frankly, I'd much rather worry about a hacker than the OS "automatically" detecting the right security model.
2. No, the domain is absolutely NOT available via the public NIC. I've verified this by plugging it into another non-domain machine with a cross-over cable, connected it to a true public connection, and connected it to a separate, non-related network. The default gateway is set to the public default gateway and yet NLA says it is still a domain network.
Monday, October 19, 2009 7:53 PMAs another thought, your point #1 says "By default". I just want to know how to turn it off. That should be documented.
Thursday, October 22, 2009 1:16 PMSo does a non-answer mean there is no way to disable the default behavior or change it when it is wrong?
Friday, October 23, 2009 2:39 PM
Were you able to determine how to apply different 'network locations' to your 2 different NIC's?
My scenario is similar to yours, except I simply need RDP (3389) and NOTHING else open on the WAN connection. However both the LAN and the WAN connection are identified as 'Domain network' and I can not find how to change the WAN to 'Public network'. Therefore, my public IP is now serving all my file sharing, ldap, ad, rpc information, in addition to the needed RDP. This seems very insecure!!
What was piece of cake easy less than a minute for me to do in Server 2003 I have now spent over 8 hours trying to find the answer for Server 2008 R2. (I am not one to quickly ask for help, as it would seem better to go research the new and 'better' (?) way to do things).
If you (or a moderator) can help, how do I close the WAN NIC to all but RDP incoming traffic in Server 2008?
Friday, October 23, 2009 2:54 PMNope, I have not been able to figure it out. The NLA overrides whatever you set even if you use the registry to change the profile to be public.
More concerning, if you establish a site-to-site VPN tunnel the NLA will "redetect" things and may override your choice again. Anytime there is a new IP address, gateway change, routing change(?), or something similar the NLA resets the NIC profiles to the way it deems they should be set. It does not use effective logic in determining the right profile!
There should be a way to disable the setting via group policy or some other method but I haven't been able to find it. The best I can tell is this is a hold-over from the Windows 7 features that were in both the Win 7 and Server 2008 R2 code base. I did find a group policy setting which allows you to enable changes to the profile (see Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Network List Manager Policies -> All networks) but this doesn't resolve this particular situation for some reason.
This type of "feature" should not be on a server without some way to override it. Sorry I can't be of more help. There doesn't seem to be any additional moderator input on this issue which makes me guess there is no way to override it.
Friday, October 23, 2009 4:09 PM
Being a Microsoft Partner, I just attempted to get tech support assistance on how to keep the customer's new 2008 R2 server from sharing files on the internet. But they were requiring I shell out the $250 to take out a support incident (a cost I won't be able to pass on to the customer).
Considering I have 2 other servers with the same **security problem** (gaping hole), I scoured the net for the answer for a day now, posted the inquiry here, and I'd post the answer here for others to find, you'd think I would have received some support. Nope, just a request for more money.
I'll let you know if I do find something. I know this is NOT the only thread looking for this answer.
Saturday, October 24, 2009 10:20 PM
JayRO, just wondering if you ever were able to make progress on this issue? I've been stumped so far. I've tried setting the DNS to a public DNS on the public NIC and other "hacks" to no avail.
Monday, October 26, 2009 5:06 PMRob--
Without success, I also modified the GPO, I tried this on 3 different 2008 servers (although 2 are pre-R2).
I have attempted to get guidance on this issue over at another forum:
Just now I replied to the latest (non-)suggestions.
I completely agree with your statement: "I think that the design of this feature is flawed..."
Here is one of the highlights from a referenced TechNet article:
"Windows Server 2008 R2 and Windows 7 provide support for multiple active per-network adapter profiles. In Windows Vista and Windows Server 2008, only one profile can be active on the computer at a time."
The part I don't understand: this is really a good idea? Why has there been so little outcry? Because everyone else can afford expensive hardware firewalls for their systems? (all my customers are small businesses) Or worse, the folks without a fully configured firewall device are actually quite open? And how is this Security 'Advanced'? Yikes.
Over on the Minasi post, you will see that I listed the default configuration ports that are open to the internet (external NIC detected as Domain Network). Yikes.
I think my next step will be to go BACKWARD, as in use RRAS Input Filters like I was with Windows 2000:
http://www.ohmancorp.com/RefWin-RRASPortBlock.asp But at least I know with confidence this method will block all incoming ports except 3389. But then I have to add the RRAS role to a host installation of 2008 server, I was really trying to keep the roles to nothing except Hyper-V at the Host level.
Again, thanks for the suggestions, I'll let you know if I find anything more.
Monday, October 26, 2009 6:54 PMThere are some issues with the RRAS inbound filters too. If you have NAT on the interface then your inbound filters may block traffic you don't expect. That is because the ports are literal...and don't account for NAT if you have NAT on the interface. I had a lot of issues with them because they behave completely different than any previous version. I used wireshark to debug the issue. In the end it the filters don't work because NAT is enabled.
I am surprised too that there is not more outcry on the way the NLA works. It's really bad.
I'll post if I find anything. For now I've just written scripts that change all the rules except specific ones I've created to a "domain" profile AND limit the "remote IP" since that will limit the incoming traffic to the local subnet.
I just love having the system say a public connection is the "domain" and having absolutely no way to override it. I can't write what I think of that lovely logic some developer dreamed up!
Here is a snippet of the script:
netsh advfirewall firewall set rule name=all new profile=domain remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="MyInternetRule TCP Ports" new profile=public,domain,private remoteip=any
netsh advfirewall firewall set rule name="MyInternetRule UDP Ports" new profile=public,domain,private remoteip=any
netsh advfirewall firewall set rule name="Allow ICMP" new profile=public,domain,private remoteip=any
Tuesday, October 27, 2009 12:41 PMWOW, now that was exhilarating! Spent 15 minutes replying, almost all done typing, and silly me hit Ctrl+I for italic, like I have been able to for at least 15 years, except for some stupid reason I'm browsing with IE, and IE apparently now has Ctrl+I will take you to your favorites, so now I get to start over.
Thanks for the scripting sample, that may become quite helpful.
I am going to give inbound filters a try, maybe I'll find the technique that eluded you.
If you care, I responded to a couple suggestions over at the Minasi forum: http://web2.minasi.com/forum/topic.asp?TOPIC_ID=32615
The quote of the day: "I can't write what I think of that lovely logic some developer dreamed up!"
That would probably be the same developer that thought Office Ribbons are cool.
Just to stress my comment from the other post:
Windows Server has had the feature of easily opening a single port on an interface. This seems like a dreadful step backward, considering the context that Microsoft is supposedly 'improving' security with each new version of Windows.
Then I had some nice, therapeutic venting on removal of Classic interface, whining about having to change and start concentrating on the GUI in addition to the task at hand, and how it relates to frustration and lack of faith in an OS... but I lost that with my Ctrl+I (this re-write I used my Mozilla).
I will let you know my findings with using RRAS input filters.
Thanks again for taking the time to respond to my posts!!!
Wednesday, November 04, 2009 9:27 PMJayRO,
You'll love the fact that your comments were marked as an answer by the MSFT moderator! I appreciate the comments.
For MSFT moderators: I don't see an answer anywhere in this post, only comments on the way that the location cannot be changed and attempts at hacking firewall lockdowns because the NLA service incorrectly identifies the location. I'm not sure that counts as an answer. I don't see how using input filters qualifies for an answer on how to change the location that NLA identifies.
For MSFT Moderators, please don't take the same approach as NLA and force us with an incorrect solution. Just like NLA doesn't correctly identify the public network, a question gets marked as answered when it is not!
Anyway, this question is not answered. No one has said:
1. Is it impossible to change the location defined by NLA (a simple confirm/deny). If not, why not?
2. If it is possible, then how is it done?
Clearly NLA is NOT correctly identifying the right network. No question about that. A public IP should never be identified as a "domain network". Never...and doing so is just plain wrong.
Wednesday, November 18, 2009 11:06 PMI would propose that with the current version of Server 2008 R2 it is impossible to change the location in this particular situation. Once the NLA identifies a profile as "domain", whether it is or not, you cannot change it to a more restrictive profile. I think this is a bad idea and should be changed. I cannot, however, find any way to change a location once the system has identified it as domain.
Sunday, February 07, 2010 4:08 AMHi ip-rob and JayRo,
I stumbled upon your thread and i have the same problem: I've been using Win2K3-dual-NIC-RRAS-basic firewall for a while with great success for many of my customers.
I now have the same problem with win2K8 r2 identifying the public interface as domain, and by doing that it opens up whatever ports the roles/features require.
This is MADNESS!
Have any of you found a solution to this by now ? If so, please share.
Thank you in advance,
P.S. I found several threads where ppl speak of modifying the registry in order to change this:
However, if both your NICS are identified as domain, then you don't have the option of changing the public interface since there is none listed.
I tried to find out if there is the posibility of adding a new profile with the public interface GUID. Any input comment on that ?
- Proposed As Answer by Marcus_L Friday, February 12, 2010 11:46 PM
Friday, February 12, 2010 11:52 PM@Nimare Whoops, I proposed your response as an answer by mistake! Sorry. Here's my proposed answer for Windows Server 2008 R2:Use Windows Firewall with Advanced Security to make a new Outbound rule:General:- Name: "Block NLA from Public NIC"- Action: BlockPrograms and Services- Services: NlaSvcScope- Local IP Addresses: <your public IP(s) from your public NIC> (make sure you mark all of them!)Then enable the rule, disable and re-enable the public network adapter, and it should now be public! What this rule does is prevent the Network Location Awareness service from being able to make outbound connections on your public IPs (on your public NIC). Since the service can't use your NIC, it can't contact your domain controller(s) from that NIC, and won't mark the NIC as being in the Domain Network Category.Hope that helps,Marcus
- Proposed As Answer by Marcus_L Friday, February 12, 2010 11:52 PM
Saturday, February 20, 2010 5:34 PMHi Marcus,
i have tried your suggestion but it still gives a domain profile on the external nic. do you have a commandline example so there can be no problem with my interpertation of your solution?
Monday, February 22, 2010 11:59 AMHi Marcus,
I also tried your suggestion and ran into the same problem as Sjaakmarelis.
Thursday, February 25, 2010 10:56 PM@sjaak & @andrew:Can you confirm that you are both running Windows Server 2008 R2? I'm not sure that previous versions support multiple profiles active at the same time. Also just to check things that you might've missed:1. Ensure the Windows Firewall is Enabled2. Ensure the Rule you made was an Outbound Rule, not an Inbound3. Ensure the Rule is enabled4. Did you enter in the IP of your public NIC into the Local IP address section of the rule?5. After you enable the rule, disable & re-enable the public NICTo troubleshoot, try in the Scope section of the new Outbound rule leaving the Local IP address as "All IP addresses" and then stop/restart your NICs. This should prevent even the private NIC from being marked as a Domain connection.Hope that helps,-Marcus
Thursday, February 25, 2010 11:00 PMThat is correct only one firewall profile (public/private/domain) prior to Win7/Win2008R2 and the firewall profile used is the least restrictive.
Friday, April 16, 2010 5:50 PM
Marcus, I tried the following without success:
1. Disabled both NICs
2. Remove the location profiles under HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles to be sure that nothing was getting "reused" from there.
3. Setup your rule as follows: Outbound Rule, New Rule, Custom, Left "All programs that meet criteria" and selected Services, choose Network Location Awareness, Any protocol, put in the public IP of public facing NIC, Block the connection, left all profiles checked
4. Enabled public NIC and it still picked up the local
I even attempted to accommodate the IPv6 addresses and made sure the NLA service was stopped while I was making these changes. Nothing had any impact. It still detected it as a "domain" profile.
I like the idea but I can't seem to get it to work.
Wednesday, May 19, 2010 8:44 PMCoincidentally, I've recently run into this problem on Windows 2008 R2 and Vista. A new server sporadically fails to properly identify our business LAN, and a home-based PC using wi-fi fails to identify a previously working connection after a Netgear driver update. In both cases, there seems to be no way to tell the system "look, this is a secure private network, even if for some reason you don't agree". From this discussion I get the impression Microsoft does not think this is a problem. Of course, I must be wrong about this. I mean, why would any company put its users into this kind of situation? Oh, wait, did I say "Microsoft" ...?
Tuesday, June 08, 2010 11:50 PMI struggled with this too. I just found whats an anwser for me. Maybe it'll work for you too. I discovered that once I disabled the second nick I could change the network type even though the nic was disabled.
- Proposed As Answer by Eddy01 Tuesday, June 08, 2010 11:50 PM