AW: Problem Radius over VPN
Luca Bertoncello
L.Bertoncello at queo-group.com
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
More information about the Freeradius-Users
mailing list