Strange dhcp client behaviour



  • Hi all!

    I've just installed an instance of pfsence in a simple configuration (one port wan, one port lan, dhcp client on wan and server on lan and nat between lan and wan).
    Everything that i expect works fine but one big problem.

    When booted I experience my dns server inaccessible from the pfsene instance.
    It is alike that when it gains DHCP it adds a line into routing table that breaks anything

    
    192.168.39.1       ba:3e:e6:62:02:f5  UHS         0       52    em0
    
    

    192.168.39.1 is my inner DNS server and  ba:3e:e6:62:02:f5 seems to be exact MAC-address of em0 interface.
    The default gw for this segment is 192.168.52.1 and the subnetwork is 192.168.52.0/24.
    So far this pfsence instance cannot access my DNS and that is a pain.
    If i remove this strange route, everything works but the next dhclient run (and of course next reboot) everything breaks down.

    Why does this bogus line appear? How could i cure this? All other dhcp clients i tried work fine(linux and windows boxes without any specific configurations)

    PS : 2.0.3-RELEASE, up to date



  • @ivanaxe:

    When booted I experience my dns server inaccessible from the pfsene instance.
    It is alike that when it gains DHCP it adds a line into routing table that breaks anything

    
    192.168.39.1       ba:3e:e6:62:02:f5  UHS         0       52    em0
    
    

    This is not a routing table format I recognise. How did you get it? (what command and on what type of operating system?)

    @ivanaxe:

    192.168.39.1 is my inner DNS server and  ba:3e:e6:62:02:f5 seems to be exact MAC-address of em0 interface.
    The default gw for this segment is 192.168.52.1 and the subnetwork is 192.168.52.0/24.

    I don't understand this. Do you mean 192.168.39.1 is on the same same LAN segment as the 192.168.52.0/24 network and that the default gateway for 192.168.39.1 is 192.168.52.1?

    Please provide a network diagram giving the IP address and subnet mask of all interfaces.



  • Just executing netstat -nr

    
    [2.0.3-RELEASE][admin@gw.lugger.trafica.ru]/root(4): netstat -nr
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            192.168.52.1       UGS         0      627    em0
    127.0.0.1          link#5             UH          0      164    lo0
    192.168.39.1       ba:3e:e6:62:02:f5  UHS         0      431    em0
    192.168.52.0/24    link#1             U           0     4170    em0
    192.168.52.233     link#1             UHS         0        0    lo0
    192.168.210.0/24   link#2             U           0      320    em1
    192.168.210.1      link#2             UHS         0        0    lo0
    
    Internet6:
    Destination                       Gateway                       Flags      Netif Expire
    ::1                               ::1                           UH          lo0
    fe80::%em0/64                     link#1                        U           em0
    fe80::b83e:e6ff:fe62:2f5%em0      link#1                        UHS         lo0
    fe80::%em1/64                     link#2                        U           em1
    fe80::5870:a7ff:feac:6fe9%em1     link#2                        UHS         lo0
    fe80::%lo0/64                     link#5                        U           lo0
    fe80::1%lo0                       link#5                        UHS         lo0
    ff01:1::/32                       fe80::b83e:e6ff:fe62:2f5%em0  U           em0
    ff01:2::/32                       fe80::5870:a7ff:feac:6fe9%em1 U           em1
    ff01:5::/32                       ::1                           U           lo0
    ff02::%em0/32                     fe80::b83e:e6ff:fe62:2f5%em0  U           em0
    ff02::%em1/32                     fe80::5870:a7ff:feac:6fe9%em1 U           em1
    ff02::%lo0/32                     ::1                           U           lo0
    
    
    
    [-em1(LAN)  pfsense box  em0(WAN)-] <---> [-(192.168.52.1)  dhcp relay  (192.168.39.2)] <---> [192.168.39.1 DNS+DHCP server]
    
    

  • Banned

    @ivanaxe:

    Just executing netstat -nr

    That's not what's been requested, plus absolutely does not explain how 192.168.39.x/?? fits into the scheme…



  • @wallabybob:

    This is not a routing table format I recognise. How did you get it? (what command and on what type of operating system?)

    @doktornotor:

    That's not what's been requested, plus absolutely does not explain how 192.168.39.x/?? fits into the scheme…

    That's exactly what has been requested (the way how i've got this).

    @doktornotor:

    192.168.39.x/?? fits into the scheme…

    FLAGS=H indicates that this entry is a host-entry and assumes that mask is /32.

    @doktornotor:

    how 192.168.39.x/?? fits into the scheme…

    It is just a host and that is not strange that a routing table can contain an entry with an ip-address.
    It is awful surprising that dhcp client or another pfsense script adds this strange entry into routing table. All other clients i've tried don't do this.
    Yes, 192.168.39.1 is my dns server that is announced by my dhcp server. Yes it is inside another /24 segment. Yes, i've got more than one subnetwork, connected with a router (or L3-capable switch, no matter).
    And this pfsense instance is guided to be a part of roadwarrior's demo equipment and must be capable to work in wide class of cases.



  • @doktornotor:

    @ivanaxe:

    Just executing netstat -nr

    That's not what's been requested, plus absolutely does not explain how 192.168.39.x/?? fits into the scheme…

    Thats what I thought at first but a second look showed the routing table entry I queried within the pfSense netstat -rn output/

    I don't think I have ever seen such an entry on a pfSense system. I wonder if this is some weirdness related to use of DHCP relay. I wonder what dhclient reports in the logs. What sort of software runs in the DHCP relay?

    Your diagram is somewhat helpful but suggests to me that 192.168.39.0/24 is on a different broadcast medium (distinct LAN segment) than 192.168.52.0/24


  • Banned

    @wallabybob:

    suggests to me that 192.168.39.0/24 is on a different broadcast medium (distinct LAN segment) than 192.168.52.0/24

    Afraid it's not even LAN but something "in front" of WAN.



  • @wallabybob:

    Thats what I thought at first but a second look showed the routing table entry I queried within the pfSense netstat -rn output/

    I don't think I have ever seen such an entry on a pfSense system. I wonder if this is some weirdness related to use of DHCP relay. I wonder what dhclient reports in the logs. What sort of software runs in the DHCP relay?

    A system.log fragment. I don't see anything bad. Is it a way to increase verbosity of dhcp client logs?

    
    Sep 10 13:36:13 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67
    Sep 10 13:36:20 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67
    Sep 10 13:36:22 gw apinger: ALARM: WAN(192.168.52.1)  *** down ***
    Sep 10 13:36:29 gw dhclient[33448]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 5
    Sep 10 13:36:32 gw check_reload_status: Reloading filter
    Sep 10 13:36:34 gw dhclient[33448]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10
    Sep 10 13:36:36 gw dhclient[33448]: DHCPOFFER from 192.168.52.1
    Sep 10 13:36:36 gw dhclient: ARPSEND
    Sep 10 13:36:38 gw dhclient: ARPCHECK
    Sep 10 13:36:38 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67
    Sep 10 13:36:38 gw dhclient[33448]: DHCPACK from 192.168.52.1
    Sep 10 13:36:38 gw dhclient: BOUND
    Sep 10 13:36:38 gw dhclient: Deleting old routes
    Sep 10 13:36:38 gw dhclient: Starting add_new_address()
    Sep 10 13:36:38 gw dhclient: ifconfig em0 inet 192.168.52.233 netmask 255.255.255.0 broadcast 192.168.52.255
    Sep 10 13:36:38 gw dhclient: New IP Address (em0): 192.168.52.233
    Sep 10 13:36:38 gw dhclient: New Subnet Mask (em0): 255.255.255.0
    Sep 10 13:36:38 gw dhclient: New Broadcast Address (em0): 192.168.52.255
    Sep 10 13:36:38 gw dhclient: New Routers (em0): 192.168.52.1
    Sep 10 13:36:38 gw dhclient: Adding new routes to interface: em0
    Sep 10 13:36:38 gw dhclient: /sbin/route add default 192.168.52.1
    Sep 10 13:36:38 gw dhclient: Creating resolv.conf
    Sep 10 13:36:38 gw dhclient[33448]: bound to 192.168.52.233 -- renewal in 3600 seconds.
    Sep 10 13:36:38 gw check_reload_status: rc.newwanip starting em0
    Sep 10 13:36:42 gw php: : rc.newwanip: Informational is starting em0.
    Sep 10 13:36:42 gw php: : rc.newwanip: on (IP address: 192.168.52.233) (interface: wan) (real interface: em0).
    Sep 10 13:36:42 gw php: : ROUTING: setting default route to 192.168.52.1
    
    

    DHCP relay is D-link DGS-3420. It is running for several months in this configuration and no strange effects have been observed yet.
    Finaly i've tried to attach that instance directly into 192.168.39.0/24 segment (no relay between dhcp server and pfsense client) – the strange entry still exists but dns connections work (because of the same broadcast domain).
    I think it could be some kind of pfsense- or freebsd-specific script that adds this route for some reason but couldn't catch it yet(

    Your diagram is somewhat helpful but suggests to me that 192.168.39.0/24 is on a different broadcast medium (distinct LAN segment) than 192.168.52.0/24

    Yes, different vlans. And I've tried tcpdump on em0 – sure, different vlans and no cross-broadcast traffic between them

    @doktornotor:

    Afraid it's not even LAN but something "in front" of WAN.

    It's in front of WAN, yes. It's my internal DNS+DHCP server. And the instance of pfsense i'm having an issue whith is a gate into a kind of isolated subnetwork 192.168.210.0/24 (which contains a demo-stand that can be moved out of the office and displayed somewhere else)


Log in to reply