SYNPROXY *NAT/redirects etc.

SYNPROXY *NAT/redirects etc.

[Christian Ruppert]

Hi,

I noticed that neither *NAT nor redirects will work when using the 
SYNPROXY module with e.g. those settings:
net.netfilter.nf_conntrack_tcp_loose=0
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.netfilter.nf_conntrack_tcp_loose=0
sysctl -w net.ipv4.tcp_timestamps=1

iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED 
-j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

So when doing a redirect for example, the SYNPROXY will open the 
connection to the original destination address and port but it will not 
go through the rest of the iptables rules and thus the redirect/NAT has 
no effect at all. DNAT might be somewhat different though, I wasn't able 
to figure out to where it tries to establish the connection.
If you disable the SYNPROXY it will work as expected.

I saw that a NF_ACCEPT will be used in the module and I assume that's 
why it does not further through the rules. I'm not sure if XT_CONTINUE 
(like in the handshake part) would be possible here or work at all. Or 
is there any other workaround to get this working? Or am I using it 
wrong? Is that by design?

-- 
Regards,
Christian Ruppert
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in

Re: SYNPROXY *NAT/redirects etc.

[Pascal Hambourg]

Christian Ruppert a écrit :
> 
> I noticed that neither *NAT nor redirects will work when using the 
> SYNPROXY module with e.g. those settings:
> net.netfilter.nf_conntrack_tcp_loose=0
> sysctl -w net.ipv4.tcp_syncookies=1
> sysctl -w net.netfilter.nf_conntrack_tcp_loose=0
> sysctl -w net.ipv4.tcp_timestamps=1
> 
> iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack

This rule disables connection tracking which is required for stateful
NAT operation.

> iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED 
> -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Re: SYNPROXY *NAT/redirects etc.

[Christian Ruppert]

Hi Pascal,

On 2015-06-23 23:33, Pascal Hambourg wrote:
> Christian Ruppert a écrit :
>> 
>> I noticed that neither *NAT nor redirects will work when using the
>> SYNPROXY module with e.g. those settings:
>> net.netfilter.nf_conntrack_tcp_loose=0
>> sysctl -w net.ipv4.tcp_syncookies=1
>> sysctl -w net.netfilter.nf_conntrack_tcp_loose=0
>> sysctl -w net.ipv4.tcp_timestamps=1
>> 
>> iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
> 
> This rule disables connection tracking which is required for stateful
> NAT operation.

Thanks! From what I've seen/read, this rule is required or am I wrong? 
It needs to do the complete handshake and upon success it will 
pass/forward the connection or act somehow like a real proxy.

> 
>> iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate 
>> INVALID,UNTRACKED
>> -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
>> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

-- 
Regards,
Christian Ruppert

Re: SYNPROXY *NAT/redirects etc.

[Pascal Hambourg]

Christian Ruppert a écrit :
> 
> On 2015-06-23 23:33, Pascal Hambourg wrote:
>> Christian Ruppert a écrit :
>>>
>>> iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
>>
>> This rule disables connection tracking which is required for stateful
>> NAT operation.
> 
> Thanks! From what I've seen/read, this rule is required or am I wrong? 

AFAIK it's not strictly required for SYNPROXY operation. It just saves
connection tracking resources.

Re: SYNPROXY *NAT/redirects etc.

[Christian Ruppert]

Hey,

On 2015-06-24 23:57, Pascal Hambourg wrote:
> Christian Ruppert a écrit :
>> 
>> On 2015-06-23 23:33, Pascal Hambourg wrote:
>>> Christian Ruppert a écrit :
>>>> 
>>>> iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
>>> 
>>> This rule disables connection tracking which is required for stateful
>>> NAT operation.
>> 
>> Thanks! From what I've seen/read, this rule is required or am I wrong?
> 
> AFAIK it's not strictly required for SYNPROXY operation. It just saves
> connection tracking resources.

I tried some different setups but somehow I don't get it working.

So if we keep using the "sysctl -w 
net.netfilter.nf_conntrack_tcp_loose=0"
Which is still being used by:
iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID -j 
SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460

I thought I could just avoid that --notrack rule and therefor do 
something like:
iptables -I INPUT -p tcp -m tcp --syn -j SYNPROXY --sack-perm 
--timestamp --wscale 7 --mss 1460

But that doesn't work (neither new nor established connections work, 
default INPUT is DROP btw.). What's the difference here between the 
raw/PREROUTING rule that basically just marks it as untracked so it can 
be passed to the extension in the filter table and just doing "--syn -j 
SYNPROXY ..." in the filter table? Does the "--notrack" one actually 
more?
I need to keep the NAT/redirect functionality while using the SYNPROXY 
extension.

-- 
Regards,
Christian Ruppert