Radsec Regression Alpine 3.14

[Emile Swarts]

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 at deployingradius.com>
wrote:

> On Sep 14, 2021, at 12:03 PM, Emile Swarts <emile.swarts123 at 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