Re: Is this possible SYN Proxy bug?

[Florian Westphal <fw@strlen.de>]

İbrahim Ercan <ibrahim.metu@gmail.com> wrote:
> I modified your patch as below and now synproxy send mss values as it
> should be. Soom I will test it on real environment.
> I also have another question. When I don't provide --wscale option,
> both client syn-ack an server syn packets have empty wscale. When I
> don't provide --mss option, I realized firewall not set mss value on
> client syn-ack, but it sets mss on server syn. Is that what suppose to
> happen?

The SYN sent to server should reflect/match the SYN received from
client (mss might be smaller due to msstab encoding).

> diff -rupN a/net/ipv4/netfilter/ipt_SYNPROXY.c
> b/net/ipv4/netfilter/ipt_SYNPROXY.c
> --- a/net/ipv4/netfilter/ipt_SYNPROXY.c       2019-06-19
> 09:51:40.163633231 +0300
> +++ b/net/ipv4/netfilter/ipt_SYNPROXY.c      2019-06-20 13:32:18.893025129 +0300
> @@ -71,13 +71,13 @@ free_nskb:
>  static void
>  synproxy_send_client_synack(struct net *net,
>                             const struct sk_buff *skb, const struct tcphdr *th,
> -                           const struct synproxy_options *opts)
> +                           const struct synproxy_options *opts, const
> u16 *client_mssinfo)
>  {
>         struct sk_buff *nskb;
>         struct iphdr *iph, *niph;
>         struct tcphdr *nth;
>         unsigned int tcp_hdr_size;
> -       u16 mss = opts->mss;
> +       u16 mss = *client_mssinfo;

Yes, something like this is needed, i.e. we need to pass two
mss values -- one from info->mss ("server") that we need to
place in the tcp options sent to client and one containing
the clients mss that we should encode into the cookie.

I think you can pass "u16 client_mssinfo" instead of u16* pointer.