AW: Problem Radius over VPN

Wed Apr 13 08:06:32 UTC 2022

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 at lists.freeradius.org> Im Auftrag von Michael Schwartzkopff via Freeradius-Users
Gesendet: Mittwoch, 13. April 2022 09:32
An: freeradius-users at lists.freeradius.org
Cc: Michael Schwartzkopff <ms at 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