Hi Michael, I just discovered a very curious thing... If a device in the main office tries to connect to the Radius, the pakets will be fragmented, too, but they are greater than the pakets from second office: 13 2022-04-13 09:55:29,248146 10.0.21.46 10.0.21.10 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=53fb) 14 2022-04-13 09:55:29,248768 10.0.21.10 10.0.21.46 RADIUS 108 Access-Challenge id=216 15 2022-04-13 09:55:29,274741 10.0.21.46 10.0.21.10 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=53fd) 16 2022-04-13 09:55:29,275374 10.0.21.10 10.0.21.46 RADIUS 108 Access-Challenge id=217 17 2022-04-13 09:55:29,301244 10.0.21.46 10.0.21.10 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=53fe) As you see, the fragmented pakets are 1516 bytes, instead of just 1500... Since the pakets are _sent_ from the VPN server in the second office and they are already "short", I think, the problem should be there... I try to sniff the pakets in the second office to discover the point where the pakets will be "shorted". Regards Luca -----Ursprüngliche Nachricht----- Von: Freeradius-Users <freeradius-users-bounces+l.bertoncello=queo-group.com@lists.freeradius.org> Im Auftrag von Michael Schwartzkopff via Freeradius-Users Gesendet: Mittwoch, 13. April 2022 09:32 An: freeradius-users@lists.freeradius.org Cc: Michael Schwartzkopff <ms@sys4.de> Betreff: Re: Problem Radius over VPN On 13.04.22 09:24, Luca Bertoncello wrote:

Hi list!

I already reported in March my problems using Freeradius over VPN. I spent many time searching the problem, and maybe I found something, but I have no idea how to correct the problem...

So, short explanation: Main office with Freeradius, connected via OpenVPN to our central VPN-Server. Second office with the AccessPoints, connected via OpenVPN to our central VPN. "Normal" pakets from second office to main office (and viceversa) go through both VPNs.

Now, I sniffed the pakets on all servers (VPN server on second office, central VPN server, VPN server on main office and Freeradius), and I discovered that some pakets are blocked.

Wireshark on VPN server of the second office:

12 2022-03-25 14:39:48,154608 10.0.21.10 10.6.21.10 RADIUS 979 Access-Challenge id=86 13 2022-03-25 14:39:48,476555 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c1) 14 2022-03-25 14:39:48,507473 10.0.21.10 10.6.21.10 RADIUS 92 Access-Challenge id=87 15 2022-03-25 14:39:48,533183 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c2) 16 2022-03-25 14:39:51,533406 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=42d9)

Wireshark on central VPN:

12 2022-03-25 14:39:48,129787 10.0.21.10 10.6.21.10 RADIUS 979 Access-Challenge id=86 13 2022-03-25 14:39:48,488993 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c1) 14 2022-03-25 14:39:48,501213 10.0.21.10 10.6.21.10 RADIUS 92 Access-Challenge id=87

No other pakets after paket 14 (ID 87) reach the central VPN serve, so the problem "must be" either on the central VPN server or on the VPN server oft he second office... Now the very question: do someone have an idea why just the first fragmented paket run over all VPNs and the other one do not?

Thanks a lot Luca - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

hi, a VPN tunnel adds some byte to the IP packet. If a packet is already 1500 byte it has to be fragmented. This is what happens here. Some firewalls and VPN devices cannot deal with fragmentation correctly and drop the packet. So it never reaches the other side and communication is disrupted. RADIUS especially has a problem with long certificates that exceed the MTU limit of the network. Please avoid network fragmentation or at least, configure path MTU discovery. Best solution would be to configure fragmentation detection within the  VPN setup. IPsec with IKEv2 has the ability to detect the MTU and the need to build smaller encrypted packets. Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Apr 13, 2022, at 9:23 AM, Luca Bertoncello <L.Bertoncello@queo-group.com> wrote:

I didn't changed the fragment_size, but I tried to reduce it and set it to 800. Unfortunately no changes in the situation...

Then something else is going on in your local configuration. The EAP module will limit the EAP-Message attribute to "fragment_size". So if the RADIUS packets are still >1500 bytes, then the problem isn't EAP. Look at the debug output. What attributes are in the Access-Challenge responses? There should be: EAP-Message State And not really much else. If you have tons of other attributes in the Access-Challenge packets, that's the problem. Go to sites-enabled/default, and look for this text: # # Filter access challenges. # Post-Auth-Type Challenge { # remove_reply_message_if_eap # attr_filter.access_challenge.post-auth } Uncomment the "attr_filter.access_challenge.post-auth" line, and the Access-Challenge packets should get a lot smaller. Alan DeKok.

On Apr 13, 2022, at 9:52 AM, Luca Bertoncello <L.Bertoncello@queo-group.com> wrote:

Hi Alan,

I started Freeradius with the -X Option. In the Access-Challenge Response sind nur:

- EAP-Message

Did you check that the EAP-Message attributes were about "fragment_size" in length?

- Message-Authentication - State

No other attributes...

Did you check that the Access-Challenge packet is less than 1500 bytes in length? This *IS* printed in the debug output. There is no magic here. If the packets are larger than 1500 bytes, then something is making them larger than 1500 bytes. Since you're not posting the debug output, there's little more we can do to help. Alan DeKok.

On Apr 13, 2022, at 10:19 AM, Luca Bertoncello <L.Bertoncello@queo-group.com> wrote:

Hi Alan,

I would say, the answer ist 261 bytes:

(1) Sent Access-Challenge Id 68 from 10.0.21.10:1812 to 10.6.21.10:54656 length 0 (1) EAP-Message = 0x01e803ec0dc0000012f5160303003d020000390303a1b6eb58bf2ce8ab3f12a20eacc792ded76b9714c15bebd6444f574e4752440100c030000011ff01000100000b000403000102001700001603030f7d0b000f79000f760008243082082030820608a0030201020215009613f3945007364d2b46c3df (1) Message-Authenticator = 0x00000000000000000000000000000000 (1) State = 0xfd8b5894fc6355beb76ffb2667a966eb (1) Finished request

Or do I understand wrong?

The EAP-Message is encoded as binary data (not hex), so it's really 120 bytes for that, plus the rest. But that's minor. Yes, this packet is small. If you're still seeing fragmentation, then you have to track it down: * which packets are being fragmented? * what is in those packets? * where do they come from? The only way to fix this is by using a methodical approach to narrow down the problem. It might have been RADIUS at the start, but it looks like that isn't it. So... what else is going on? We don't have access to your systems. But since the problem isn't RADIUS, there isn't a lot more we can do here. Alan DeKok.

Hi, yesterday evening I tried to configure the VPNs to use the "fragment" option. And now it works... Regards Luca -----Ursprüngliche Nachricht----- Von: Freeradius-Users <freeradius-users-bounces+l.bertoncello=queo-group.com@lists.freeradius.org> Im Auftrag von Alan Buxey Gesendet: Mittwoch, 13. April 2022 17:11 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: Problem Radius over VPN Allow fragmented UDP? (Much like people running RADIUS across WAN have to do at perimeter firewalls) alan On Wed, 13 Apr 2022, 08:24 Luca Bertoncello, <L.Bertoncello@queo-group.com> wrote:

Hi list!

I already reported in March my problems using Freeradius over VPN. I spent many time searching the problem, and maybe I found something, but I have no idea how to correct the problem...

So, short explanation: Main office with Freeradius, connected via OpenVPN to our central VPN-Server. Second office with the AccessPoints, connected via OpenVPN to our central VPN. "Normal" pakets from second office to main office (and viceversa) go through both VPNs.

Now, I sniffed the pakets on all servers (VPN server on second office, central VPN server, VPN server on main office and Freeradius), and I discovered that some pakets are blocked.

Wireshark on VPN server of the second office:

12 2022-03-25 14:39:48,154608 10.0.21.10 10.6.21.10 RADIUS 979 Access-Challenge id=86 13 2022-03-25 14:39:48,476555 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c1) 14 2022-03-25 14:39:48,507473 10.0.21.10 10.6.21.10 RADIUS 92 Access-Challenge id=87 15 2022-03-25 14:39:48,533183 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c2) 16 2022-03-25 14:39:51,533406 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=42d9)

Wireshark on central VPN:

12 2022-03-25 14:39:48,129787 10.0.21.10 10.6.21.10 RADIUS 979 Access-Challenge id=86 13 2022-03-25 14:39:48,488993 10.6.21.10 10.0.21.10 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=41c1) 14 2022-03-25 14:39:48,501213 10.0.21.10 10.6.21.10 RADIUS 92 Access-Challenge id=87

No other pakets after paket 14 (ID 87) reach the central VPN serve, so the problem "must be" either on the central VPN server or on the VPN server oft he second office... Now the very question: do someone have an idea why just the first fragmented paket run over all VPNs and the other one do not?

Thanks a lot Luca - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html