DHCP Server Gateway setting not working

johnpoz

Not sure why you would point anything to your proxy as a its default gateway.. But to pfsense to hand out the default gateway just put in the IP on dhcp server tabe its that easy.. Do you have something in the advanced dhcp options that conflict with that setting?

dhcp server will hand out gateway you put in there, or if left blank pfsense interface IP.. Your not putting something in that is not in the network of the dhcp server are you?

gateway.png_thumb

rbmk

The proxy is a transparent one. The intention is to direct dhcp clients to it so that traffic can be decrypted/filtered/inspected by that appliance's rules, while still allowing static IP clients to specify pfSense's IP as their gateway (and to have filter rules to only allow certain IPs to connect to the internet that way). This setup works as I'm intending it to when I specify the proxy server's IP as the gateway statically. The problem is that despite the fact that I've specified the proxy's IP as the gateway in the DHCP server settings, the actual offer still specifies pfSense's LAN IP. Please see attached screenshot showing specified gateway and packet capture of DHCP offer. Also, I didn't explicitly say this or show it, but the machine does indeed end up with pfSense's LAN IP as its default gateway.

dhcp.png_thumb

johnpoz

once you change the gateway to that IP, did you apply it and did your dhcp service actually restart?

edit:
Do you happen to have a reservation/static setup for that mac - this would hand out something different then what you have in the default config of the pool

doktornotor

@rbmk:

The proxy is a transparent one.

So why do you need to redirect GW there? Really what you are doing makes totally zero sense. Plus, when it's transparent it CANNOT be bypassed by the way you are suggesting.

rbmk

@johnpoz:

once you change the gateway to that IP, did you apply it and did your dhcp service actually restart?

Yes, I both applied and manually restarted the service.

johnpoz

check my edit you sure you don't have a reservation or static for this mac.. That would hand out different info then your default configuration.

rbmk

@johnpoz:

check my edit you sure you don't have a reservation or static for this mac.. That would hand out different info then your default configuration.

I have no static entries at all.

johnpoz

what version of pfsense are you running.. This is pretty straight forward stuff.. So either the config didn't load or didn't save?

You sure pfsense is the dhcp server your getting that from? Looks like a whole second before an offer goes out after the discover.. That seems really really long..

So in your sniff see offer at 5.34 and then offer at 6.35 that sure seems like really slow response.. Notice here in this transaction the time from discover to offer is ms..

edit
sure you don't have something the optional settings - if you put in say option 3 router in there it overwrites what you put in the gateway box in the gui. Just tested this put in .19 in the gateway and in the options put in 3 with .18 – got .18 no .19

offerfromdiscover.png_thumb

optionsdhcp.png_thumb

rbmk

Thanks for your continued attention to this question.

I checked the dhcpd.conf file, and it does look like it saved in there…

[2.2.3-RELEASE][root@firewall.localdomain]/var/dhcpd/etc: cat dhcpd.conf

option domain-name "localdomain";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;
option arch code 93 = unsigned integer 16; # RFC4578

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
one-lease-per-client true;
deny duplicates;
ping-check true;
update-conflict-detection false;
authoritative;
subnet 192.168.2.0 netmask 255.255.255.0 {
pool {
range 192.168.2.100 192.168.2.244;
}

option routers 192.168.2.8;
option domain-name-servers 192.168.2.1;

}

I agree that nearly a second seems like a long time, but that offer is indeed coming from pfsense. Here's the interface showing the mac that is making the same offer in that packet capture, (which I attached):

em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:2f:98:9c
inet6 fe80::20c:29ff:fe2f:989c%em0 prefixlen 64 scopeid 0x1
inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast>

bootp.pcapng

johnpoz

well clearly it seems to be in the config file.. You sure dhcpd reloaded and read the config?

I would reboot so your SURE that happened..

rbmk

@johnpoz:

I would reboot so your SURE that happened..

That worked!

I suppose I was taking the 'unix' approach and assuming that a reboot would not be necessary. I did restart the service several times from the configurator, and it reported as successful, but maybe it wasn't actually restarting under the covers.

Thanks for your help and prompt replies!!

johnpoz

yeah I didn't have to reboot mine.. But clearly it was in the config - so if still handing out the old stuff then it didn't read the config for some reason.

Could of always killed the process, and then started it back up.. So curious now what is your response time from discover to offer..