Posting to a forum issue
-
Hi,
OpenVPN's --mtu related directives are "inside tunnel" options, AFAIK.
Also, the manual is not correct, --mtu-disc is not working IIRC.
Thanks.
-
Made a capture on OPT1, if someone is willing to take a look at it.
Thanks.
0_1544569894586_opt1withvpn.pcap -
Now reading here:
https://github.com/OpenVPN/openvpn/blob/master/INSTALLIf run through a firewall using OpenBSDs packet filter PF and the
filter rules include a "scrub" directive, you may get problems talking
to Linux hosts over the tunnel, since the scrubbing will kill packets
sent from Linux hosts if they are fragmented. This is usually seen as
tunnels where small packets and pings get through but large packets
and "regular traffic" don't. To circumvent this, add "no-df" to
the scrub directive so that the packet filter will let fragments with
the "dont fragment"-flag set through anyway.>Could this somehow be tested?
Thanks.
-
Hmm, Linux sends fragmented packets with df set? Seems.... interesting.
You can disable pfscrub entirely to test that. You could probably make a custom rules file and load it temporarily with
no-dfset.I haven't see this for a long time but we have previously seen OpenVPN tunnels where fragmented packets would make it across the tunnel but never be sent out of the local interface at the other end. That only happened on OpenVPN tunnels where the interface was not assigned. Assigning it worked around it, somehow altering how pf handles the packets. I could see that being this issue.
Steve
-
@stephenw10 said in Posting to a forum issue:
Hmm, Linux sends fragmented packets with df set? Seems.... interesting.
The DF flag tells routers not to fragment. The originating device is still free to fragment.
-
Mmm, I guess so.
-
@stephenw10 said in Posting to a forum issue:
Mmm, I guess so.
If the source wants to send a packtet that's too big to fit within the MTU, it might split it into more than one piece. This is typically done with UDP, but not TCP. These days, the world is moving to path MTU detection. It's mandatory on IPv6 and now used on IPv4. On Linux, with IPv4, the DF flag is set on everything, but in Windows TCP only. As for TCP, don't forget that every packet is a fragment, unless the entire data can be carried in a single packet.
The reason for moving away from fragmentation is to reduce the performance hit at routers, along with reassembling at the destination.
-
So, ticking
"IP Do-Not-Fragment compatibility"
makes the issue go away.
I'm not sure if that is the right solution or somehow tell Linux not to set DF bit on fragmented packets...Or is my conclusion wrong?
Thanks.
-
I don't know if that is the proper fix. My thought would be to find out what's causing this. What packets are being fragmented? If that setting only affects fragmented packets that have DF set, then I suppose it wouldn't be a problem. Still, I'd want to know why it's needed. As I mentioned, DF is used these days, for everything on Linux and TCP on Windows.
-
This post is deleted!
