2.1: bogons vs DHCP

[senser]

In 2.1, when "deny bogons" is enabled on an interface DHCP traffic is blocked as well:

# block bogon networks
# http://www.cymru.com/Documents/bogon-bn-nonagg.txt
# http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt
block in log quick on $BRIDGE0 from <bogons>to any label "block bogon IPv4 networks from BRIDGE0"
antispoof for bridge0
# allow access to DHCP server on BRIDGE0
pass in quick on $BRIDGE0 proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"
pass in quick on $BRIDGE0 proto udp from any port = 68 to 10.1.0.1 port = 67 label "allow access to DHCP server"
pass out quick on $BRIDGE0 proto udp from 10.1.0.1 port = 67 to any port = 68 label "allow access to DHCP server"
antispoof for vr1</bogons> 

I am not 100% sure, but I think in 2.0.x it was the other way around: The rule to allow DHCP traffic came first. So you could block bogons and still have DHCP working. Is this new behaviour intentional? Thanks

[stephenw10]

Hmm, has the bogon list included private networks?

Steve

[doktornotor]

The bogonv6 list still includes the stupid 8000::/1 entry which kills fe80 for IPv6. As for IPv4, no, not really, none RFC1918 IPs included.

[senser]

To be more specific:
<bogons>includes 0.0.0.0/8 so this DHCP traffic is blocked

proto udp from any port = 68 to 255.255.255.255 port = 67

by

block in log quick on $BRIDGE0 from <bogons> to any</bogons>
```</bogons>

[mhab12]

Could this be the reason that I am seeing disconnects related to the WAN DHCP lease for my cable modem?

Before I upgraded to 2.1 I never had any connectivity issues.  Now I am finding that I have lost connectivity seemingly at random over the past few days since the upgrade.  When I check out the status/interfaces page the WAN only shows an IPv6 IP beginning with fe80 but no IPv4 address.  Once I release/renew I see the IPv4 address again and regain connectivity.  Possibly related or should I start a new thread?

[stephenw10]

Remove 'block bogons' from the WAN interface. That will tell you straight away if it's related. You may have to reset the firewall states or reboot.

Steve

[mikeisfly]

Any update on this? Since upgrading to 2.1 Release I have been seeing random internet drops as well. I haven't really had the time to really trouble shoot the issue although sometimes I have released and renewed the WAN IP and that fixed the issue. Sometimes the GUI has become unresponsive so I SSH into my box and reboot the system which fixes the problem 100% of the time. Sorry for the limited details I was just looking around to see if others where having the same issue. I have setup PfSense (Green Field Install) for a friend on 2.1 Release 64bit and he has had to reset a couple of times over the past two weeks as well. My uncle who is on 2.1-RC0  (i386)
built on Thu May 23 19:52:31 EDT 2013 has not experienced any issues what so ever. When I was on the 64 bit build of this firmware I have had no issues as well. So far I have unchecked State Killing on Gateway Failure to see if this resolves the issue. If not then I will check it back and try unchecking block bogon networks. I should know in a week if the problem has been resolved.

[NOYB]

@doktornotor:

The bogonv6 list still includes the stupid 8000::/1 entry which kills fe80 for IPv6. As for IPv4, no, not really, none RFC1918 IPs included.

The bogons code strips out some of the entries that are in the list before it's applied.  Don't recall off top of my head which ones.

See /etc/rc.update_bogons.sh lines 122 and 130.

[phil.davis]

/etc/rc.update_bogons.sh
IPv4:

egrep -v "^192.168.0.0/16|^172.16.0.0/12|^10.0.0.0/8" /tmp/bogons > /etc/bogons

IPv6:

egrep -iv "^fc00::/7" /tmp/bogonsv6 > /etc/bogonsv6

http://tools.ietf.org/html/rfc5735

0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network.  Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network ([RFC1122], Section
3.2.1.3).

Protocols like DHCP (where the source [client] is trying to find out its IP address) need to put something in the source IP field. 0.0.0.0 is a good choice.

So, there is an argument that 0.0.0.0/8 (or at least some of it) is "link-local" IPv4 address space. So it is not appropriate to consider it "bogon", as it is used legitimately on any local link by whatever protocol has the need.

[kaipanoi]

This was a very frustrating bug. Thanks to every here for sorting it out.

@phil.davis:

/etc/rc.update_bogons.sh
IPv4:

egrep -v "^192.168.0.0/16|^172.16.0.0/12|^10.0.0.0/8" /tmp/bogons > /etc/bogons

IPv6:

egrep -iv "^fc00::/7" /tmp/bogonsv6 > /etc/bogonsv6

http://tools.ietf.org/html/rfc5735

0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network.  Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network ([RFC1122], Section
3.2.1.3).

Protocols like DHCP (where the source [client] is trying to find out its IP address) need to put something in the source IP field. 0.0.0.0 is a good choice.

So, there is an argument that 0.0.0.0/8 (or at least some of it) is "link-local" IPv4 address space. So it is not appropriate to consider it "bogon", as it is used legitimately on any local link by whatever protocol has the need.