Changing Network Subnet Limited User Access
-
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?
-
If you don't need anything different from what auto provides, I'd leave it auto.
Does /tmp/rules.debug show anything interesting now?
Deleted the OpenVPN package? What version of pfSense is this?
-
If you don't need anything different from what auto provides, I'd leave it auto.
Does /tmp/rules.debug show anything interesting now?
Deleted the OpenVPN package? What version of pfSense is this?
Auto it is then.
/tmp/rules.debug shows as follows (related to 192.168.2.*)
Outbound NAT rules
Subnets to NAT
tonatsubnets = "{ 192.168.2.0/23 192.168.1.0/24 127.0.0.0/8 }"
nat on $LIME from $tonatsubnets port 500 to any port 500 -> 209.59.59.194/32 port 500
nat on $LIME from $tonatsubnets to any -> 209.59.59.194/32 port 1024:65535–--
Reflection redirects and NAT for 1:1 mappings
rdr on { em3 bge0 em2 em1 em0 } from any to 209.59.59.194 -> 192.168.1.4 bitmask
no nat on em2 from em2 to 192.168.1.4
nat on em2 from 192.168.1.0/24 to 192.168.1.4 -> 192.168.1.1 port 1024:65535rdr on { em3 bge0 em2 em1 em0 } from any to 209.59.59.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:65535I removed the configured settings of OpenVPN first, then deleted the package entirely. We are running: 2.1.5-RELEASE (i386)
-
There is no OpenVPN package on 2.1.5. It's part of the base system. Are you talking about the client export utility?
Anyway. Now that all that is out of there, step back and take another look at the /tmp/rules.debug and all your interfaces and rules.
-
There is no OpenVPN package on 2.1.5. It's part of the base system. Are you talking about the client export utility?
Anyway. Now that all that is out of there, step back and take another look at the /tmp/rules.debug and all your interfaces and rules.
My apologies, yes the client Export Utility for OpenVPN.
