problem resolving public domain name from client pc after switching subnet from /24 to /23


  • Hi,

    I was trying googling for this issue but couldn't find any similar nor related, hence looking for help here.

    My previous pfsense box settings as below:
    LAN : 192.168.0.4/24
    WAN : PPPOE static public ip assign by ISP

    Recently tried increase available LAN dhcp ip by changing LAN interface subnet /24 to /23 which gives 500+ ip.

    New LAN interface setting:
    LAN : 192.168.0.4/23

    After the new subnet configured, the client LAN IP assigned correctly but unfortunately the client not able to access internet due to public domain name not able to resolve. Tested ping public ip e.g. 8.8.8.8 with success. The WAN from pfsense box works without any issues just that the client not able to resolve any public domain name hence not able to access the net(except using IP).

    Wondering what went wrong. The only changes was the subnet.

    Would appreciate any advice.

  • LAYER 8 Rebel Alliance

    Did you check your clients for the correct mask (/23)?

    -Rico


  • @kee

    DHCP and DNS are two entirely separate things. DNS should work, no matter what the subnet size is. What happens if you try from a computer that has an address within the original range? What happens if you put the subnet back to /24?


  • @Rico

    The clients should get the subnet size automagically from the DHCP server, which passes on the size configred on the LAN page. Also, if a device has an address within the original range, it should make no difference what size the subnet is, so long as it's trying to reach an address outside of the subnet.


  • @Rico
    client mask is correct, see below:

    ========================
    Ethernet adapter Ethernet:

    Connection-specific DNS Suffix . : localdomain
    Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes

    IPv4 Address. . . . . . . . . . . : 192.168.0.21(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.254.0
    Lease Obtained. . . . . . . . . . : Tuesday, March 3, 2020 7:56:48 AM
    Lease Expires . . . . . . . . . . : Tuesday, March 3, 2020 12:01:14 PM
    Default Gateway . . . . . . . . . : 192.168.0.4
    DHCP Server . . . . . . . . . . . : 192.168.0.4
    DHCPv6 IAID . . . . . . . . . . . : 190626049

    DNS Servers . . . . . . . . . . . : 192.168.0.4
    NetBIOS over Tcpip. . . . . . . . : Enabled

    ==============================


  • @JKnott
    The computer i am testing it from is within the original dhcp range. None of the domain name can be resolved.

    I have not expand the dhcp start and end yet, until i test everything ok, so the range still within the original range. And things back to normal if i switch it back to /24, all domain name can be resolved without any problem.

  • LAYER 8

    is it dns resolver or dns forwarder ?
    did you try to change from dns resolver to dns forwarder or from dns forwarder to dns resolver?


  • @kiokoman
    i have dns resolver enabled before and after i switch to /23, but nothing was changed.
    The only change is the subnet from /24 to /23.


  • Just curious, but why would you change the subnet size instead of using VLANs to expand your network?

    Jeff


  • @akuma1x
    i am having some issues with legacy domain controller (samba 3) when windows client connecting with WiFi (Wifi is different subnet and different network interface).

    LAN 192.168.0.0/24 (wired clients and domain controller is in here)
    WiFi 192.168.1.0/24 (WiFi AP connecting to this interface to serve wireless users)
    Dmz 192.168.2.0/24

    Tested with WiFi AP connecting to LAN switch, so that WiFi clients get 192.168.0.x, no problem at all with Domain Controller e.g. change password, join domain etc.

    So i am thinking to expand the range by switching to /23 so that wired and wireless client all within the same subnet and "probably" solve the domain controller issues.

    Thinking that this is the easier way instead of trying to fix the domain controller issues.