Re: [NETFILTER]: xt_TCPMSS: Consider reverse route's MTU in clamp-to-pmtu

[Jaco Kroon <jaco@uls.co.za>]

Patrick McHardy wrote:
> Jaco Kroon wrote:
>> Jan Engelhardt wrote:

[[ -- snip -- ]

>>>> use routing rules based on source address, iif etc., so I
>>>> think we should make this optional.
>>>>     
>>> iif yes; should be a matter of in->ifindex or so.
>>>   
>> I'd reckon that's a definite "yes, we should fill in iif and saddr"! 
> 
> 
> saddr and iif don't work without more complicated changes since
> we'd have to use input routing.

Oh well.  For my needs the original simpler patch to simply look at the 
mtu of the in net_device is good enough.  So as far as I'm concerned 
this is "nice to have for the day I need to do IPSec with some 
disfunctional router" or "some really funky asymmetric routing".

>> This should cover 99.99% of cases where this is useful, and the only
>> potentially problematic case I can envision is with asymmetric routing
>> between the gateway this is running on and the final destination.  And
>> chances are that even in those cases the oif of two different incoming
>> routes are going to be the same.
> 
> The problem is that we can't determine all keys used in the
> reverse direction, which becomes obvious if you think of
> mark based routing. So I'm wondering how many setups this
> would break. Leaving the routing as it is and making it
> optional looks safer, with the downside that most users
> probably want this and won't notice the new option.

Or keep to the original "simply look at the mtu of the in net_device as 
provided".  Which is a major improvement and should cover the vast 
majority of cases.  Just make it clear in the man page exactly what 
--clamp-mss-to-pmtu does do, and possibly add a "--clamp-to-mtu 
mtu_value" or "--clamp-to-mss mss_value" option (I'd prefer 
--clamp-to-mtu), which works like --set, but only if the new mss value 
is less than the existing one.  I prefer the mtu version simply because 
it doesn't require me to know how much space needs to be reserved for 
ip/tcp headers.

It's possible to do the path routing stuff with somewhat complicated 
iptables chains, as an example, originally I thought to do this for my 
case (the one described in the need case):

iptables -A FORWARD -i ppp+ -p tcp --tcp-flags SYN,FIN,RST SYN -j CLAMP_MSS
iptables -A FOWARD -p tcp --tcp-flags SYN,FIN,RST SYN -j TCPMSS 
--clamp-mss-to-pmtu

iptables -A CLAMP_MSS -i ppp0 -p tcp --tcp-flags SYN,FIN,RST SYN -j 
TCPMSS --set-mss $(( $mtu_of_ppp0 - 40 ))
iptables -A CLAMP_MSS -i ppp1 -p tcp --tcp-flags SYN,FIN,RST SYN -j 
TCPMSS --set-mss $(( $mtu_of_ppp1 - 40 ))
etc ...

More complex situations can also do this, and people actually setting up 
those kind of setups should be (made) aware of this.

*sigh* if there just wasn't so many flippen firewalls blocking icmp 
fragmentation required packets, and if these packets were handled 
correctly ...

Jaco