Ok thanks, Had a look at that C code, but understanding why it's not doing the right thing is a bit beyond me I'm afraid. I have a packet capture from the server as well: "188.220.232.134","10.180.101.189","TCP","76","56345 > 2083 [SYN] Seq=0 Win=25200 Len=0 MSS=1260 SACK_PERM=1 TSval=45917131 TSecr=0 WS=64" "10.180.101.189","188.220.232.134","TCP","76","2083 > 56345 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=8961 SACK_PERM=1 TSval=3850271683 TSecr=45917131 WS=128" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=1 Ack=1 Win=25216 Len=0 TSval=45917135 TSecr=3850271683" "188.220.232.134","10.180.101.189","TLSv1.2","217","Client Hello" "10.180.101.189","188.220.232.134","TCP","68","2083 > 56345 [ACK] Seq=1 Ack=150 Win=28032 Len=0 TSval=3850271693 TSecr=45917135" "10.180.101.189","188.220.232.134","TLSv1.2","1316","Server Hello" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=1249 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=2497 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=3745 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TLSv1.2","656","Certificate, Server Key Exchange, Certificate Request, Server Hello Done" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=1249 Win=27712 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=2497 Win=30208 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=3745 Win=32704 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=4993 Win=35200 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=5581 Win=37696 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=150 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","68","2083 > 56345 [FIN, ACK] Seq=5581 Ack=1398 Win=30464 Len=0 TSval=3850271729 TSecr=45917153" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=1398 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=2646 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TLSv1.2","509","Certificate" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=4335 Ack=5582 Win=37696 Len=0 TSval=45917158 TSecr=3850271729" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5582 Win=0 Len=0" Can see the server sending RST packets at the end. Thanks, Emile On Tue, Sep 14, 2021 at 5:41 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 14, 2021, at 12:03 PM, Emile Swarts <emile.swarts123@gmail.com> wrote:
Thanks for that.
Had a look at the debug logs:
... (0) (TLS) Application data. (0) FAILED in TLS handshake receive
Hmm... that message means that FreeRADIUS is ready for application data (i.e. stuff inside of the radsec tunnel), but OpenSSL thinks that the TLS handshake isn't finished.
See src/main/tls_listen.c, the label "check_for_setup". It does:
* if SSL init is not done try to do more handshake if handshake data to send, then send that
* else there's no handshake data to send, then the SSL init MUST be done but OpenSSL says it's not... so who knows what's up :(
It's not clear what's going on here. Maybe some wireshark debugging of the TLS packets might help. But I haven't had any luck getting wireshark to decode TLS recently.
I've been unable to find much about the default security policies of Openssl / Alpine. Is this something I can update myself, that could potentially solve the problem?
See the link I posted... setting the cipher_list will over-ride the default security policies.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html