From: Vasili Pupkin <diggest@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Jordan Glover <Golden_Miller83@protonmail.ch>
Cc: "William J. Tolley" <william@breakpointingbad.com>,
WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
Date: Fri, 6 Dec 2019 19:03:54 +0300 [thread overview]
Message-ID: <1bcf459c-4c08-33b2-19da-31cb62fd56a1@gmail.com> (raw)
In-Reply-To: <CAHmME9qUWRO76NJrnO5iNoWuauvMT3kf+qM1bY49bVkcBFXY9g@mail.gmail.com>
On 06.12.2019 18:08, Jason A. Donenfeld wrote:
> On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>
>>> If we can make nft coexistance work reliably, perhaps we can run the
>>> nft rule on systems where the nft binary simply exists.
>>>
>> Will this work correctly on systems where nft binary exist but only
>> iptables rules are used?
> That's what I meant by, "if we can make nft coexistance work reliably."
>
Take a look at the table on the bottom of this page
https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F
On my system their rules coexist fine. Both nftables and iptables are
just high level interfaces to kernel netfilter hooks after all, if
either of them drop the packet then the packet is dropped. It is also
possible to write the same filter using iptables, not as easy and not as
beautiful as nft though. Finally wireguard can do this directly
interacting with netfilter as the last resort.
I'd like if kernel developers reconsider the default system behavior on
this... It is so stupid that the system expose all its IPs on all
interfaces by default. But Linus don't like patches that break things
and this will break some bad network setups, yes weak and insecure but
still.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-12-06 16:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 19:13 Regarding "Inferring and hijacking VPN-tunneled TCP connections" Jason A. Donenfeld
2019-12-05 19:50 ` Vasili Pupkin
2019-12-05 20:24 ` Jason A. Donenfeld
2019-12-05 21:28 ` Vasili Pupkin
2019-12-06 15:18 ` Jason A. Donenfeld
2019-12-06 17:21 ` Vasili Pupkin
2019-12-07 20:51 ` Lonnie Abelbeck
2019-12-06 12:58 ` William J. Tolley
2019-12-06 15:06 ` Jordan Glover
2019-12-06 15:08 ` Jason A. Donenfeld
2019-12-06 16:03 ` Vasili Pupkin [this message]
2019-12-06 16:12 ` Jordan Glover
2019-12-06 17:06 ` Vasili Pupkin
2019-12-05 20:10 ` zrm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bcf459c-4c08-33b2-19da-31cb62fd56a1@gmail.com \
--to=diggest@gmail.com \
--cc=Golden_Miller83@protonmail.ch \
--cc=Jason@zx2c4.com \
--cc=william@breakpointingbad.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.