[strongSwan] Overriding DF on XFRM interfaces

[Noel Kuntze]

Hello John,

I am not aware of if the kernel tracks the assigned TCP MSS of the connections it knows of.
Conntrack does not have that information. So it's a good question why exactly that happens.

Can you double check if there is not maybe something like a local proxy running that could
be the cause of that? Also, what is the currently set MTU on the interface?
Does it coincide with the MSS (taking the TCP overhead into account)?

I agree that it is likely extremely fragile. A good way would be a userspace proxy, like squid.
Squid knows about conntrack, so can transparently proxy connections, even without tproxy (speaking from memories).

Kind regards
Noel


Am 03.12.21 um 15:35 schrieb John Marrett:
> I am working on a VPN solution connecting some appliances on two
> different networks. I’m using an x86 openwrt router with strongswan
> 5.9.2 and kernel 5.4.154. The systems I am connecting exhibit
> non-compliant TCP MSS behaviour. They are, for unknown reasons,
> ignoring the MSS from their peers and sending oversized packets. They
> also ignore ICMP unreachable messages indicating path MTU, I have
> confirmed that the ICMP unreachable messages are not blocked and they
> have been captured directly on the system sending the problematic
> traffic. I do not have control over the appliances and need to solve
> the issues at the network level.
> 
> I'm using a modern IKEv2 / XFRM based configuration for this VPN. I
> would like to ignore the DF bit and fragment traffic passing through
> the VPN tunnel. This fragmentation could occur before or after
> encapsulation, it's not significant to me.
> 
> If I was using a GRE tunnel I could use the ignore-df configuration
> [1], however there doesn't appear to be an equivalent with an xfrm
> interface.
> 
> I have managed to "solve" my problem, though I do not understand the
> solution or how it works. If I create the following iptables rule to
> adjust the MSS on traffic traversing the xfrm interface:
> 
> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o xfrm0
> -j TCPMSS --set-mss 1240
> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -i xfrm0
> -j TCPMSS --set-mss 1240
> 
> Then, in addition to the expected modification of the mss field, my
> TCP traffic will be fragmented, ignoring the DF bit.
> 
> Here's an excerpt of traffic in ingress to the router:
> 
> 09:23:56.103022 IP 10.1.34.10.5060 > 10.1.61.20.25578: Flags [P.], seq
> 883:1906, ack 1760, win 260, length 1023
> 09:23:56.119864 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
> 1906, win 501, length 0
> 09:24:01.448960 IP 10.1.34.10.5060 > 10.1.61.20.25578: Flags [P.], seq
> 1906:3271, ack 1760, win 260, length 1365
> 09:24:01.467771 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
> 3148, win 501, length 0
> 09:24:01.467810 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
> 3271, win 501, length 0
> 
> And egress on the xfrm interface (In addition to being sent over a VPN
> connect the traffic is also being NATed by the VPN router):
> 
> 09:23:56.103150 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [P.], seq
> 881:1902, ack 1750, win 260, length 1021
> 09:23:56.119828 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
> 1902, win 501, length 0
> 09:24:01.449067 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [.], seq
> 1902:3142, ack 1750, win 260, length 1240
> 09:24:01.449135 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [P.], seq
> 3142:3265, ack 1750, win 260, length 123
> 09:24:01.467724 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
> 3142, win 501, length 0
> 09:24:01.467725 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
> 3265, win 501, length 0
> 
> The packet with length 1365 has been split into a packet of 1240 bytes
> and a second of 123.
> 
> Without these rules I see the expected behaviour, the packets are
> dropped and ICMP unreachable messages are sent indicating the path
> MTU.
> 
> Is anyone able to explain why, in addition to adjusting the MSS, this
> mangle configuration is allowing fragmentation ignoring the DF bit?
> While the solution is working as I need it to, I'm concerned that it
> may be extremely fragile.
> 
> Is there a better way to solve this problem?
> 
> Thanks in advance for any help you can offer,
> 
> -JohnF
> 
> [1] https://man7.org/linux/man-pages/man8/ip-tunnel.8.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20211215/92e01db0/attachment.sig>