Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

firewall: fix rpfilter blocking dhcp offers when no ip was bound yet #31839

Merged
merged 1 commit into from
Nov 24, 2017
Merged

firewall: fix rpfilter blocking dhcp offers when no ip was bound yet #31839

merged 1 commit into from
Nov 24, 2017
+3 −0

Conversation

bluescreen303
Copy link
Contributor

When first bringing up an interface, the DHCP server's offer gets dropped by our firewall because of rpfilter.

Basically no packets will ever match for reverse-path as we don't have an IP address yet, hence nothing would route back through the interface.

dhcpcd then after 10 seconds switches to auto-configuration (APIPA) giving the interface a 169.254.*.* address. It then retries a dhcp request. Only now the OFFER does pass the rpfilter.

This change fixes the initial drops and allows us to gain a proper ip address almost instantly

@GrahamcOfBorg GrahamcOfBorg added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Nov 19, 2017
@andir
Copy link
Member

andir commented Nov 19, 2017

You are right, the first DHCP OFFER message is being dropped.
On my machine with networking.firewall.checkReversePath = false; the same issues occurs and wouldn't be fixed by your proposed solution.

My recommendation would be to actually allow incoming sport 67 & dport 68 udp packets. Possibly only when there is some kind of DHCP client / NetworkManager / … is configured.

@bluescreen303
Copy link
Contributor Author

I cannot replicate the first OFFER being dropped with checkReversePath = false.
It should match the -m conntrack --ctstate RELATED,ESTABLISHED rule and thus be accepted.
With some extra logging that logs every drop (not just tcp rejections) I do not get drops while activating an interface.

@fpletz fpletz self-requested a review November 20, 2017 08:37
@andir
Copy link
Member

andir commented Nov 20, 2017

You are right it should be in conntrack. Turns out what I saw was happening because on the public WiFi I am rotating my MAC-Address per connection the DHCP Server would NACK my initial REQUEST (since the MAC Address changed and the old lease is still valid for some time).

@bluescreen303
Copy link
Contributor Author

ok, so shall we merge this req the way it is?

And I haven't been contributing for a while. What's the rules for cherry-picking this for 17.09?

@fpletz fpletz added this to the 17.09 milestone Nov 24, 2017
fpletz
fpletz approved these changes Nov 24, 2017
View reviewed changes
Copy link
Member

@fpletz fpletz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! 🍻

As this is a bugfix, I'll cherry-pick into 17.09.

@fpletz fpletz merged commit a59864c into NixOS:master Nov 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@fpletz fpletz

Assignees
No one assigned
Labels
10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux
Projects
None yet
Milestone
17.09
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@bluescreen303 @andir @fpletz @GrahamcOfBorg