İbrahim Ercan <[email protected]> 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.
