-
Notifications
You must be signed in to change notification settings - Fork 149
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.
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
pf+route-to: panic when shared forwarding is enabled #52
Comments
Just for my own reference, so I won't forget.
Lines 5585 to 5587 in a7a4a06
Since we don't want to send the packets back out directly, we likely only want to test if it would be possible to send it out on approx the same spot. |
pf_test() is the dangerous fast path that evaluates outgoing direction on the spot and if we call it we cannot undo it. The goal of shared forwarding is to land in outgoing pf_test() through the proper channels. Besides this != PF_PASS is first and foremost rule evaluation, not specifically sanity checking for higher level TCP input behaviour: here we are receiving an incoming packet that is supposed to hit the local network stack which shouldn't be routed in this direction. Maybe a proper debug trace with line numbers would help prevent this? I'm still not a fan of WireGuard's tendency to break the network stack in general terms. :) |
I'm not exactly sure where we should fix this, but the problem is introduced on the inbound package via pf if I'm not mistaken. Since the normal function discards it on the outbound path, it apparently doesn't matter if the interface doesn't exist. I haven't looked at ipfw by the way, not sure if something similar exists there. It's not per-se an issue with wireguard, sending traffic to an interface that doesn't exist will likely result in this issue when using shared forwarding. There's no rush here, just wanted to drop some notes while reading through the code, if a proper core dump would be better, I can probably generate that later, although I rather wait for 12.1 to dig into this deeper, since it tends to crash faster it seems. |
when ifp is null packets are marked bad, which means *m points to a freed address. reset *m and return in that case.
when ifp is null packets are marked bad, which means *m points to a freed address. reset *m and return in that case.
when ifp is null packets are marked bad, which means *m points to a freed address. reset *m and return in that case.
when ifp is null packets are marked bad, which means *m points to a freed address. reset *m and return in that case.
fixed in #59 fixes the issue |
when ifp is null packets are marked bad, which means *m points to a freed address. reset *m and return in that case.
When shared forwarding is enabled and traffic is send to a non existing interface it can lead to erratic panics it seems.
Tested on both HardenedBSD 11.2 and 12.1, where the latter seems to crash sooner (easier to reproduce).
Steps below are executed on the 12.1 version.
Test setup
client 1 has a couple of tcp sessions (ssh, https) to igb0, while client 2 keeps pinging igb4's address.
Relevant rules:
Interface
wg0
doesn't exist during test.Result
After some time, the machine panics, although the messages are not always exactly alike, I've added some partial textdumps below:
Example from 11.2:
Example from 12.1:
Changing the
route-to
to a non existing address on an existing interface seems to be stable, which is expected.The text was updated successfully, but these errors were encountered: