I have successfully configure freeradius with mysql.
i can radtest using command :
sudo radtest alice password 192.168.2.3 1812 testing123
Sending Access-Request of id 187 to 192.168.2.3 port 1812
User-Name = "alice"
User-Password = "password"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 192.168.2.3 port 1812, id=187, length=20
Now i try squid using radius authentication.
i followed step by step from :
http://safesrv.net/setup-squid-and-freeradius-on-centos-5/#comment-1043
But i got error message log on cache.log
Warning: Received invalid reply digest from server
Warning: Received invalid reply digest from server
Warning: Received invalid reply digest from server
squid_rad_auth: No response from RADIUS server
On radius -X debug there is error message like bellow :
Sending duplicate reply to client localprivate port 42003 – ID: 2
Sending Access-Reject of id 2 to 192.168.2.3 port 42003
Waking up in 2.9 seconds.
rad_recv: Access-Request packet from host 192.168.2.3 port 42003, id=2, length=63
Sending duplicate reply to client localprivate port 42003 – ID: 2
Sending Access-Reject of id 2 to 192.168.2.3 port 42003
Waking up in 0.9 seconds.
Found Auth-Type = PAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group PAP {…}
[pap] login attempt with password “b9?I? +�(�Ч�Y�?”
[pap] Using clear text password “password”
[pap] Passwords don’t match
++[pap] returns reject
Failed to authenticate the user.
WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS!
Using Post-Auth-Type REJECT
What is that error ? How i can solve this
Thanks
Snoop your generated Accessreq and try to decode the encrypted password using your shared secret with wireshark. Looks like your test client doesnt encode the password correct.
Make sure testing123 is correctly configured on server side.
Related
I get the following exception when trying to send a mail with JavaMail with OAuth2:
javax.mail.MessagingException: Can't send command to SMTP host (javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate))
I have already checked dozens of stackOverFlow posts and none of the solutions work.
This is my javamail config (commented out some other configs I have tried):
...
String oauth2_access_token = <procedure to aquire a token>;
Properties props = new Properties();
props.put("mail.host",config.getString("MAILSERVER"));
props.put("mail.smtp.port", config.getString("MAILPORT"));
props.put("mail.smtp.auth", "true");
props.put("mail.transport.protocol", "smtp");
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.smtp.starttls.required", "true");
props.put("mail.smtp.ssl.protocols", "TLSv1.1 TLSv1.2 TLSv1.3");
//props.put("mail.smtp.ssl.trust", "*");
props.put("mail.smtp.auth.mechanisms", "XOAUTH2");
//props.put("mail.smtp.auth.xoauth2.disable", false);
//props.put("mail.smtp.sasl.enable", "true");
//props.put("mail.smtp.auth.login.disable","true");
//props.put("mail.smtp.auth.plain.disable","true");
props.put("mail.debug", "true");
props.put("mail.debug.auth", "true");
// Connect
javax.mail.Session mailSession = javax.mail.Session.getInstance(props);
mailSession.setDebug(true);
SMTPTransport transport = (SMTPTransport) mailSession.getTransport("smtp");
transport.connect(config.getString("MAILSERVER"),
Integer.parseInt(config.getString("MAILPORT")), config.getString("MAILUSER"), oauth2_access_token);
Here is some output:
[apache-tomcat-9.0.54]: DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "smtp.office365.com", port 587, isSSL false
[apache-tomcat-9.0.54]: 220 SOMEANONYMIZEDSERVERPREFIX.outlook.office365.com Microsoft ESMTP MAIL Service ready at Wed, 16 Mar 2022 10:16:37 +0000
DEBUG SMTP: connected to host "smtp.office365.com", port: 587
[apache-tomcat-9.0.54]: EHLO MY_COMPUTER_NAME
[apache-tomcat-9.0.54]: 250-SOMEANONYMIZEDSERVERPREFIX.outlook.office365.com Hello [MY_IP_ADRESS]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
STARTTLS
[apache-tomcat-9.0.54]: 220 2.0.0 SMTP server ready
[apache-tomcat-9.0.54]: EHLO MY_COMPUTER_NAME
[apache-tomcat-9.0.54]: ERROR 2022-03-16 11:16:39,407 [..MyProgramException..] - javax.mail.MessagingException: Can't send command to SMTP host (javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate))
I think it has to do with issuing the AUTH command because it is not listed in output. The connection over TLS is established successfully so I think the SSLHandshake Exception might be misleading. So what gives?
Might it have to do with the token? The scope I had to use for the token aquisition is ".default". "Mail.Send" didn't work.
I am using the newest JavaMail version 1.6.2 and AdoptOpenJdk 11.0.12.
I also double checked java.security config. TLS 1v2 and 1v3 algorithms are not disabled.
I found the solution myself. Maybe somone can make use of it:
The code above was not false to my knowledge. The actual reason was, that I should not have used a token acquisition with client credentials but only with username/password and client id.
I am not sure if JavaMail supports this because in the documentation I could not find anything about it. The rare examples about this are usually with client credentials.
As you can see above, no AUTH command was triggered because I had not the permission to do it obviously.
What I needed to do aswell was to use the Microsoft Graph API not only to aquire a token via "password/username provider" (this type) instead of the "client credential provider" (link) but also to actually trigger a send mail command via Microsoft Graph API (link).
The client credential provider was in my case not sufficient because the admin had not specified permissions to send mails.
Thus, I didn't use JavaMail anymore for this and needed another token acquisition provider.
Command radtest test testing1234294106 127.0.0.1 18120 testing123
below is the output getting
Sent Access-Request Id 176 from 0.0.0.0:56553 to 127.0.0.1:1812 length 90
User-Name = "test"
User-Password = "testing1234294106"
NAS-IP-Address = 127.0.1.1
NAS-Port = 18120
Message-Authenticator = 0x00
Cleartext-Password = "testing1234294106"
Sent Access-Request Id 176 from 0.0.0.0:56553 to 127.0.0.1:1812 length 90
User-Name = "test"
User-Password = "testing1234294106"
NAS-IP-Address = 127.0.1.1
NAS-Port = 18120
Message-Authenticator = 0x00
Cleartext-Password = "testing1234294106"
Sent Access-Request Id 176 from 0.0.0.0:56553 to 127.0.0.1:1812 length 90
User-Name = "test"
User-Password = "testing1234294106"
NAS-IP-Address = 127.0.1.1
NAS-Port = 18120
Message-Authenticator = 0x00
Cleartext-Password = "testing1234294106"
(0) No reply from server for ID 176 socket 3
No reply, is frustrating. So here are general steps to diagnose a No reply situation. At the end of this post, I point out the solution to the OP's original question.
Diagnosis Steps
If you get "No reply" from radtest, the first step is check the output of radiusd (which you need to have running in debug mode with cmd radiusd -X).
This will help you diagnose whether the request is being ignored or if the request isn't even making it to radiusd.
Radiusd Ignoring Request
In radiusd, if you see a message telling you that the request was "Ignored", read the reason for it being ignored and resolve the problem.
Radiusd With No Output
Alternatively, if radiusd -X doesn't show any output after attempting to connect, then most likely your request isn't even making it to the radiusd listener. This could happen if you're specifying an invalid ip address or port, or if a firewall is blocking the request, or if there's a routing problem.
NOTE: I noticed that some default configurations run the radius server auth port on 18120 instead of 1812. Double check the listener port number by checking the output of radiusd -X. The very end of the output should say "Listening for connections on..." followed by the IP Address and Port.
Solution to OP's problem
The Op's radtest command is incorrectly formatted. It says
radtest test testing1234294106 127.0.0.1 18120 testing123
The correct format is:
radtest test testing1234294106 127.0.0.1:18120 0 testing123
You can check this by running 'radtest --help'. The format for the ip port portion is "ip:port nas-port". In this case the nas-port can be 0.
You can also see, that since the port wasn't specified, the resulting request goes out on the default port 1812 (when it should have been 18120):
Sent Access-Request Id 176 from 0.0.0.0:56553 to 127.0.0.1:1812
I don't know why the out-of-box configuration for freeRadius uses 18120 for testing. But I think this throws a lot of people off. Especially since radtest syntax normally reads: ip:18120 0 (note the separated 0s).
I've got a build of the OpenVPN3 client library (https://github.com/OpenVPN/openvpn3) connecting to an OpenVPN 2 server (2.4.4). This is working for my mac and windows builds, but failing when the client is iOS.
The iOS client appears to connect, in the sense that I get my custom up script invoked and I can see what I assume are keepalive/heartbeat packets going back and forth between client and server. The client doesn't time out as long as these packets are allowed to continue. However, as soon as the client attempts to access any web page over the tunnel, I get packets dropped on the server side with errors like the following:
Fri Mar 15 20:08:27 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=10 seenFri Mar 15 20:08:28 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
Fri Mar 15 20:08:29 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=5 seen
Fri Mar 15 20:08:30 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=9 seen
Fri Mar 15 20:08:31 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=8 seen
Fri Mar 15 20:08:32 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=2 seen
Fri Mar 15 20:08:34 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=13 seen
Fri Mar 15 20:08:38 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
I'm using the same server and client configs for iOS as I was using when the client was Mac and Windows.
Server configs:
port 1194
proto udp
dev tun
ca /opt/certs/ca-cert.pem
cert /opt/certs/server.pem
key /opt/certs/server-key.pem
dh /opt/certs/dh2048.pem
tls-auth /opt/certs/ta.key 0
server 10.8.0.0 255.255.0.0
keepalive 5 15
verb 3
script-security 3
client-connect "/usr/local/bin/sdp-updown"
client-disconnect "/usr/local/bin/sdp-updown"
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
Client configs:
dev tun
proto udp
remote ... server and port omitted
remote-cert-tls server
key-direction 1
server-poll-timeout 5
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
... routes omitted
<ca>
... CA omitted
</ca>
<cert>
... cert omitted
</cert>
<key>
... private key omitted
</key>
<tls-auth>
... OpenVPN static key omitted
</tls-auth>
I've tried a number of different settings for cipher and tls-cipher. When those settings are set to values that are supported on both sides I can get connected, but get the same IP packet with unknown IP version error. Obviously when either cipher or tls-cipher isn't supported on either server or client we fail to negotiate TLS and don't get connected at all.
I found a number of troubleshooting forum posts regarding this error and most of them are resolved by setting the compression settings to the same value on both ends. My iOS client build seems to think that it has no ability to perform compression, even though I think I've linked successfully against the LZ4 library. I compiled the LZ4 library for iOS, and included the LZ4=1 when building a dylib for OpenVPN itself. However, when the iOS client connects it reports settings like:
ENV[IV_AUTO_SESS] = 1
ENV[IV_COMP_STUBv2] = 1
ENV[IV_COMP_STUB] = 1
ENV[IV_LZO_STUB] = 1
ENV[IV_PROTO] = 2
ENV[IV_TCPNL] = 1
ENV[IV_NCP] = 2
ENV[IV_PLAT] = ios
ENV[IV_VER] = 3.1.2
I notice that this does not include IV_LZ4, which I take to mean that the client thinks it can't perform compression. That said, even when my configs include disabled compression I get the same results. I tried omitting any compression setting at all, comp-lzo no, compress stub, and compress stub-v2. None of these resulted in any different behavior.
My questions are thus:
What could be the cause of my IP packet with unknown IP version errors when actually sending packets over the data channel?
If what I'm seeing is actually a compression setting error, how do I convince OpenVPN to disable compression entirely? Alternatively, what have I done wrong to link LZ4 into my iOS OpenVPN dylib?
we recently upgraded our solace VMR to pub sub+, I am trying to configure rest delivery point using SSL. I created a rest consumer and set authentication schema as client-certificate, it is not taking and displaying as none. I did all this from CLI.The ssl settings looks good default cipher and trusted CN. the rest consumer was down with failure reason " Remote SSL handshake failed: sslv3 alert handshake failure"
I suspect solace is not sending certificate when it is trying to connect. Any thoughts on setting Authentication scheme as client-certificate?
Check that the rest-consumer is configured correctly to use SSL, and to authenticate with client-certificate. The CLI commands are:
show message-vpn <vpn_name> rest rest-consumer <rest-consumer_name> authentication
show message-vpn <vpn_name> rest rest-consumer <rest-consumer_name> detail
Also, check that the CA of the remote host certificate is trusted with CLI command:
show certificate-authority ca-name * cert
At the minimum, the root issuer of the remote host certificate must be one of the configured certificate-authorities in that CLI command.
If those check out, ensure that the remote endpoint is indeed requesting client-certificates in the first place. You can check the raw packets on the wire with Wireshark:
Internet Protocol Version 4, Src: <remote-host-ip>, Dst: <solace-ip>
...
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
...
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
...
TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
Content Type: Handshake (22)
...
TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
...
Handshake Protocol: Certificate Request
Handshake Type: Certificate Request (13)
Then, you should see a client certificate response from the Solace container:
Internet Protocol Version 4, Src: <solace-ip>, Dst: <remote-host-ip>
...
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
...
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
...
Certificates (xxx bytes)
...
Certificate (...,id-at-commonName=...)
I'm trying to connect from Jenkins (docker container) to a windows server (VM) running a Cygwin sshd. The problem I'm facing is that (seemingly) at random I can or cannot connect. This is both with the 'SSH Plugin' (username/password) and via shell SSH command (key pair).
From Jenkins the debug information tells me:
debug1: connect to address [serverIP] port 22: Connection refused
When it isn't working the sshd log tells me:
debug1: fd 4 clearing O_NONBLOCK
debug1: Forked child 1128.
debug3: send_rexec_state: entering fd = 7 config len 232
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from [clientIP] port 59440 on 0.0.0.0 port 22
Could not write ident string to [clientIP] port 59440
When it is working I get the following in the sshd log:
debug1: fd 4 clearing O_NONBLOCK
debug1: Forked child 1708.
debug3: send_rexec_state: entering fd = 7 config len 232
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from [clientIP] port 56742 on [serverIP] port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.4
Difference I'm seeing is the 0.0.0.0 instead of the serverIP but I cannot find why this is.
I've tried setting up a job that runs every 5 minutes to see if there was a pattern, but I could find none.
On the server I've made a wireshark trace these are the packages I get
Client to server: [SYN]
Client to server: [TCP Out-Of-Order] (same package as previous [SYN])
Server to client: [RST, ACK]
Client to server: [SYN, ACK]
Client to server: [TCP Retransmission] (same package as previous [SYN, ACK])
I'm a bit stumped on the "Could not write ident string to [clientIP]" message and I'm having some trouble finding more information about why this is happening.
Any help on troubleshooting this further or information on why this message is displayed is welcome.
"Connection refused" normally means the server isn't accepting connections to the IP address and port that you requested. The service that you're trying to connect to may not be listening for connections, or it may be listening to a different address and/or port.
"Connection refused" can also be caused by a firewall blocking connections. In your case, given that the service is logging an incoming connection but without the client IP address, my guess is that you have some kind of firewall or malware detection software running on the server, and it's interfering with these connection attempts.
You'll need to access this firewall software, figure out why it's blocking these connections, and configure it to stop interfering.