I have installed a WordPress website on my Google Cloud Compute Engine, but I am not able to send mail. So after searching the internet discovered Sendmail.
Installed and configured the latest version by:
$ sudo apt-get update
$ sudo apt-get install sendmail
Ran the sendemail config, answered "yes" to everything:
$ sudo sendmailconfig
Edited the 127.0.0.1 localhost instance-1 line (instance-1 is my Google cloud instance):
$ sudo vim /etc/hosts # changed
Restart Apache:
sudo service apache2 restart
When I run the command below in my terminal, nothing happens, and I am not be able to run commands anymore. So it looks like the process is not ending.
$ sendmail example#email.com
The output of $ date | sendmail -v example#email.com returns:
example#email.com... Connecting to [127.0.0.1] via relay...
220 instance-1.c.myproject.internal ESMTP Sendmail 8.14.4/8.14.4/Debian-8; Wed, 24 Aug 2016 09:42:18 GMT; (No UCE/UBE) logging access from: localhost(OK)-localhost [127.0.0.1]
>>> EHLO instance-1.c.myproject.internal
250-instance-1.c.myproject.internal Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> VERB
250 2.0.0 Verbose mode
>>> MAIL From:<info#instance-1.c.myproject.internal> SIZE=29
250 2.1.0 <info#instance-1.c.myproject.internal>... Sender ok
>>> RCPT To:<example#email.com>
>>> DATA
250 2.1.5 <example#email.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
My log file /var/log/mail.log show al lot of these kind of lines:
Aug 25 07:56:02 instance-1 sm-mta[19958]: u7OCN1Wu013988: to=<example#email.com>, delay=19:33:01, xdelay=00:10:36, mailer=esmtp, pri=5340422, relay=alt4.gmail-smtp-in.l.google.com. [173.194.72.27], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Aug 25 07:56:02 instance-1 sm-mta[19958]: u7OC9iDu013870: to=<example#email.com>, delay=19:46:18, xdelay=00:00:00, mailer=esmtp, pri=10560423, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Aug 25 07:56:02 instance-1 sm-mta[19958]: u7OBliSC013710: to=<example#email.com>, delay=20:08:18, xdelay=00:00:00, mailer=esmtp, pri=10740386, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Aug 25 07:56:02 instance-1 sm-mta[19958]: u7O94ubM013110: to=<example#email.com>, delay=22:51:06, xdelay=00:00:00, mailer=esmtp, pri=11460376, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
You cannot send mail from Google Compute Engine, Google blocks all outgoing traffic on 25.
You will have to use a third party like Sendgrid to send mail.
Yes, it could be possible to send email from the instance, everything is explained in this tutorial.
By default, Compute Engine allows outbound connections on all ports except port 25, which is blocked because of the risk of abuse. All other ports are open, including ports 587, and 465.
It's not possible to send email directly from your GCE VM.
Please have a look at the documentation Always blocked traffic:
Egress traffic to TCP destination port 25 (SMTP)
also at the Using standard email ports:
Due to the risk of abuse, connections to destination TCP Port 25 are always blocked when the destination is external to your VPC network. This includes using SMTP relay with Google Workspace.
Accordingly to the Wikipedia article Simple Mail Transfer Protocol:
Since SMTP's introduction in 1981, it was updated, modified and
extended multiple times. The protocol version in common use today has
extensible structure with various extensions for authentication,
encryption, binary data transfer, internationalized email addresses.
SMTP servers commonly use the Transmission Control Protocol on port
number 25.
This was first decided back in 1982 with RFC 821, Appendix A and has been this way ever since. At the RFC5321 you can see:
4.5.4.2. Receiving Strategy
The SMTP server SHOULD attempt to keep a pending listen on the SMTP
port (specified by IANA as port 25) at all times.
What does that mean? You cannot simply change the port, because there is no mechanism for other SMTP servers to know you are using a non-standard port, and you cannot either send to other servers using any other port.
Is there a way to send emails from the GCE VM?
Yes, let's get back to the documentation Using standard email ports:
Google Cloud does not place any restrictions on traffic sent to external destination IP addresses using destination TCP ports 587 or 465.
The ports 587 and 465 are available for SMTP Message Submission (RFC6409). This means you can use an external mail relay (your own or 3rd party) for authenticated SMTP, and this server handles delivery to other mail systems on port 25. For example, you can use these 3rd party services: SendGrid, Mailgun, or Mailjet. Also, you can relay your mails via Google Workspace or just use Google Workspace.
Related
I have this v2.8-2 configuration file that I want to convert to the new YAML format. Documentation is hard to find.
User "root"
Group "root"
LogLevel 5
Alive 10
Control "/var/run/poundctl.socket"
# Redirect all http requests on port 80 to https on port 443
ListenHTTP
Address 0.0.0.0
Port 80
Err500 "/usr/local/etc/pound_error_500"
Err503 "/usr/local/etc/pound_error_500"
Service
Redirect 301 "https://localhost"
End
End
# Redirect all requests on port 443 to the webapp on port 9443
ListenHTTPS
Address 0.0.0.0
Port 443
Err500 "/usr/local/etc/pound_error_500"
Err503 "/usr/local/etc/pound_error_500"
Cert "/etc/pound/certbot/combined-for-pound.pem"
Disable SSLv3
Ciphers "EECDH+ECDSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!eNULL:!LOW:!aNULL:!MD5:!DSS"
SSLAllowClientRenegotiation 0
SSLHonorCipherOrder 1
HeadRemove "X-Forwarded-Proto"
HeadRemove "x-forwarded-proto"
AddHeader "x-forwarded-proto: https"
Service
BackEnd
Address 127.0.0.1
Port 9000
End
End
End
This is my attempt at translating the above to the new format:
Global:
- Err500: /usr/local/etc/pound_error_500
- Group: root
- User: root
Backends:
- &be
Address: 127.0.0.1
Port: 9000
HTTPListeners:
- Address: 0.0.0.0
Port: 80
Services:
- Backends:
- *be
HTTPSListeners:
- Address: 0.0.0.0
Certificates:
- /etc/pound/certbot/combined-for-pound.pem
Port: 443
Services:
- Backends:
- *be
This is the output from running Pound from the command line:
$ sudo pound -d 5
debug option 5 ./src/config.c:642
start get_others ./src/config.c:574
start get_backends ./src/config.c:123
addr 127.0.0.1 ./src/config.c:139
port 9000 ./src/config.c:142
push ./src/config.c:168
start get_https ./src/config.c:499
address 0.0.0.0 ./src/config.c:520
start get_certificates ./src/config.c:461
start get_one(/etc/pound/certbot/combined-for-pound.pem) ./src/config.c:376
get_one add pattern scalacourses\.com ./src/config.c:406
get_one add pattern home\.scalacourses\.com ./src/config.c:432
get_one add pattern scalacourses\.com ./src/config.c:432
get_one add pattern www\.scalacourses\.com ./src/config.c:432
get_one: added 4 patterns ./src/config.c:446
port 443 ./src/config.c:523
start get_services ./src/config.c:209
push ./src/config.c:258
push ./src/config.c:562
Prepare backends ./src/pound.c:153
Starting resurrector thread ./src/util.c:80
Prepare listeners ./src/pound.c:185
Prepare services for listener 0 ./src/pound.c:188
7F1B0827A640 start service ./src/http.c:45
7F1B0827A640 Null session: ./src/http.c:52
7F1B07A79640 thr_http start ./src/http.c:535
7F1B07A79640 start loop ./src/http.c:539
7F1B07278640 thr_http start ./src/http.c:535
7F1B07278640 start loop ./src/http.c:539
7F1B06A77640 thr_http start ./src/http.c:535
7F1B06A77640 start loop ./src/http.c:539
7F1B06276640 thr_http start ./src/http.c:535
7F1B06276640 start loop ./src/http.c:539
7F1B05A75640 thr_http start ./src/http.c:535
7F1B05A75640 start loop ./src/http.c:539
7F1B05274640 thr_http start ./src/http.c:535
7F1B05274640 start loop ./src/http.c:539
7F1B04A73640 thr_http start ./src/http.c:535
7F1B04A73640 start loop ./src/http.c:539
7F1B04272640 thr_http start ./src/http.c:535
7F1B04272640 start loop ./src/http.c:539
7F1B04272640 peer address 192.168.1.1 ./src/http.c:549
7F1B04272640 start sni ./src/util.c:157
7F1B04272640 sni for scalacourses.com ./src/util.c:165
7F1B04272640: found match at 0 ./src/util.c:169
Segmentation fault
The segmentation fault happens after I attempt to connect to the website from another machine by using https://scalacourses.com/
$ lynx https://scalacourses.com/
Looking up scalacourses.com
Making HTTPS connection to scalacourses.com
Alert!: Unable to make secure connection to remote host.
lynx: Can't access startfile https://scalacourses.com/
After the core dump, the socket remains in use for a few minutes before Pound can be restarted:
Listener 0.0.0.0:https: can't bind socket
When I try to access without SSL (http://scalacourses.com/ and http://www.scalacourses.com/) Pound does not appear to respond, and I get:
$ lynx http://scalacourses.com/
Looking up scalacourses.com
Making HTTP connection to scalacourses.com
Sending HTTP request.
HTTP request sent; waiting for response.
HTTP/1.1 302 Found
Data transfer complete
HTTP/1.1 302 Found
Using http://www.scalacourses.com/
Looking up www.scalacourses.com
Making HTTP connection to www.scalacourses.com
Alert!: Unable to connect to remote host.
lynx: Can't access startfile http://scalacourses.com/
Here is the help message for pound v3:
POUND(8) System Manager's Manual POUND(8)
NAME
pound - HTTP/HTTPS reverse-proxy and load-balancer
SYNOPSIS
pound [-v] [-c] [-d level] [-f config_file] [-p pid_file]
DESCRIPTION
Pound is a reverse-proxy load balancing server. It accepts requests
from HTTP/HTTPS clients and distributes them to one or more Web
servers. The HTTPS requests are decrypted and passed to the back-ends
as plain HTTP.
If more than one back-end server is defined, Pound chooses one of them
randomly. By default, Pound keeps track of associations between clients
and back-end servers (sessions).
GENERAL PRINCIPLES
In general Pound needs three types of objects defined in order to func‐
tion: listeners, services and back-ends.
Listeners
A listener is a definition of how Pound receives requests from
the clients (browsers). Two types of listeners may be defined:
regular HTTP listeners and HTTPS (HTTP over SSL/TLS) listeners.
At the very least a listener must define the address and port to
listen on, with additional requirements for HTTPS listeners.
Services
A service is the definition of how the requests are answered.
When a request is received Pound attempts to match them to each
service in turn. The services may define their own conditions as
to which requests they can answer: typically this involves cer‐
tain URLs (images only, or a certain path) or specific headers
(such as the Host header).
Back-ends
The back-ends are the actual servers for the content requested.
By itself, Pound supplies no responses - all contents must be
received from a "real" web server. The back-end defines how the
server should be contacted.
Multiple back-ends may be used within a service, in which case
Pound will load-balance between the available back-ends.
If a back-end fails to respond it will be considered "dead", in
which case Pound will stop sending requests to it. Dead back-
ends are periodically checked for availability, and once they
respond again they are "resurected" and requests are sent again
their way. If no back-ends are available (none were defined, or
all are "dead") then Pound will reply with "503 Service Unavail‐
able", without checking additional services.
The connection between Pound and the back-ends is always via
HTTP, regardless of the actual protocol used between Pound and
the client.
OPTIONS
Options available (see also below for configuration file options):
-v Print version: Pound will exit immediately after printing the
current version.
-c Check only: Pound will exit immediately after parsing the con‐
figuration file. This may be used for running a quick syntax
check before actually activating a server.
-d level
Debug mode: if level is greater than 0 error messages will be
sent to stdout and Pound will stay in the foreground. Level 0
(default) are the regular log messages, level 1 and up will pro‐
duce more detailed information.
-f config_file
Location of the configuration file (see below for a full de‐
scription of the format). Default: /etc/pound/pound.yaml
-p pid_file
Location of the pid file. Pound will write its own pid into
this file. Normally this is used for shell scripts that control
starting and stopping of the daemon. Default:
/var/run/pound.pid
One (or more) copies of Pound should be started at boot time. Use "big
iron" if you expect heavy loads: while Pound is as light-weight as we
know how to make it, with a lot of simultaneous requests it will use
quite a bit of CPU and memory. Multiple CPUs are your friend.
CONFIGURATION FILE
The configuration file is in standard YAML syntax. There are four
blocks of directives: Global directives (they affect the settings for
the entire program instance), Backends directives, defining the avail‐
able backends, HTTPlisteners directives (they define which requests
Pound will listen for), and HTTPSlisteners directives (same as HTTPlis‐
tener but via TLS).
Global Directives
User: user_name
Specify the user Pound will run as (must be defined in
/etc/passwd).
Group: group_name
Specify the group Pound will run as (must be defined in
/etc/group).
RootJail: directory_path_and_name
Specify the directory that Pound will chroot to at runtime.
Please note that SSL may require access to /dev/urandom, so make
sure you create a device by that name, accessible from the root
jail directory. Pound may also require access to /dev/syslog or
similar.
Err404: path_to_file
Specify a path to an HTML file to be returned in case of a 404
error.
Err405: path_to_file
Specify a path to an HTML file to be returned in case of a 405
error.
Err500: path_to_file
Specify a path to an HTML file to be returned in case of a 500
error.
Backends
A back-end is a definition of a single back-end server Pound will use
to reply to incoming requests. Each backend must be marked with an an‐
chor. The following directives are available:
Address: address
The address that Pound will connect to. This can be a numeric IP
address, or a symbolic host name that must be resolvable at run-
time. This is a mandatory parameter.
Port: port
The port number that Pound will connect to. This is a mandatory
parameter.
Timeout: number
How long to wait for a backend (server) to complete and opera‐
tion. Default: 15 seconds.
Threads: number
How many threads will be used to service requests to this back‐
end. See also below for remarks on performance tuning. Default:
8 threads.
HeadAdd: header
A header to add to each reply received from this backend. The
header is a string.
HTTPListeners
An HTTP listener defines an address and port that Pound will listen on
for HTTP requests. The following directives are available:
Address: address
The address that Pound will listen on. This can be a numeric IP
address, or a symbolic host name that must be resolvable at run-
time. This is a mandatory parameter. The address 0.0.0.0 may be
used as an alias for 'all available addresses on this machine',
but this practice is strongly discouraged.
Port: port
The port number that Pound will listen on. This is a mandatory
parameter.
Client: value
Define how long Pound will wait for client activity. Default: 5
seconds.
Threads: value
Define how many threads Pound will use to service client re‐
quests. Default: 8 threads.
Services:
This defines a service. This service will be used only by this
listener.
Services
The following directives are allowed in a service definition:
URL: pattern
The service will only be used if the request URL matches the
given pattern.
HeadRequire: pattern
Use the service only if any of the request headers matches the
given pattern.
HeadDeny: pattern
Use the service only if none of the request headers matches the
given pattern.
Session: number
How long to keep the client sessions (in seconds). Sessions are
a long term association between a client IP address and a spe‐
cific backend in this service. A value of 0 seconds means no
sessions are kept. Default: 0.
BackEnds:
A list of references to previously defined backends.
HTTPSListeners
All HTTPListeners directives are also available in the HTTPSListener
blocks.
The following additional directives are available:
Certificates:
A file name or a list of file names. Each file must contain a
certificate, optionally additional chained certificates up to a
known certificate authority, and the private key corresponding
to the certificate. Note: the private key should probably not
be password-protected, as Pound normally starts as a daemon and
cannot ask for the password at start-up time.
Ciphers:
A list of acceptable cipher names for this listener. The negoti‐
ation with the client will result in one of these ciphers being
used, or the hand-shake will fail.
ADDITIONAL REMARKS
High-availability
Pound attempts to keep track of active back-end servers, and will tem‐
porarily disable servers that do not respond (though not necessarily
dead: an overloaded server that Pound cannot establish a connection to
will be considered dead). However, every 60 seconds (compile-time op‐
tion), an attempt is made to connect to the dead servers in case they
have become active again. If this attempt succeeds, connections will be
initiated to them again.
The clients that happen upon a dead backend server will just receive a
503 Service Unavailable message.
Security
In general, Pound does not read or write to the hard-disk. The excep‐
tions are reading the configuration file and (possibly) the server cer‐
tificate file(s) and error message(s), which are opened read-only on
startup, read, and closed; secondly the pid file which is opened on
start-up, written to and immediately closed. Following this there is
no disk access whatsoever, so using a RootJail directive is only for
extra security bonus points.
Pound tries to sanitise all HTTP/HTTPS requests: the request itself,
the headers and the contents are checked for conformance to the RFC's
and only valid requests are passed to the back-end servers. This is not
absolutely fool-proof - as the recent Apache problem with chunked
transfers demonstrated. However, given the current standards, this is
the best that can be done - HTTP is an inherently weak protocol.
Additional Notes
Pound uses the system log for messages (default facility LOG_DAEMON -
compile-time option). The format is very similar to other web servers,
so if you want to use a log tool:
fgrep pound /var/log/messages | cut -d ':' -f 4- | your_log_tool
(assuming messages is you log file; it may be syslog or something else,
depending on your configuration).
Pound deals with (and sanitizes) HTTP/1.1 requests. Thus a single con‐
nection to an HTTP/1.1 client is kept, while the connection to the
back-end server is (re)opened as necessary.
Unless you start Pound as root it won't be able to listen on privileged
ports. That applies even if you do start it as root but set the User to
something else.
There is no point in setting User to root: either you start as root, so
you already are, or you are not allowed to setuid(0).
Performance Tuning Considerations
The two important factors in tuning the performance are the number of
threads for the backends end the number of threads for the listeners.
The number of backend threads defines how many requests may be issued
in parallel to a specific backend server, but also backend priorities.
Increasing it may overload the web server, but setting it too low will
cause longer wating ques for servicing requests. Please note that you
may define several backends for the same server in order to use them in
separate services.
The number of listener threads defines how many client requests can be
serviced in parallel. If this number is too low for your load clients
may be faced with long waiting times even when the backends are almost
idle.
EXAMPLES
The simplest configuration, with Pound used strictly to sanitise re‐
quests:
Backends:
- &be
Address: 10.1.1.100
Port: 80
HTTPListeners:
- Address: 123.1.2.3
Port: 80
Services:
- Backends:
- *be
HTTPSListeners:
The same thing, but with HTTPS:
Backends:
- &be
Address: 10.1.1.100
Port: 80
HTTPListeners:
HTTPSListeners:
- Address: 123.1.2.3
Port: 443
Services:
- Backends:
- *be
Certificates: "cert.pem"
Client: 60
Ciphers:
- TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
- TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
- TLS-DHE-RSA-WITH-AES-128-CBC-SHA
- TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
- TLS-RSA-WITH-AES-128-CCM
- TLS-RSA-WITH-AES-256-GCM-SHA384
- TLS-RSA-WITH-RC4-128-MD5
- TLS-RSA-WITH-3DES-EDE-CBC-SHA
To distribute the HTTP/HTTPS requests to three Web servers, where the
third one is a newer and faster machine:
Backends:
- &be0
Address: 10.1.1.100
Port: 80
Threads: 8
- &be1
Address: 10.1.1.101
Port: 80
Threads: 8
- &be2
Address: 10.1.1.102
Port: 80
Threads: 12
HTTPListeners:
HTTPSListeners:
- Address: 123.1.2.3
Port: 80
Threads: 32
Services:
- Backends:
- *be0
- *be1
- *be2
Certificates:
- "cert1.pem"
- "cert2.pem"
To separate between image requests and other Web content:
Backends:
- &text
Address: 10.1.1.100
Port: 80
Threads: 16
- &images
Address: 10.1.1.101
Port: 80
Threads: 16
HTTPListeners:
- Address: 123.1.2.3
Port: 80
Threads: 32
Services:
- URL: ".*.(gif|jpg|png)"
Backends:
- *images
- Session: 300
Backends:
- *text
HTTPSListeners:
FILES
/var/run/pound.pid
this is where Pound will attempt to record its process id.
/etc/pound/pound.yaml
the default configuration file (compile-time option).
AUTHOR
Written by Robert Segall, Apsis GmbH.
REPORTING BUGS
Report bugs to <roseg#apsis.ch>.
COPYRIGHT
Copyright © 2002-2020 Apsis GmbH.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
pound Jan 2010 POUND(8)
Possible issue -- YAML is extremely white-space-sensitive.
The documentation says this:
Backends:
- &be
Address: 10.1.1.100
Port: 80
but you have this:
Backends:
- &be
Address: 127.0.0.1
Port: 9000
This may not be the answer you're looking for, but my suggestion is to stay on pound v2 and put it to rest when the time comes.
Version 3 was a complete rewrite of the codebase. It features some critical bugs (e.g. pound3 calls setuid before bind, which breaks setups that utilize unprivileged users. Reported it back in May with no response.) and new config format which isn't feature complete => there is no way to port some configs, as the functionality simply isn't there.
Did a bit of digging on a fresh install and ended up with the same conclusion as you in another comment. I was very fond of the project because of how simple it was and had lots of fun with it over the years, but I think the project is dead and it's time to move on unless someone is willing to maintain a fork.
Pound is effectively a dead project. Anything that Pound can do as a reverse proxy, Apache http and nginx can do, and do better.
I chose nginx. You can read about the gory details here: https://www.mslinn.com/blog/2022/07/08/reverse-proxy.html
Trying to configure a syslog-ng server to send all of the logs that it receives, to another syslog-ng server over TLS. Both running RHEL 7. Everything seems to be working from an encryption and cert perspective. Not seeing any error messages in the logs, an openssl s_client test connection works successfully, I can see the packets coming in over the port that I'm using for TLS, but nothing is being written to disk on the second syslog-ng server. Here's the summary of the config on the syslog server that I'm trying to send the logs to:
source:
source s_encrypted_syslog {
syslog(ip(0.0.0.0) port(1470) transport("tls")
tls(key-file("/etc/syslog-ng/key.d/privkey.pem")
certfile("/etc/syslog-ng/cert.d/servercert.pem")
peer-verify(optional-untrusted)
}
#changing to trusted once issue is fixed
destination:
destination d_syslog_facility_f {
file("/mnt/syslog/$LOGHOST/log/$R_YEAR-$R_MONTH-$R_DAY/$HOST_FROM/$HOST/$FACILITY.log" dir-owner ("syslogng") dir-group("syslogng") owner("syslogng") group("syslogng"));
log setting:
log { source (s_encrypted_syslog); destination (d_syslog_facility_f); };
syslog-ng is currently running as root to rule out permission issues. selinux is currently set to permissive. Tried increasing the verbosity on syslog-ng logs and turned on debugging, but not seeing anything jumping out at me as far as errors or issues go. Also the odd thing is, I have very similar config on the first syslog-ng server and it's receiving and storing logs just fine.
Also, I should note that there could be some small typo's in the config above as I'm not able to copy and paste it. Syslog-ng allows me to start up the service with no errors with the config that I have loaded currently. It's simply not writing the data that it's receiving to the destination that I have specified.
It happens quite often that the packet filter prevents a connection to the syslog port, or in your case port 1470. In that case the server starts up successfully, you might even be able to connect using openssl s_client on the same host, but the client will not be able to establish a connection to the server.
Please check that you can actually connect to the server from the client computer (e.g. via openssl s_client, or at least with something like netcat or telnet).
If the connection works, another issue might be that the client is not routing messages to this encrypted destination. syslog-ng only performs the SSL handshake as messages are being sent. No messages would result in the connection being open but not really exchanging packets on the TCP level.
Couple of troubleshooting tips:
You can check if there is a connection between the client and the server with "netstat -antp | grep syslog-ng" on the server or the client. You should see connections in the ESTABLISHED state on both sides of the connection (with local/remote addresses switched of course).
Check that your packet filter lets port 1470 connections through. You are most likely using iptables, try reviewing your ruleset and see if port 1470 on TCP is allowed to pass in the INPUT chain. You could try adding a "LOG" rule right before the default rule to see if the packets are dropped at that level. If you already have LOG rules, you might check the kernel logs of the server to see if that LOG rule produced any messages.
You can also confirm if there's traffic with tcpdump on the server (e.g. tcpdump -pen port 1470). If you write the traffic dump to a file (e.g. the -w argument to tcpdump, along with -s 0 to avoid truncation), then this dump file can be analyzed with wireshark to see if the negotiation takes place. You should at the very least see a "Client Hello" and a "Server Hello" packet which are not encrypted at the beginning of the handshake.
I have a server running Rundeck to handle a large amount of various integration tasks.
The scheduled tasks each make a curl request to a given URL on our intranet system - essentially Rundeck just runs a temporary bash script.
About 99% of the time, this works fine - but we're seeing curl fail intermittently with Error 35: Unknown SSL protocol error in connection.
I've tried specifying the ssl protocol explicitly, with a known-good protocol, but we're still experiencing the issue.
We have a pretty high volume of requests going out - I'm not sure if that could have something to do with it. There is a chance we could have ~3 curl processes running at any given time.
Any advice would be appreciated.
curl --version
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
I've figured this out myself.
I ended up using wireshark to watch the communication on the server side of the SSL connection. The only anomaly I could see in the trace of the failures was that our Diffie-Hellman Public Key was 127 bytes, when typically it would be 128.
It looks like IIS didn't know how to handle this, and terminated the communication.
I'm not 100% clear on what the root cause of the issue was, but forcing a non-DH TLS cipher suite completely stopped the error messages.
Check This Article On Security.StackExchange For More Information
I have installed aspera connect plug-in for download large data on fedora 14 linux platform.
I have configured proxy setting of our organization. Whenever i try to download some file, it throws an error :
Error -failed to open ssh session. (Code 16)
For Successfull transfer you need to open the following ports on you firewall:
TCP port 22 (ssh) : allows the connection with Aspera server.
UDP port 33001 : allows file transfer.
UDP ports from 33001 to 33010 for example if you want to send 10 files simultaneously.
(http://support.sportstec.com/hc/en-us/articles/202344978-Firewall-configuration-for-ASPERA)
FOr more information about how to open the ports,please refer to this link:
https://help.ubuntu.com/lts/serverguide/firewall.html
I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services