Changing Network Subnet Limited User Access
-
On our campus, we are noticing the strangest thing. Every now and then, our Windows 8 wireless users fail to connect to the wireless by receiving a "limited" connection. This only seems to happen internally, and the alternative is for users to use a wired connection.
-
PfSense acts as our Firewall for wireless and wired users
-
For wired users, pfSense also acts as the DHCP server. We have alternative DHCP servers for wired users
-
There are no special settings within DHCP and we use no VLANs at this time
-
We are using IPv4
-
Leases expire after 2 hours
In fact, I'm using a Windows 8 computer right now and after many reboots and following Windows 8 troubleshooting guides that describe a similar issue: http://www.tomshardware.com/answers/id-1963890/fix-wifi-limited-connection-issues-windows.html
I decided to simply connect via a wired connection until the unit fixes itself as it usually does after a few hours. As you can imagine, this issue is a nuisance on a college campus, however, phones, tablets, etc appear to have no issues.
-
-
"For wired users, pfSense also acts as the DHCP server. We have alternative DHCP servers for wired users"
Huh?
So what is your problem? So you have 2 dhcp serves on wired connections? Where does your wireless get dhcp?
-
My apologies, what I meant was that we have a 4 NIC pfSense server.
–
NIC 1 - LAN: DHCP is provided by Domain Controllers on the same switch
NIC 2 - WIFI: pfSense provides DHCP
NIC 3 - WAN
NIC 4 - Not in useUnfortunately I cannot delete this thread, so I changed the title and hope to start over here after seeing what really happened on our network.
Our network was originally a 192.168.3.1 /24 network with 192.168.3.1 being the gateway. We decided to increase our IP range by changing the network to a 192.168.3.1 /23 network.
As a result, our network has expanded from an IP range of:
192.168.3.1 - 254
To
192.168.2.1 - 192.168.3.254
All seemed to work until we noticed that users being assigned the 192.168.2.1 range are receiving limited connectivity while users being assigned the 192.168.3.254 addresses are connecting just fine,
Is there any other configuration that should be changed within pfSense besides the subnet to allow access? The 192.168.2.1 network is not in use.
Our DHCP Rules
-
Define 'limited connectivity'… They can get to the Internet but not from LAN to WiFi or vice versa? 192.168.2.x can't see anything in 192.168.3.x, but 192.168.3.x can see 192.168.2.x?
-
"Limited" means the there is no connection to the internet despite receiving the following addresses for example:
IPv4 Address. . . . . . . . . . . : 192.168.2.7
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 192.168.3.1 -
When it's in this state, can the client ping the gateway? If you manually change the client's IP address to another in the DHCP pool, does it work? You have 2 DHCP servers in the mix. Are their IP lease ranges exclusive?
-
Sounds like something in the network has not been changed from the /24 to /23.
It shouldn't be a mystery. ipconfig /all and see what the users are being assigned. Can they ping their assigned gateway, resolve DNS, etc?
-
@KOM:
When it's in this state, can the client ping the gateway? If you manually change the client's IP address to another in the DHCP pool, does it work? You have 2 DHCP servers in the mix. Are their IP lease ranges exclusive?
The client cannot even ping the gateway in that state. If I manually change the client IP from .2 to .3, the device works perfectly fine. Our DHCP addresses are 192.168.1.1 (Active Directory) while pfSense is 192.168.2.1-192.168.3.254.
Sounds like something in the network has not been changed from the /24 to /23.
It shouldn't be a mystery. ipconfig /all and see what the users are being assigned. Can they ping their assigned gateway, resolve DNS, etc?
Ipconfig a/ll delivers the information I gave earlier in the thread. Users cannot ping the gateway. For instance, I was trying to access pfSense WebGUI from a device that received the .2 address with no luck. Do you think this could be a firewall issue?
I have other users who approached me with the same access issue, so I was forced to temporarily delete the .2 pool. I look forward to your continued assistance here, it's puzzling. Of course, I tried a simple reboot to make sure something wasn't stuck.
-
Instead of saying everything is rosy, post cut and pastes and screen shots. You're obviously overlooking something or it would be working. Get more eyes on your config.
You might also consider changing the gateway IP to something more conventional like 192.168.2.1/23 and using one big DHCP pool. Just for clarity.
You could set the DHCP leases short, then make the change off-hours, then put the DHCP lease time back to a reasonable value to minimize downtime.
Bottom line: If pfSense is set to 192.168.3.1/23, and the firewall rules on that interface allow all traffic from 192.168.2.0/23, and the client is assigned an address of 192.168.2.X/255.255.254.0 and it can't ping 192.168.3.1, you have a problem at layer 2.
-
Derelict, thanks for the suggestions. Here are a few configuration screenshots. Please let me know if they are any others that might be useful. You're right, things are often missed after looking at the same thing all week. I can see if I can make those changes if nothing is off below.
For clarification
-
Lime - WAN
-
Wireless - Network with DHCP provided by pfSense
Network
NAT
DHCP
Note that I deleted the .2 pool for now due to user access issues.
Firewall - WAN
Firewall - Wireless
-
-
Wireless users won't be able to use the internet because there are no NAT rules. Did you have it set to Manual maybe when you created the wireless interface or something?
-
Wireless users won't be able to use the internet because there are no NAT rules. Did you have it set to Manual maybe when you created the wireless interface or something?
Thank you for pointing that out, I'm seeing that NAT rules are only set for the 192.168.1.0/24 network. However, even as is, is it not strange that the 192.168.3.1 network can access the wan just fine?
The rules were never set to be manually created. Would you suggest simply duplicating the NAT information but for "wireless" iP's? Very strange that rules did not create.
-
@Derelict - look again at the nat
Set to Auto for nat, what is in the list there doesn't mean much while your in auto mode. My guess is at one time you switched to manual when only had that network, then switched back to auto and those are left over.
Those can be deleted - or just switch to manual and lets see the full list.
Your lime rules above the any any that are allow are pointless. Your block rule to 389 is pointless, since you have an allow rule above that say any source can go to 389
-
There is nothing in the screen shots above that would prevent 192.168.2.x from accessing the webGUI at 192.168.3.1
Is there anything in floating rules?
If you "ping 192.168.3.1"from a 192.168.2.x device in WiFi I am guessing there is no reply? Does anything appear in the firewall log?
Look in /tmp/rules.debug for 192.168.2 - maybe that will give some inspiration as to what setting somewhere accidentally refers to this address block. -
Never liked Auto NAT much. IMHO it should always show you all the rules in play but be grayed out. Thanks for the correction.
Please find a client that can't access 192.168.3.1 and post it's ipconfig.
Be sure there's not a rule somewhere that's 192.168.3.0/24 instead of "WIRELESS net"
-
Never liked Auto NAT much. IMHO it should always show you all the rules in play but be grayed out. Thanks for the correction.
That has all been fixed up in 2.2 - you can have Auto plus rules of your own in a mixed mode. The GUI shows what Auto is doing underneath plus any extra rules you have added. IMHO it will help a lot for people to see what is really happening and reduce the forum help needed when people touch NAT settings.
-
I went ahead and assigned my machine 192.168.2.5. See below for the IP Configuration.
The network addresses loaded correctly, however, requests timed out when attempting to ping our gateway or any other addresses.
There is nothing in the screen shots above that would prevent 192.168.2.x from accessing the webGUI at 192.168.3.1
Is there anything in floating rules?
If you "ping 192.168.3.1"from a 192.168.2.x device in WiFi I am guessing there is no reply? Does anything appear in the firewall log?
Look in /tmp/rules.debug for 192.168.2 - maybe that will give some inspiration as to what setting somewhere accidentally refers to this address block.I went ahead and copied snippets that were relevant from the file. I'm not quite sure what I'm looking at, however, I do see 192.168.2.0/24 instead of /23 below.
#SSH Lockout Table
table <sshlockout>persist
table <webconfiguratorlockout>persist
#Snort tables
table <snort2c>table <virusprot>table <bogons>persist file "/etc/bogons"
table <vpn_networks>{ 192.168.2.0/24 }
table <negate_networks>{ 192.168.2.0/24 }–-
Subnets to NAT
tonatsubnets = "{ 192.168.2.0/23 192.168.1.0/24 192.168.2.0/24 127.0.0.0/8 }"
nat on $LIME from $tonatsubnets port 500 to any port 500 -> 209.59.100.194/32 port 500
nat on $LIME from $tonatsubnets to any -> 209.59.100.194/32 port 1024:65535
rdr on { em3 bge0 em2 em1 em0 openvpn } from any to 209.59.100.196 -> 192.168.3.4 bitmask
no nat on em3 from em3 to 192.168.3.4
nat on em3 from 192.168.2.0/23 to 192.168.3.4 -> 192.168.3.1 port 1024:65535</negate_networks></vpn_networks></bogons></virusprot></snort2c></webconfiguratorlockout></sshlockout> -
If you have manual outbound NAT enabled you need to make sure you have those rules right. They don't track "LAN net", etc names.
If you don't have Manual outbound NAT enabled, you have another interface on 192.168.2.0/24 or something else borked. You need to take a look at everything again. You also have the 192.168.2.0/24 network in your VPN config.
nat on em3 from 192.168.2.0/23 to 192.168.3.4 -> 192.168.3.1 port 1024:65535
What is that?
-
If you have manual outbound NAT enabled you need to make sure you have those rules right. They don't track "LAN net", etc names.
If you don't have Manual outbound NAT enabled, you have another interface on 192.168.2.0/24 or something else borked. You need to take a look at everything again. You also have the 192.168.2.0/24 network in your VPN config.
nat on em3 from 192.168.2.0/23 to 192.168.3.4 -> 192.168.3.1 port 1024:65535
What is that?
I'm not quite sure, but what I'm assuming is that there is NAT on em3 which appears to be our "Wireless" interface. Regarding Manual NAT, I've really never messed with those rules.
-
I went ahead and switched to manual NAT, the same rules appeared so nothing changed from above.
-
I deleted the existing rules as you suggested. Internet access completely halted for everyone (no ping).
-
We then switched back to Automatic
-
We are now operational with the below NAT rules, or lack thereof.
I switched to Manual to see if new rules would be created:
Switched back to Automatic mode after deleting the existing rules (since they would be recreated) and retested the 192.168.2.1 network. Same result. I received all network information shown in prior posts, however, I cannot ping the local gateway.
UPDATE: I am just noticing here that according to NAT, our OpenVPN server is on the 192.168.2.1 network. Let me remove this.
-
-
Well I went ahead and removed the OpenVPN configuration and deleted the package since it is not in use. My machine still picks everything up as it did in the above ipconfig screenshot, but I still not ping the gateway or other IP's. Would you recommend leaving pfSense in Automatic or Manual mode?
