Re: fragmented ipv4[udp] ignored by server.
Hello And good day. One small update. I set up the same freeradius configuration with official freeradius docker image and my radius eap configuration. Used vmd as hyper-visor and alpine linux to run docker. And pf to redirect/nat traffic to freeradius. And it worked! Also previously same configuration of pf and freeradius worked with Freebsd to get eap tls authentication work. May be it's some default openbsd configuration or pf rules. Thank you. On 3/6/23 14:20, Mikhael Lialin wrote: Hello Tom. It's a local setup. So radius server and eapol_client are located on the near ports of cisco sg350 switch. And there is no rules on this switch present regarding fragmented packets. Anyway it's capable of rspan, and it's possible to mirror traffic from one port to another for analyse. to be sure where those packet's loss. However this requires one more pc in this scheme. In freeradius documentation (in/usr/local/share/examples/freeradius/mods-available/eap) mentioned that server and client certificates should have 509 extensions for server and client authentication. And they have. Thank you. On 3/6/23 02:27, Tom Smyth wrote: Hi Mikhael, Moving this on to Misc List as it is more approiaate for support type requests, It may not be OpenbSD, that is ignoring the fragments, depending on your setup an intermediate device ( NAT router etc) could be proccessing the IP fragments incorrectly and or dropping them... IP fragments are a pain as they dont really match the protocol of the original packet and have all sorts of issues when traversing multipath (hashed) multipath routes between the source and destination.. cloudflare have a really good article on this https://blog.cloudflare.com/ip-fragmentation-is-broken/ Hope this is of help... On Sun, 5 Mar 2023 at 22:04, Mikhael Lialin wrote: Hi. I'm successfully configured eap tls with freeradius. However with default value for fragment_size in wpa_supplicant.conf which equals 1398 - packets get fragmented and seems ignored by the server. Both systems are openbsd 7.2 here is output from thsark: --target radius-- 9 124.886123 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 10 124.894967 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 11 124.914163 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 12 125.010446 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 13 125.014979 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 14 125.032537 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 15 125.034214 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 16 125.045650 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 --source eapol_test with wpa_supplicant.conf--- 1 0.00 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 2 0.011025 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 3 0.027023 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 4 0.126651 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 5 0.127440 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 6 0.148742 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 7 0.149411 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 8 0.161846 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 9 0.179447 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=b444) 10 3.193244 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=b576) 11 9.213196 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=ef21) 12 21.233280 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=00d0) eapol_test fails setting fragment_size = 1212 in wpa_supplicant.conf and getting success. output from tshark: --target radius-- 1 0.00 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 2 0.006613 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 3 0.024538 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 4 0.104617 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 5 0.106355 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 6 0.114877 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 7 0.118679 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 8 0.128309 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 9 0.145442 10.10.2.10 ? 10.10.2.1 RADIUS 1415 Access-Request id=4 10 0.160230 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=4 11 0.161621 10.10.2.10 ? 10.10.2.1
Re: fragmented ipv4[udp] ignored by server. OT: pf optimization setup
Tom Smyth : > IP fragments are a pain as they dont really match the protocol of the > original packet and have all sorts of issues when traversing multipath > (hashed) multipath routes between the source and destination.. > cloudflare have a really good article on this > https://blog.cloudflare.com/ip-fragmentation-is-broken/ Thank you for this one, Tom I'd like to ask if it could be possible to have a new option between aggressive and normal for 'set optimization' in pf? Or if you consider the aggressive setting enough good for little desktops with security in mind too? Thanks, -- Daniele Bonini
Re: fragmented ipv4[udp] ignored by server.
Hello Tom. It's a local setup. So radius server and eapol_client are located on the near ports of cisco sg350 switch. And there is no rules on this switch present regarding fragmented packets. Anyway it's capable of rspan, and it's possible to mirror traffic from one port to another for analyse. to be sure where those packet's loss. However this requires one more pc in this scheme. In freeradius documentation (in/usr/local/share/examples/freeradius/mods-available/eap) mentioned that server and client certificates should have 509 extensions for server and client authentication. And they have. Thank you. On 3/6/23 02:27, Tom Smyth wrote: Hi Mikhael, Moving this on to Misc List as it is more approiaate for support type requests, It may not be OpenbSD, that is ignoring the fragments, depending on your setup an intermediate device ( NAT router etc) could be proccessing the IP fragments incorrectly and or dropping them... IP fragments are a pain as they dont really match the protocol of the original packet and have all sorts of issues when traversing multipath (hashed) multipath routes between the source and destination.. cloudflare have a really good article on this https://blog.cloudflare.com/ip-fragmentation-is-broken/ Hope this is of help... On Sun, 5 Mar 2023 at 22:04, Mikhael Lialin wrote: Hi. I'm successfully configured eap tls with freeradius. However with default value for fragment_size in wpa_supplicant.conf which equals 1398 - packets get fragmented and seems ignored by the server. Both systems are openbsd 7.2 here is output from thsark: --target radius-- 9 124.886123 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 10 124.894967 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 11 124.914163 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 12 125.010446 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 13 125.014979 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 14 125.032537 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 15 125.034214 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 16 125.045650 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 --source eapol_test with wpa_supplicant.conf--- 1 0.00 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 2 0.011025 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 3 0.027023 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 4 0.126651 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 5 0.127440 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 6 0.148742 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 7 0.149411 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 8 0.161846 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 9 0.179447 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=b444) 10 3.193244 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=b576) 11 9.213196 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=ef21) 12 21.233280 10.10.2.10 ? 10.10.2.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=00d0) eapol_test fails setting fragment_size = 1212 in wpa_supplicant.conf and getting success. output from tshark: --target radius-- 1 0.00 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 2 0.006613 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 3 0.024538 10.10.2.10 ? 10.10.2.1 RADIUS 373 Access-Request id=1 4 0.104617 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 5 0.106355 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=2 6 0.114877 10.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 7 0.118679 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=3 8 0.128309 10.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 9 0.145442 10.10.2.10 ? 10.10.2.1 RADIUS 1415 Access-Request id=4 10 0.160230 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=4 11 0.161621 10.10.2.10 ? 10.10.2.1 RADIUS 1372 Access-Request id=5 12 0.262102 10.10.2.1 ? 10.10.2.10 RADIUS 161 Access-Challenge id=5 13 0.263753 10.10.2.10 ? 10.10.2.1 RADIUS 191 Access-Request id=6 14 0.281330 10.10.2.1 ? 10.10.2.10 RADIUS 226 Access-Accept id=6 --source eapol_test with wpa_supplicant.conf--- 1 0.00 10.10.2.10 ? 10.10.2.1 RADIUS 188 Access-Request id=0 2 0.010060 10.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0
Re: fragmented ipv4[udp] ignored by server.
Hi Mikhael, Moving this on to Misc List as it is more approiaate for support type requests, It may not be OpenbSD, that is ignoring the fragments, depending on your setup an intermediate device ( NAT router etc) could be proccessing the IP fragments incorrectly and or dropping them... IP fragments are a pain as they dont really match the protocol of the original packet and have all sorts of issues when traversing multipath (hashed) multipath routes between the source and destination.. cloudflare have a really good article on this https://blog.cloudflare.com/ip-fragmentation-is-broken/ Hope this is of help... On Sun, 5 Mar 2023 at 22:04, Mikhael Lialin wrote: > Hi. > > I'm successfully configured eap tls with freeradius. > > However with default value for fragment_size in wpa_supplicant.conf > which equals 1398 - packets get fragmented and seems ignored by the server. > > Both systems are openbsd 7.2 > > here is output from thsark: > > --target radius-- > 9 124.886123 10.10.2.10 ? 10.10.2.1RADIUS 188 Access-Request id=0 > 10 124.89496710.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 > 11 124.914163 10.10.2.10 ? 10.10.2.1RADIUS 373 Access-Request id=1 > 12 125.01044610.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 > 13 125.014979 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=2 > 14 125.03253710.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 > 15 125.034214 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=3 > 16 125.04565010.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 > > > --source eapol_test with wpa_supplicant.conf--- > > 1 0.00 10.10.2.10 ? 10.10.2.1RADIUS 188 Access-Request id=0 > 2 0.01102510.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 > 3 0.027023 10.10.2.10 ? 10.10.2.1RADIUS 373 Access-Request id=1 > 4 0.12665110.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 > 5 0.127440 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=2 > 6 0.14874210.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 > 7 0.149411 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=3 > 8 0.16184610.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 > 9 0.179447 10.10.2.10 ? 10.10.2.1IPv4 1514 Fragmented IP > protocol (proto=UDP 17, off=0, ID=b444) > 10 3.193244 10.10.2.10 ? 10.10.2.1IPv4 1514 Fragmented IP > protocol (proto=UDP 17, off=0, ID=b576) > 11 9.213196 10.10.2.10 ? 10.10.2.1IPv4 1514 Fragmented IP > protocol (proto=UDP 17, off=0, ID=ef21) > 12 21.233280 10.10.2.10 ? 10.10.2.1IPv4 1514 Fragmented IP > protocol (proto=UDP 17, off=0, ID=00d0) > > eapol_test fails > > setting fragment_size = 1212 in wpa_supplicant.conf and getting success. > > output from tshark: > > --target radius-- > 1 0.00 10.10.2.10 ? 10.10.2.1RADIUS 188 Access-Request id=0 > 2 0.00661310.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=0 > 3 0.024538 10.10.2.10 ? 10.10.2.1RADIUS 373 Access-Request id=1 > 4 0.10461710.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=1 > 5 0.106355 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=2 > 6 0.11487710.10.2.1 ? 10.10.2.10 RADIUS 1320 Access-Challenge id=2 > 7 0.118679 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=3 > 8 0.12830910.10.2.1 ? 10.10.2.10 RADIUS 300 Access-Challenge id=3 > 9 0.145442 10.10.2.10 ? 10.10.2.1RADIUS 1415 Access-Request id=4 > 10 0.16023010.10.2.1 ? 10.10.2.10 RADIUS 106 Access-Challenge id=4 > 11 0.161621 10.10.2.10 ? 10.10.2.1RADIUS 1372 Access-Request id=5 > 12 0.26210210.10.2.1 ? 10.10.2.10 RADIUS 161 Access-Challenge id=5 > 13 0.263753 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request id=6 > 14 0.28133010.10.2.1 ? 10.10.2.10 RADIUS 226 Access-Accept id=6 > > --source eapol_test with wpa_supplicant.conf--- > > 1 0.00 10.10.2.10 ? 10.10.2.1RADIUS 188 Access-Request > id=0 > 2 0.01006010.10.2.1 ? 10.10.2.10 RADIUS 106 > Access-Challenge id=0 > 3 0.023662 10.10.2.10 ? 10.10.2.1RADIUS 373 Access-Request > id=1 > 4 0.10807210.10.2.1 ? 10.10.2.10 RADIUS 1320 > Access-Challenge id=1 > 5 0.108734 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request > id=2 > 6 0.11863210.10.2.1 ? 10.10.2.10 RADIUS 1320 > Access-Challenge id=2 > 7 0.119341 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request > id=3 > 8 0.13202610.10.2.1 ? 10.10.2.10 RADIUS 300 > Access-Challenge id=3 > 9 0.147236 10.10.2.10 ? 10.10.2.1RADIUS 1415 Access-Request > id=4 > 10 0.16330010.10.2.1 ? 10.10.2.10 RADIUS 106 > Access-Challenge id=4 > 11 0.164158 10.10.2.10 ? 10.10.2.1RADIUS 1372 Access-Request > id=5 > 12 0.26551410.10.2.1 ? 10.10.2.10 RADIUS 161 > Access-Challenge id=5 > 13 0.266328 10.10.2.10 ? 10.10.2.1RADIUS 191 Access-Request
