On Thu, Dec 22, 2016 at 4:56 PM, Tom Hacohen wrote:
>
>
> On 22 Dec 2016 12:35, "Florian Westphal" wrote:
>
> Tom Hacohen wrote:
>> I'm sorry for repeating myself, however I'd like to stress out again,
>> that while your workaround fixes an
Tom Hacohen wrote:
> I'm sorry for repeating myself, however I'd like to stress out again,
> that while your workaround fixes an inconsistency between iptables and
> nftables, the scenario itself is caused by the buggy behaviour of
> masquerade with "lo", and that needs to be
On Wed, Dec 21, 2016 at 2:39 AM, Liping Zhang wrote:
> 2016-12-20 23:16 GMT+08:00 Tom Hacohen :
>> On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang wrote:
>>> According to the explanations in nftables wifi:
>>>
On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang wrote:
> According to the explanations in nftables wifi:
> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
>
> You should add the following nft rules(I agree this is tricky and
>
2016-12-17 22:18 GMT+08:00 Liping Zhang :
>
> For loopback connection, the request packets will traverse:
> OUTPUT->POSTROUTING->PREROUTING->INPUT
> and the source ip will be modified in nat POSTROUTING hook.
>
> Meanwhile the reply packets will also traverse:
>
Hi Tom,
2016-12-13 21:28 GMT+08:00 Tom Hacohen :
> Hi,
>
> I've recently migrated from iptables (no modules loaded anymore) to
> nftables and came across a weird situation that looks like a bug to
> me.
>
> When using "masquerade" it always sets the ip address to that of one
> of