[Solved] BOOTP/DHCP rule ?

stevejones · #1 January 23rd, 2010, 21:04

Hello,

After checking pflog I see a lot of:

Code:

00:00:10.614198 rule 5/0(match): block in on re0: 10.47.192.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 325
00:00:00.085813 rule 5/0(match): block in on re0: 10.47.192.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 325

I'm assuming that's from my ISP ?

Should I add a rule to allow this traffic to pass or just leave it ?

What would be a good rule to allow this.

Thanks.

**DutchDaemon** · #2 January 23rd, 2010, 21:13

Does the 10.47.192.1 address belong to you? It's a private IP address, so I doubt your ISP will be doing this (and why would your ISP request an IP address?).

stevejones · #3 January 23rd, 2010, 21:18

No 10.47.192.1 doesn't belong to me that's the weird thing why I thought maybe my ISP was requesting that through my modem.

My LAN is on 192.168.1.0/24

**DutchDaemon** · #4 January 23rd, 2010, 21:29

Can you post ifconfig -a, netstat -rn and arp -a? The only way that that 10.x address can show up in your broadcast traffic is from a connected network.

stevejones · #5 January 23rd, 2010, 21:36

Code:

ifconfig -a
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:1a:4d:f8:89:63
        inet 99.244.135.x netmask 0xfffffe00 broadcast 255.255.255.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
        ether 00:50:ba:68:e2:cf
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX)
        status: active
vr1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
        ether 00:50:ba:1e:77:8c
        media: Ethernet autoselect (none)
        status: no carrier
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33200

Code:

 netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            99.244.134.1       UGS         0   702646    re0
99.244.134.0/23    link#1             U           0        0    re0
99.244.135.x       link#1             UHS         0        0    lo0
127.0.0.1          link#5             UH          0        8    lo0
192.168.1.0/24     link#2             U           2   733417    vr0
192.168.1.1        link#2             UHS         0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%lo0/64                     link#5                        U           lo0
fe80::1%lo0                       link#5                        UHS         lo0
ff01:5::/32                       fe80::1%lo0                   U           lo0
ff02::%lo0/32                     fe80::1%lo0                   U           lo0

Code:

 arp -a
? (192.168.1.1) at 00:50:ba:68:e2:cf on vr0 permanent [ethernet]
? (192.168.1.100) at 00:1a:92:f0:45:07 on vr0 [ethernet]
? (192.168.1.199) at 00:14:a5:5c:a3:21 on vr0 [ethernet]
x.cpe.net.cable.rogers.com (99.244.135.x) at 00:1a:4d:f8:89:63 on re0 permanent [ethernet]

**DutchDaemon** · #6 January 23rd, 2010, 21:51

Interesting. Perhaps someone in that cable network 99.244.134.0/23 is experimenting with a DHCP sever or client (on the public interface instead of the private one). I guess you could run this for a while and see what else comes along. Cable networks are usually a bit 'dirtier' than DSL ones, so I guess this stuff is possible. Oh, and never mind about PF: RFC1918 addresses should never be allowed to traverse your public interface either way.

# tcpdump -s 0 -pnli re0 not net 99.244.134.0/23

stevejones · #7 January 24th, 2010, 02:21

Code:

tcpdump -s 0 -pnli re0 not net 99.244.134.0/23
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:15:45.520937 ARP, Request who-has 72.53.149.70 tell 72.53.149.65, length 46
20:16:14.022728 ARP, Request who-has 72.53.149.42 tell 72.53.149.33, length 46
20:16:56.534186 ARP, Request who-has 72.53.149.75 tell 72.53.149.65, length 46

Just lots of the same as above.

**DutchDaemon** · #8 January 24th, 2010, 03:12

Ok, some people with ill-configured networks. The IP addresses belong to a web host in Ontario, probably multi-homed, or with a cable connection as a backup. Since you're in a network with 512 IP addresses, things like that can happen. Nothing to worry about, as they won't get past your firewall.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
install_state: too many dynamic rule	rugal14	Firewalls	0	December 11th, 2009 00:30
IPF Rule	adz	Firewalls	2	September 24th, 2009 23:14
Freebsd dhcp client from a Windows dhcp server	Dillweed	Networking	12	September 10th, 2009 01:15

The Following User Says Thank You to DutchDaemon For This Useful Post:
stevejones (January 24th, 2010)