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 anything192.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
-
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 anything192.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?)
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]
-
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…
-
This is not a routing table format I recognise. How did you get it? (what command and on what type of operating system?)
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).
192.168.39.x/?? fits into the scheme…
FLAGS=H indicates that this entry is a host-entry and assumes that mask is /32.
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. -
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
-
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.
-
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
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)