# BOOTP/DHCP rule ?



## stevejones (Jan 23, 2010)

Hello,

After checking pflog I see a lot of:


```
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 (Jan 23, 2010)

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 (Jan 23, 2010)

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 (Jan 23, 2010)

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


----------



## stevejones (Jan 23, 2010)

```
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
```



```
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
```



```
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 (Jan 23, 2010)

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 (Jan 24, 2010)

```
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 (Jan 24, 2010)

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.


----------

