BOOTP/DHCP rule ?

stevejones

stevejones

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.
 
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?).
 
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
 
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.
 
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]
 
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
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top