DHCP on bridged lan/wlan

iimre

Oddly enough this was not working for me but after I rebooted the client, it does work.

Not sure why you're having trouble, it works here.

O.K. with what settings?

sullrich

OPT1(ATH0) bridged to WAN(SIS1)

iimre

@sullrich:

OPT1(ATH0) bridged to WAN(SIS1)

… but what I want is to bridge OPT1(ATH0) to LAN(fxp1)...

sullrich

That works as well. I have both configurations here that I can restore.

Just restored a similar config and its fine.

iimre

That's good, in this case I've got hope to set it up finally :)
But now I've got two lines repeated on the diag_logs_filter page:

Dec 30 21:54:50 pf: 000056 rule 141/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Dec 30 21:54:50 pf: 000121 rule 141/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

I have rules allow everything from OPT1 to LAN and vice versa.

sullrich

Okay, in this case I bridged LAN to WAN.

Issue the following command from a shell:

update_file.sh /etc/inc/filter.inc && shutdown -r now

And let me know if its fixed after reboot.

iimre

I've got the following result, what do I wrong?

##############
$ update_file.sh /etc/inc/filter.inc && shutdown -r now
Status: 404
Content-type: text/html
X-Powered-By: PHP/4.4.0

No input file specified.
trying to fetch latest /etc/inc/filter.inc
Status: 404
Content-type: text/html
X-Powered-By: PHP/4.4.0

No input file specified.
##############

sullrich

Try replacing /etc/inc/filter.inc with http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/~checkout~/pfSense/etc/inc/filter.inc?rev=1.575.2.54;content-type=text%2Fplain;only_with_tag=RELENG_1

iimre

BINGO! Thanks Scott!
This has done magic :)
Will this modification in filter.inc be included in next release?

sullrich

Yep.

Thanks for testing!

iimre

Life is not so easy. :(

Next morning as I switch on my notebook, I didn't receive ip address again.

In the logs I found the followings:
#################
Dec 31 07:46:31 pf: 000126 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Dec 31 07:46:31 pf: 287219 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Dec 31 07:46:30 pf: 000134 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Dec 31 07:46:30 pf: 7. 386391 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

#################

Previous evening it was working fine.

sullrich

Run pfctl -vvsa | grep 316

What's the output of that?

iimre

Hi Scott,

As per your request I run it with the following result.
##############
$ pfctl -vvsa | grep 316
@316 pass in quick on ng0 inet proto ah from 194.143.xxx.yyy to 87.97.aaa.bbb keep state label "IPSEC: OfficeDMZ - inbound ah proto"

##############
…BUT ... probably it is not the same rule #316 anymore. (It seem to me changes time to time, maybe when I reboot.)

Meanwhile I solved it, so that I created an
" UDP * 68 * 67 *" rule on my OPT1 (ath0) interface.

I don't know what security hole creates it, if any?
I don't know that after applying your new filter.inc yesterday night, why worked without this rule?
Is ARP filtering is on when interface is bridged?
This static arp enabling is on the dhcp server tab originally, but since now it is bridged, that's no more available.
(Of course it is enabled on LAN as well)