Lost access to Windows server after pfSense install
-
My original home network used to consist of a Netgear Nighthawk in router mode connected to my ISP with my Windows Server 2016 Essentials server and several workstations connected to the router's Ethernet ports. The router performed all DHCP leasing and traffic routing; the server provided shared files for my workstations. Over time, I added a number of wireless IOT's (lights, temp control, etc.) so I decided to create a separate IOT network to protect my home network.
I built a pfSense 2.6.0 router out of a spare computer, installed 6 Ethernet ports and created two networks, IOT and Home. I bridged 4 of the ports together and assigned them to the Home network, assigned one port to the IOT network and assigned the remaining port to the LAN. I placed a WAP on the IOT port to handle all of the wireless IOT's and I put the Netgear router in AP mode on the Home network to provide wireless service for that network. The server is connected to one of the Home network ports on the pfSense router because it sits right next to it; the workstations are connected to the Netgear router ports. The pfSense router performs all DHCP leasing and traffic routing similar to what the Netgear router did initially.
For some reason, my workstations can no access files on the Windows server. I can ping the server from the workstations and get a response, but when I try to access files I receive an error message that says the server is online but it is not responding to connection attempts. I assume that there must be a firewall rule error but I do not see it. I uploaded my firewall rules for the Home network (OPT6 is the name of the bridged group of ports). Any help to figure out how to access my server would be appreciated.
-
1st rule does you absolutely no good.. Rules control traffic coming into the interface.. not visa versa.
Show your LAN rules that seems blocked to you.
Remember that Windows firewalls block anything outside their own subnet by default. Even Server.
-
@oldsports not exactly sure what you did with a bridging... But your opt6 network rules don't allow any access to lan..
If your clients coming in from this opt bridge you created into lan - you have blocked all access, not even sure how you could possibly being pinging them..
What I would suggest is why are you trying to use discrete interfaces as a switch? With your bridge.. Just use a switch..
interfaces in a bridge do not make a switch - while you can get some functionality to seem like a switch, its not a switch.. You would most likely save yourself a lot of grief and use a switch vs trying to get them to act like a switch.
Your interfaces would be much better used as actual routing interfaces for different networks than trying to make them into something they are not.
-
Also :
First rule : DNS traffic can be TCP and/or UDP.
Use the "This Firewall" alias as a Destination, just to be more clear. -
@gertjan said in Lost access to Windows server after pfSense install:
Use the "This Firewall" alias as a Destination, just to be mare clear.
Hmmm - while sure that would work, and could be actually a good rule. Since that alias includes all IPs of pfsense, and while that wouldn't be a problem normally. You normally would be pointing clients of a network/vlan to the IP address pfsense on that specific interface.
I would think the better option here would be OptX address. But yes for sure should be tcp/udp.
The use of "net" in the alias is a bit ambiguous because pfsense really has no control over devices on that net talking to other devices on that net.. So yeah use of the optX net is not a good choice for sure.
And it even gets more muddled with use of a bridge, are you pointing the dns to something that is on the other side of the bridge and not pfsense specifically.. But you want to allow it.
-
All,
Thanks for all of the quick responses. Let me try to respond to them the best I can.
I copied the DNS rule from a firewall example I found when I built my first pfSense router last year. To be honest, I was not exactly sure how it worked, but since the comments said that it was allowing DNS to pfSense I left it. If it does nothing as @chpalmer suggests, I can remove it. If it should be there, I can add TCP as @Gertjan suggests. What I do know is that the rule has no effect on my problem because I disabled it during troubleshooting and I still could not access the server.
Similarly, I use "net" versus "address" because I saw this in examples of firewall rules the first time I built a router. Given your comments, I assume that "net" refers to any device physically connected to the interface while "address" is looking for the specific address being used by the device. If that is the case, I understand the point of using "address", particularly on "Allow" rules.
I am not clear on the comments about using "This Firewall". From your comments, it sounds like a built-in alias in pfSense - is that correct?
The server and the clients are not on the LAN; they are on their own network with their own IP range. This is why the clients can ping the server. The server and the clients are using pfSense as the DNS and the gateway; I checked this in their Internet set-ups on Windows. The clients just need to connect to the Internet and access the server and shared printers; they do not even need to access each other. I could put all of them on the LAN if that makes a difference, but I don't see why they need to be on the LAN.
I created the bridge for two reasons. First, I read about it so I wanted to experiment and learn. Second, since the server was sitting physically next to the router, it was easy to connect the server directly to the router. The long cable that formerly connected the server to the Netgear router in my previous set-up was now used to connect the pfSense router to the ISP modem which is physically next to the Netgear router. I would need to get another long cable to connect the server to the Netgear router (which is now an AP), so connecting it directly to the pfSense router was more convenient. However, I suspected that the bridge was causing the issue, so I went ahead and connected the server to the Netgear AP where the clients are connected and I still could not access it. I left the bridge in place even though I was only using one interface, so my next move is to disassemble the bridge and try again.
I think that covers all of the comments. So, I will disassemble the bridge, create one interface for the Home network, connect the interface to the Netgear AP and connect the server and the clients to the AP. I will report back on how this works. Thanks!
-
Yes, 'address' refers to the specific IP address used by the interface. 'net' refers to the whole subnet defined on it. However there may be more than one subnet attached physically and it would not include those. You should avoid having that if you you can, one subnet per layer 2 segment please!
Yes, 'This Firewall' is a system alias that contains all IP addresses the firewall owns. So all interfaces including WANs and VPNs etc.
So OPT6 is the assigned bridge interface? And that contains LAN and OPT1-5?
If the server was not accessible when it was connected to the switch in the Netgear router and you were testing from a client also connected there then pfSense cannot be blocking it.
Steve
-
Thanks for the reply and the clarifications on "This Firewall" and "address vs. net".
The interfaces on my router are:
- WAN
- LAN - 192.168.100.x
- OPT1 - IOT network (192.168.2.x)
- OPT2-5 - bridged together as BRIDGE0
- OPT6 - assigned to BRIDGE0; Home network (192.168.1.x)
The bridge does not include the LAN. I suppose I could have included the LAN in the bridge, but I did not think it needed to be there. This might not be necessary, but I like the idea of keeping the client networks separate from the LAN. I don't think that this is causing my problem, but let me know if I am missing something.
During troubleshooting, when I connected the server directly to the AP where the clients were, I thought that would take the bridge out of the picture as a possible cause of the issue. However, I thought that the router would still be a possible cause since I assume the router still needs to process the communication between the server and the clients even if they are on a common switch. This led me back to the idea that maybe the bridge is causing the problem even though I was using one interface. Later this evening, I will dismantle the bridge and try again. I will report back on what happens.
Thanks!
-
Most SOHO routers like that just use the switch ports as a layer 2 switch. But not all.
If it is though then with the clients and server both connected to it traffic goes directly between them. Neither pfSense or the local router would see that traffic at all. So the only thing that might prevent clients reaching the server would be DNS perhaps. Depending on how they are trying to access it.
With the server on the bridge in pfSense and clients on the LAN you would need the correct LAN rules to allow access.
Steve
-
So, I have some good news but I still have an issue. The good news is that I was able to access the server:
-
I disassembled the bridge and set up the Home network on one interface (OPT2). I connected the interface to the Netgear AP and then connected the server and one of the clients to the AP. I tried to access the server by re-installing the server connector software but no luck.
-
I did some digging online to see if there was documentation on how a router should be configured for MS Server 2016 Essentials. I found an article that said that UPnP needed to be activated or I would have to do some manual port forwarding. I found pfSense's documentation on UPnP, configured the router and tried again to install the server connector. This time, the software installed and I was able to access the server folders again. Success!
-
When I tried to access the Internet, I could not do it. I found out that the server had changed the client's DNS address to the server's static IP address. When I changed the setting back to allow the client to automatically receive the DNS from the router, I regained access to the Internet but lost access to the server. Furthermore, the server automatically re-loads its static IP address into the client's DNS address every time the client is re-started. Apparently, this is a bug in MS Server software; I found a script to run that made a change in the registry to stop the server from changing the client DNS.
-
Having partially resolved the server access issue, I decided to recreate the 4-port bridge on pfSense to convince myself that this was not the original problem. The bridge is working as expected.
So, my original problem was probably the way DNS was being resolved in the network after I switched out the Netgear router with the pfSense router. Apparently, the Netgear router's DNS knew how to find the server but the pfSense router's DNS does not. I assume there must be some way for the pfSense's router to include the server's information in its DNS table so that it can find it when requested.
Does this sound right? Is there something else I should be looking at?
Thanks!
-
-
It definitely sounds like a DNS issue, yes.
You should always be able to access the server by IP address. It you are trying to 'discover' it from a Windows client it needs to either be in the same subnet or everything needs to be using the Windows server for DNS. Assuming it's acting as the domain controller.
You should not need UPnP enabled in pfSense and in fact the UPnP feature only handles gatewau discovery and port forwards. You do not want to allow the Windows server to open port forwards to itself from the Internet!
Steve
-
@oldsports said in Lost access to Windows server after pfSense install:
I assume there must be some way for the pfSense's router to include the server's information in its DNS table
If you're using the default DNS Resolver, under its Domain Overrides section, add an entry for
yourdomain.lan ip.of.server
Then queries to pfSense for that domain will be forwarded to that IP. Otherwise any device using pfSense (or any other DNS server) for DNS (e.g., pfSense DHCP, IPv6) will be unable to resolve the domain. So, also remove any "backup" DNS servers on PCs that are not from your Windows network (Windows uses "last good" DNS, it does not query in order).
You can also add a reverse zone:
1.168.192.in-addr.arpa ip.of.server
-
I disabled UPnP on the router and I still have access to the server.
Thanks for the information about the Domain Overrides. I entered the server's domain and IP address into the table, changed the client's adapter setting to automatically obtain the DNS address and restarted the client. The client was able to access the server files and the Internet - problem solved!
Thanks to all for sticking with my situation until it got resolved.
