Option 1 Does the sender of the RADIUS request actually support Framed-MTU. If not RADIUS isn’t magic it can’t make the RADIUS client do things it has not support for. Q2. Is this something like a router that’s getting the MTU update ? If that’s the case the client devices behind it will still send large packets. There are ways to try to enforce smaller MTU packets at least for TCP but its distinctly messy. For UDP (as in your example) you are at the mercy of the client which may not even look at the network MTU. A. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Luca Bertoncello <L.Bertoncello@queo-group.com> Date: Wednesday, 23 March 2022 at 15:51 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] AW: AW: Setting Framed-MTU Attribute Hi Matthew, I have an "update reply" in my server part. Of course not in post-auth, since the problem is previous... I added it to the preacct section, but of course it does not help. My problem is that the communication does not survive the site-to-site VPN (with OpenVPN). With tcpdump I see: 13 0.341592 10.6.21.10 10.0.21.10 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=2021) Searching for this error got me the "result", I have to change the Framed-MTU and as I didn't got it after one day work, I asked the list. Now you write, this change will not help. And I see, it does not help, as you predicted. The MTU on the VPN tunnel is currently 1500. Or I did not understand what you mean? Thanks Luca Bertoncello -----Ursprüngliche Nachricht----- Von: Freeradius-Users <freeradius-users-bounces+l.bertoncello=queo-group.com@lists.freeradius.org> Im Auftrag von Matthew Newton Gesendet: Mittwoch, 23. März 2022 16:38 An: freeradius-users@lists.freeradius.org Betreff: Re: AW: Setting Framed-MTU Attribute On 23/03/2022 15:28, Luca Bertoncello wrote:
I read the site-available/default but since I don't know what I have to search for, it's very difficult...
As Alan said, the default config is full of examples of how to update attributes. You just have to read it. Updating attributes is also documented in the unlang man pages. e.g. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreeRADIUS%2Ffreeradius-server%2Fblob%2Fv3.0.x%2Fraddb%2Fsites-available%2Fdefault%23L864-L867&data=04%7C01%7Calister.winfield%40sky.uk%7Cfd6d152165f24f726faf08da0ce503da%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637836475147410898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g6PQ267Fv3daSeZlcLz6OMdYT5F7Caqayy%2F4DjieTvY%3D&reserved=0
Currently, I tried to change the mods_enabled/eap and set use_tunneled_reply to yes. I also changed the mods-config/attr_filter/access_challenge and added Framed-MTU = 1344 at the start of the "DEFAULT" section. No changes in my situation.
Because as you've already been told, attr_filter *removes* attributes, it doesn't add them. update reply { Framed-MTU := 1000 } From your original post, though, I suspect this won't help. That attribute is for telling the NAS what MTU to use. It won't make its way through to any device on wifi. If you have a VPN in the way of that RADIUS server that's causing MTU problems, drop the MTU on the NAS or RADIUS server, or fix the VPN / PMTUD so that the path MTU is calculated correctly. You can't fix that by changing attributes. -- Matthew - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=04%7C01%7Calister.winfield%40sky.uk%7Cfd6d152165f24f726faf08da0ce503da%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637836475147410898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ot4EtK32HEDbUpW17zLtko1Bru8vhE3GEq%2FM%2BpagDaM%3D&reserved=0 - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=04%7C01%7Calister.winfield%40sky.uk%7Cfd6d152165f24f726faf08da0ce503da%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637836475147410898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ot4EtK32HEDbUpW17zLtko1Bru8vhE3GEq%2FM%2BpagDaM%3D&reserved=0 -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD