No DHCP response, pfSense 1.2.3

wällerklaus

Hello,

since almost a week I'm struggling to get my pfSense box to provide IP leases via DHCP. I'm new to pfSense, but experienced in Linux (not BSD) and consumer class routers, but still surprised about not beeing able to configure pfSense to enable DHCP. Searching on the web has pointed me to some ideas on how to analyse the issue and tune the settings, however no luck so far in getting pfSense to respond on DHCP requests on the LAN. There's no other DHCP server and I'm not running into the known Vista (pre SP1) problem as I tried with Linux (Maemo), XP and Win7 clients, all known to work. I hope someone can provide help in nailing down the issue and hopefully point me to a solution.

Here's my Setup:

ste3: LAN (port #4 of a D-Link DFE-580TX)
rl0: WAN (Realtek on motherboard)
tun0: VPN (OpenVPN)

More details recorded from the console let me assume that the dhcpd is setup correctly to listen on all net-ports and DHCP requests are coming in as they should.


# uname -a
FreeBSD router.local 7.2-RELEASE-p5 FreeBSD 7.2-RELEASE-p5 #0: Sun Dec  6 22:57:48 EST 2009     sullrich@FreeBSD_7.2_pfSense_1.2.3_snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7  i386
#
#
# ifconfig -a
ste0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b4
        media: Ethernet autoselect (none)
        status: no carrier
ste1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b5
        media: Ethernet autoselect (none)
        status: no carrier
ste2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b6
        media: Ethernet autoselect (none)
        status: no carrier
ste3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b7
        inet 192.168.1.221 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::20d:88ff:fec5:f5b7%ste3 prefixlen 64 scopeid 0x4
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
rl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:e0:c5:6a:74:a6
        inet6 fe80::2e0:c5ff:fe6a:74a6%rl0 prefixlen 64 scopeid 0x5
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
        pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
pflog0: flags=100 <promisc>metric 0 mtu 33204
ng0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
        inet xxx.xxx.xxx.xxx --> 217.0.116.247 netmask 0xffffffff
        inet6 fe80::20d:88ff:fec5:f5b4%ng0 prefixlen 64 scopeid 0xa
tun0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
        inet6 fe80::20d:88ff:fec5:f5b4%tun0 prefixlen 64 scopeid 0xb
        inet 192.168.10.1 --> 192.168.10.2 netmask 0xffffffff
        Opened by PID 377
#
#
# tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
21:54:01.965714 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:04.644946 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:07.964732 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:10.964375 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:13.745063 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:16.706229 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:19.962777 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:22.962395 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
8 packets captured
114 packets received by filter
0 packets dropped by kernel
#
#
# ps auxgw | grep dhcpd
dhcpd   1080  0.0  0.2  3156  2116  ??  Is    7:07PM   0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -c
#
#
# sockstat | grep dhcpd
dhcpd    dhcpd      1080  3  dgram  -> /var/run/logpriv
dhcpd    dhcpd      1080  10 udp4   *:67                  *:*
#
#
# netstat -an -p udp
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
udp4       0      0 *.67                   *.*
udp6       0      0 *.53                   *.*
udp4       0      0 *.53                   *.*</up,pointopoint,running,multicast></up,pointopoint,running,noarp,simplex,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></vlan_mtu></up,broadcast,running,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast>

Here's my system log:

dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
dhcpd: All rights reserved.
dhcpd: Copyright 2004-2008 Internet Systems Consortium.
dhcpd: Internet Systems Consortium DHCP Server V3.0.7
pftpx[557]: listening on 127.0.0.1 port 8022
pftpx[557]: listening on 127.0.0.1 port 8022
kernel: pflog0: promiscuous mode enabled
kernel: Trying to mount root from ufs:/dev/ad0s1a
kernel: ad0: 955MB <transcend 20070831=""> at ata0-master UDMA33
kernel: ad0: DMA limited to UDMA33, device found non-ATA66 cable
kernel: IPsec: Initialized Security Association Processing.
kernel: Timecounters tick every 1.000 msec
kernel: Timecounter "TSC" frequency 797968474 Hz quality 800
kernel: vga0: <generic isa="" vga=""> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
kernel: sc0: VGA <16 virtual consoles, flags=0x300>
kernel: sc0: <system console=""> at flags 0x100 on isa0
kernel: orm0: <isa option="" roms=""> at iomem 0xc0000-0xcbfff,0xcc000-0xcffff pnpid ORM0000 on isa0
kernel: pmtimer0 on isa0
kernel: acpi_throttle0: <acpi cpu="" throttling=""> on cpu0
kernel: cpu0: <acpi cpu=""> on acpi0
kernel: psm0: model Generic PS/2 mouse, device ID 0
kernel: psm0: [ITHREAD]
kernel: psm0: [GIANT-LOCKED]
kernel: psm0: <ps 2="" mouse=""> irq 12 on atkbdc0
kernel: atkbd0: [ITHREAD]
kernel: atkbd0: [GIANT-LOCKED]
kernel: kbd0 at atkbd0
kernel: atkbd0: <at keyboard=""> irq 1 on atkbdc0
kernel: atkbdc0: <keyboard controller="" (i8042)=""> port 0x60,0x64 irq 1 on acpi0
kernel: sio1: [FILTER]
kernel: sio1: type 16550A
kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
kernel: sio0: [FILTER]
kernel: sio0: type 16550A
kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
kernel: speaker0: <pc speaker=""> port 0x61 on acpi0
kernel: rl0: [ITHREAD]
kernel: rl0: Ethernet address: 00:e0:c5:6a:74:a6
kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
kernel: rlphy0: <realtek internal="" media="" interface=""> PHY 0 on miibus4
kernel: miibus4: <mii bus=""> on rl0
kernel: rl0: <realtek 10="" 8139="" 100basetx=""> port 0xe800-0xe8ff mem 0xef000000-0xef0000ff irq 15 at device 9.0 on pci0
kernel: pci0: <multimedia, audio=""> at device 7.5 (no driver attached)
kernel: pci0: <bridge> at device 7.4 (no driver attached)
kernel: uhub0: 2 ports with 2 removable, self powered
kernel: uhub0: <via 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr=""> on usb0
kernel: usb0: USB revision 1.0
kernel: usb0: <via 83c572="" usb="" controller=""> on uhci0
kernel: uhci0: [ITHREAD]
kernel: uhci0: [GIANT-LOCKED]
kernel: uhci0: <via 83c572="" usb="" controller=""> port 0xd400-0xd41f irq 10 at device 7.2 on pci0
kernel: ata1: [ITHREAD]
kernel: ata1: <ata 1="" channel=""> on atapci0
kernel: ata0: [ITHREAD]
kernel: ata0: <ata 0="" channel=""> on atapci0
kernel: atapci0: <via 82c686b="" udma100="" controller=""> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 7.1 on pci0
kernel: isa0: <isa bus=""> on isab0
kernel: isab0: <pci-isa bridge=""> at device 7.0 on pci0
kernel: ste3: [ITHREAD]
kernel: ste3: Ethernet address: 00:0d:88:c5:f5:b7
kernel: ste3: WARNING: using obsoleted if_watchdog interface
kernel: ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
kernel: ukphy3: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus3
kernel: miibus3: <mii bus=""> on ste3
kernel: ste3: <d-link 10="" dl10050="" 100basetx=""> port 0xcc00-0xcc7f irq 15 at device 7.0 on pci2
kernel: ste2: [ITHREAD]
kernel: ste2: Ethernet address: 00:0d:88:c5:f5:b6
kernel: ste2: WARNING: using obsoleted if_watchdog interface
kernel: ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
kernel: ukphy2: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus2
kernel: miibus2: <mii bus=""> on ste2
kernel: ste2: <d-link 10="" dl10050="" 100basetx=""> port 0xc800-0xc87f irq 11 at device 6.0 on pci2
kernel: ste1: [ITHREAD]
kernel: ste1: Ethernet address: 00:0d:88:c5:f5:b5
kernel: ste1: WARNING: using obsoleted if_watchdog interface
kernel: ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
kernel: ukphy1: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus1
kernel: miibus1: <mii bus=""> on ste1
kernel: ste1: <d-link 10="" dl10050="" 100basetx=""> port 0xc400-0xc47f irq 10 at device 5.0 on pci2
kernel: ste0: [ITHREAD]
kernel: ste0: Ethernet address: 00:0d:88:c5:f5:b4
kernel: ste0: WARNING: using obsoleted if_watchdog interface
kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
kernel: ukphy0: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus0
kernel: miibus0: <mii bus=""> on ste0
kernel: ste0: <d-link 10="" dl10050="" 100basetx=""> port 0xc000-0xc07f irq 5 at device 4.0 on pci2
kernel: pci2: <pci bus=""> on pcib2
kernel: pcib2: <pci-pci bridge=""> at device 6.0 on pci0
kernel: vgapci0: <vga-compatible display=""> mem 0xed000000-0xed07ffff,0xe0000000-0xe7ffffff irq 15 at device 0.0 on pci1
kernel: pci1: <pci bus=""> on pcib1
kernel: pcib1: <pci-pci bridge=""> at device 1.0 on pci0
kernel: agp0: aperture size is 256M
kernel: agp0: <via 82c694x="" (apollo="" pro="" 133a)="" host="" to="" pci="" bridge=""> on hostb0
kernel: pci0: <acpi pci="" bus=""> on pcib0
kernel: pcib0: <acpi host-pci="" bridge=""> port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0
kernel: acpi_button0: <power button=""> on acpi0
kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
kernel: acpi0: Power Button (fixed)
kernel: acpi0: [ITHREAD]
kernel: acpi0: <via605 awrdacpi=""> on motherboard
kernel: padlock0: No ACE support.
kernel: cryptosoft0: <software crypto=""> on motherboard
kernel: kbd1 at kbdmux0
kernel: wlan: mac acl policy registered
kernel: avail memory = 1028579328 (980 MB)
kernel: real memory = 1065287680 (1015 MB)
kernel: VIA Padlock Features=0x3d <rng>kernel: Features=0x380b13d <fpu,de,pse,tsc,msr,cx8,mtrr,pge,cmov,mmx,fxsr,sse>kernel: Origin = "CentaurHauls" Id = 0x695 Stepping = 5
kernel: CPU: VIA Nehemiah (797.97-MHz 686-class CPU)
kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
kernel: sullrich@FreeBSD_7.2_pfSense_1.2.3_snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7
kernel: FreeBSD 7.2-RELEASE-p5 #0: Sun Dec 6 22:57:48 EST 2009
kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
kernel: The Regents of the University of California. All rights reserved.
kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
kernel: Copyright (c) 1992-2009 The FreeBSD Project.
syslogd: kernel boot file is /boot/kernel/kernel</fpu,de,pse,tsc,msr,cx8,mtrr,pge,cmov,mmx,fxsr,sse></rng></software></via605></power></acpi></acpi></via></pci-pci></pci></vga-compatible></pci-pci></pci></d-link></mii></generic></d-link></mii></generic></d-link></mii></generic></d-link></mii></generic></pci-isa></isa></via></ata></ata></via></via></via></bridge></multimedia,></realtek></mii></realtek></pc></keyboard></at></ps></acpi></acpi></isa></system></generic></transcend>

Here's the my DHCP setup:

Enable DHCP server on LAN interface
Deny unknown clients [no]
Subnet 	192.168.1.0
Subnet mask 	255.255.255.0
Available range 	192.168.1.0 - 192.168.1.255
Range	192.168.1.103 to	192.168.1.150

Attached image is the Firewall setup on the LAN port:
Note the logging in my first, second and last rule.
… and there is nothing in the firewall log. No packets from LAN logged!?

… and the DHCP log

last message repeated 2 times
dhcpd: 5 bad IP checksums seen in 5 packets
last message repeated 2 times
dhcpd: 5 bad IP checksums seen in 5 packets
last message repeated 2 times
dhcpd: 5 bad IP checksums seen in 5 packets
dhcpd: Sending on Socket/fallback/fallback-net
dhcpd: Sending on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
dhcpd: Listening on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
dhcpd: Wrote 0 leases to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
dhcpd: All rights reserved.
dhcpd: Copyright 2004-2008 Internet Systems Consortium.
dhcpd: Internet Systems Consortium DHCP Server V3.0.7
dhcpd: Sending on Socket/fallback/fallback-net
dhcpd: Sending on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
dhcpd: Listening on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
dhcpd: Wrote 0 leases to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
dhcpd: All rights reserved.
dhcpd: Copyright 2004-2008 Internet Systems Consortium.
dhcpd: Internet Systems Consortium DHCP Server V3.0.7

The bad checksum notification made me checking „Disable Hardware Checksum Offloading“ in pfSense „System: Advanced functions“ without success.
…. and the interface list (LAN is up)

WAN interface (rl0)
Status 	up
PPPoE 	up  
MAC address 	00:e0:c5:6a:74:a6
IP address 	xxx.xxx.xxx.xxx  
Subnet mask 	255.255.255.255
Gateway 	217.0.116.247
ISP DNS servers 	217.0.43.97
217.0.43.113
Media 	100baseTX <full-duplex>
In/out packets 	5232/5607 (4.24 MB/707 KB)
In/out errors 	0/0
Collisions 	0

LAN interface (ste3)
Status 	up
MAC address 	00:0d:88:c5:f5:b7
IP address 	192.168.1.221  
Subnet mask 	255.255.255.0
Media 	100baseTX <full-duplex>
In/out packets 	27614/6894 (2.44 MB/5.28 MB)
In/out errors 	0/0
Collisions 	0

VPNprivate interface (tun0)
Status 	up
IP address 	192.168.10.1  
Subnet mask 	255.255.255.255
In/out packets 	0/3 (0 bytes/220 bytes)</full-duplex></full-duplex>

Any more information I could provide that would help analysing the issue?

Thanx for any suggestions,

Klaus

pfSense_LAN-rules.jpg_thumb

wallabybob

Have you run a packet trace on the DHCP client or the pfSense LAN port to verify that DHCP is correctly configured
on the client and pfSense is receiving the DHCP requests?

Without knowing the definition of DHCPports it is difficult to know if your rules are correct.

I presume Interface IP address is the LAN interface's IP address. If that is the case then your second rule is wrong because a DHCP lease renewal will have its destination IP address the DHCP server address, the LAN IP address.

The DHCP related rules can all specify the protocol as UDP rather than TCP/UDP.

wällerklaus

Thanks for the reply.
Here are my answers to your questions in between your original post:

Have you run a packet trace on the DHCP client or the pfSense LAN port to verify that DHCP is correctly configured
on the client and pfSense is receiving the DHCP requests?
here is a tcpdump copied from my original post (scroll down in first code block):

tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
21:54:01.965714 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:04.644946 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:07.964732 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:10.964375 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:13.745063 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:16.706229 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:19.962777 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
21:54:22.962395 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
8 packets captured
114 packets received by filter
0 packets dropped by kernel

At least DHCP requests are arriving at the LAN port. Is it that what you where looking for?

Without knowing the definition of DHCPports it is difficult to know if your rules are correct.
My alias definition of "DHCPports" is: 67, 68, 69, 847, 546, 547, 647, 847

I presume Interface IP address is the LAN interface's IP address. If that is the case then your second rule is wrong because a DHCP lease renewal will have its destination IP address the DHCP server address, the LAN IP address.
That was set to the VPN port, now changed to VPN subnet (IP range 192.168.10.0/24).

The DHCP related rules can all specify the protocol as UDP rather than TCP/UDP.
I didn't think of that making a difference in the result, as I presumed the rules would apply to both, UDP and TCP (logical OR). I was intending to include TFTP (using TCP?) in my DHCP rules. Anyway changed now to UDP only.

Any more suggestions?

wällerklaus

Attached is my new ruleset with the above mentioned changes - unfortunately didn't enable DHCP replies.

Here are some of my alias definitions for the rules:
DHCPports 67, 68, 69, 847, 546, 547, 647, 847 ports used for DHCP
Gateway 192.168.1.221 This router's IP Adress
Router 192.168.1.221 this router = Gateway
VPNsubnet 192.168.10.0/24 IP-Range used for the VPN subnet
privateLAN 192.168.1.0/24 IP-Range used by the private subnet
www 80, 443, 8080, 8443

LAN net is the pysical LAN port (ste3)
WAN address is the IP-adress of the WAN port (rl0)

I guess the later doesn't make sense on the purpose of "Let all LAN pass to WAN" - however shouldn't affect the DHCP issue.

rules2.JPG_thumb

wallabybob

Sorry I didn't pick up the tcpdump in your earlier post.

That shows what I suspect is a violation of the DHCP rules. I believe that the initial DHCP request should be sent to the broadcast IP address (255.255.255.255) rather than what appears to be a network specific broadcast address (166.255.255.255, 36.255.255.255, 164.255.255.255 etc).

It would be interesting to see if a trace on the DHCP client shows the same destination IP address being used. Since you have tried a number of clients and not had any work, I'm inclined to suspect there is something wrong with the LAN interface you are using. Could you try the other NICs on the DLink card or even the motherboard NIC?

wällerklaus

Many thanks for looking into this again and pointing me to that subnet broadcasting phenomenon.

I tried again and this is what the XP-Client has sent (as traced by wireshark - filter on udp port 67 or port 68):
1 0.000000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
2 3.003655000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
3 11.005107000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
4 26.006680000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1

And this is what came in on ste3 on the pfSense box:

tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
16:47:46.941873 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
16:47:49.946678 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
16:47:57.951224 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
16:48:12.958581 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
4 packets captured
314 packets received by filter
0 packets dropped by kernel

So I followed your suggestion and reconfigured my router to have LAN on ste0 instead of ste3 (WAN kept same on rl0).
Tried again, XP-Client sent exactly same packets and here is what was received on ste0 in the pfSense box:

tcpdump -e -i ste0 -l -n -s 1500 port 67 or port 68

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ste0, link-type EN10MB (Ethernet), capture size 1500 bytes
17:23:22.776147 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
17:23:25.778858 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
17:23:34.780778 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
17:23:50.782020 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
4 packets captured
240 packets received by filter
0 packets dropped by kernel

Same phenomenon! Ok - we seem to be on the right track and at least two of four ports are affected. There appears to be a bit dropping on the initial bits os the IP-Adress. Why does this happen only on DHCP requests and only in the IP-Adress and no effect on other data? Can dhcpd get set up to handle both, requests broadcasted on a subnet and requests broadcasted to everyone as it should happen?
I guess the problem might appear only on UDP packets while TCP would cover data loss in the protocol layer by checksum and repeating packets.
If this is a driver problem caused by card-firmware or the driver then I would not go for a replacement of the same type. Just using this ethernet card for the WAN where DHCP is not needed would not resolve my problem as it would still affect ports I want to use for other subnets and also how hall I confirm, that this card (or the driver) would not cause arbitrary data loss, resulting in a lot of traffic overhead for necessary packet repetitions.
Any thoughs on this?

Just to be sure not to have a misconfiguration that we have not seen I'll give it another try with the ethernet port on the motherboard.

Thanks,
Klaus

wällerklaus

After swapping the interfaces to be:

rl0: LAN
ste0: WAN

it works.

IP address MAC address Hostname Start End
192.168.1.150 00:08:0d:64:59:50 MANNS-5200 2010/11/26 21:01:47 2010/11/26 23:01:47

# tcpdump -e -i rl0 -l -n -s 1500 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes
21:01:34.498808 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
21:01:35.001738 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
21:01:39.003367 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
21:01:39.004097 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
21:01:47.003875 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
21:01:47.004567 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
21:01:47.005113 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 363: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 321
21:01:47.616267 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
8 packets captured
248 packets received by filter
0 packets dropped by kernel

Ok, now we know that the DHCP configuration is allright, however I'm wondering if I will end up with the same issue when getting a replacement card of the same type (D-Link DFE-580TX). I think it would be a safe bet to assume it's not a hardware issue but rather firmware or driver related. Staying with the current working setup is not an option as it would keep me with three non-DHCP capable interfaces for OPT1..OPT3. On top there is the question of how much trust I can keep on that card-firmware-driver combination. Does it cause more traffic and less throughput? How can I test that?

Is there any way to confirm or exclude a hardware fault (other than testing replacement cards, which I don't have at hand)? Any recommendations on a cheap 4 port ethernet 32bit PCI card the is known to work 100%?

Thanks again,
Klaus

wallabybob

Some FreeBSD drivers suffer from bit rot - the cards are no longer in sufficient use for them to be tested with drivers in newer releases. Maybe ste is in that category.

It could be worth looking at the FreeBSD revision history for ste. Maybe this problem has been fixed in a later release.

Generally 4 port cards are comparatively expensive. I would be inclined to look at getting a VLAN capable card and use a VLAN capable switch as a "port multiplier". I suspect you would be able to get an 8 port VLAN capable switch for a comparable price to a 4 port NIC.

wällerklaus

Thank you for your excellent support and suggestions. Now I'd better check ste history. I've got this card for about only 15 EUR (= 20 AUD) and I'm afraid there are not many alternatives available with a 32bit PCI interface. The D-Link 570TX is using another chipset but is even older, so even less of a target for driver updates. Anyway I'll follow your suggestion of not only checking the FreeBSD hardware support list but also driver history before deciding for the next. (we might even move this post to hardware related).
For now I've inserted an old SMC 9332BDT 21140A which provides me with DHCP on LAN and OPT1 and what is even better (although 2 ports less) it gives me a noticeable performance improvement. Unfortunately I have no second PCI slot on the motherboard (old ThinClient), so I still need to look for another 4 port card or consider a VLAN switch (probably more expensive).

Klaus

wallabybob

Some alternative 4 port PCI cards: lan1641 and lan1741 from http://www.soekris.com
If buying second hand a card with Intel PRO/100 (fxp) NICs would probably be a good choice. I think a number of the major computer suppliers have produced multi-port network cards with Intel chips under their own brand (HP, COMPAQ etc).

A cheap (US$40) 5 port VLAN capable switch is the RB250G: http://routerboard.com/pricelist.php?showProduct=101

I have no experience with any of the above products.