Great ok, thanks again. Unsure what I've done wrong to inflate the packet sizes so much, guessing this is not a common issue. My configuration assigns dynamic VLANS from a database, suddenly suspect this may be related. Will do another test without this post-auth functionality enabled. server default { listen { type = auth ipaddr = * port = 1812 limit { max_connections = 64 lifetime = 0 idle_timeout = 30 } } } authorize { eap } authenticate { eap } post-auth { update control { Tmp-String-0 := "%{sql:SELECT vlan from lookup where (common_name = '%{request:TLS-Client-Cert-Common-Name}' OR mac = '%{request:Calling-Station-Id}') and remote_ip = '%{request:Packet-Src-IP-Address}'}" } update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := &control:Tmp-String-0 } } preacct { } accounting { } session { } pre-proxy { } post-proxy { } } On Thu, 22 Apr 2021 at 18:44, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 22, 2021, at 12:42 PM, Emile Swarts <emile.swarts123@gmail.com> wrote:
Thanks for the quick reply Alan. Really helps narrow it down. I forgot to mention, I am seeing "Fragmented IP protocol" packets in the capture, which seems to correspond to each of the Access-Requests. Could this have something to do with MTU configuration of Freeradius?
It's a network MTU issue. The UDP packets are too large, and the network fragments them. UDP packet fragmentation really doesn't work well across the wider internet.
The solution is to use a VPN which doesn't fragment the packets. Or, use RADIUS over TLS. The "stunnel" utility may help here.
You can change "fragment_size" in mods-enabled/eap. Lower it to 600 or so, and might will help. But it's not a *fix* for the problem.
The best solution is to use a network which doesn't fragment the packets.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html