I am running postfix on a Google Compute instance. It is listening on 0.0.0.0:25, and I have opened port 25 on the firewall, but I cannot connect to it from the outside. I have reviewed this and this, but they do not resolve my issue. I don't see anything in the Google Compute documentation that would explain this.
The port is open on the firewall:
% gcutil --project=XXX getfirewall smtp
+---------------+-------------------------------+
| name | smtp |
| description | Incoming smtp allowed. |
| creation-time | 2014-06-08T13:29:16.052-07:00 |
| network | default |
| source-ips | 0.0.0.0/0 |
| source-tags | |
| target-tags | |
| allowed | tcp: 25 |
+---------------+-------------------------------+
From the outside, I can connect to port 80 (which is also open)...
% telnet 108.XXX.XXX.XXX 80
Trying 108.XXX.XXX.XXX...
Connected to 108.XXX.XXX.XXX.
Escape character is '^]'.
GET /
<!DOCTYPE html>
<html ...>
...
</html>Connection closed by foreign host.
...but not to port 25:
% telnet 108.XXX.XXX.XXX 25
Trying 108.XXX.XXX.XXX...
telnet: connect to address 108.XXX.XXX.XXX: Operation timed out
telnet: Unable to connect to remote host
postfix is listening on all interfaces:
% gcutil --project=XXX ssh --zone=us-central1-a XXX sudo netstat -lpn -A inet
...
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 10794/master
...
I can look up the "external" address...
% gcutil --project=XXX ssh --zone=us-central1-a XXX /sbin/ifconfig eth0
...
eth0 Link encap:Ethernet HWaddr 42:01:0a:XX:XX:XX
inet addr:10.XXX.XXX.XXX Bcast:10.XXX.XXX.XXX Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:46397953 errors:0 dropped:0 overruns:0 frame:2
TX packets:34953374 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5031906871 (4.6 GiB) TX bytes:49375287245 (45.9 GiB)
...and telnet to port 25 on it from the box:
% gcutil --project=XXX ssh --zone=us-central1-a XXX telnet 10.XXX.XXX.XXX 25
...
Trying 10.XXX.XXX.XXX...
Connected to 10.XXX.XXX.XXX.
Escape character is '^]'.
220 XXX ESMTP Postfix (Debian/GNU)
EHLO localhost
250-XXX
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Any assistance is greatly appreciated.
As #GregHewgill and #complistic pointed out in their respective comments, it is my ISP (or an intermediary) who was not routing traffic for port 25. I have been unable to connect to any port 25 outside of my immediate LAN. It is somewhat embarrassing that I have never noticed this before.
Hopefully anyone with a similar issue can find this question (and answer) before spinning their wheels in ignorance like I did.
Thanks all for your help!
Take a look at this link Blocked traffic where it says that Google blocks or restricts traffic through all of the following ports/protocols between the Internet and virtual machines on specified ports.
Hope this helps.
Mary
Related
I compiled qemu-system-x86_64 on aarch64 host, and was able to run a x86_64 guest with a command like
qemu-system-x86_64 -m 4096 -drive file=vmimage.qcow2,if=virtio \
-boot once=c,menu=on -net nic,model=virtio-net-pci \
-net user,hostfwd=tcp::8080-:80,hostfwd=tcp::22222-:22
I could ssh into the guest using
ssh -p22222 user#localhost
Meanwhile, port 80 was not forwarded successfully.
For debugging, I used nc to listen to port 80 inside the guest
nc -l 80
Then in the host, I connected to the forwarded port
nc localhost 8080
However, it was unable to connect to guest nc .
I tried the monitor interface. When the host nc command is executed, info usernet shows following:
(qemu) info usernet
Hub 0 (#net162):
Protocol[State] FD Source Address Port Dest. Address Port RecvQ SendQ
TCP[SYN_SENT] 33 127.0.0.1 8080 10.0.2.15 80 0 0
TCP[ESTABLISHED] 21 127.0.0.1 22222 10.0.2.15 22 0 0
TCP[HOST_FORWARD] 12 * 8080 10.0.2.15 80 0 0
TCP[HOST_FORWARD] 11 * 22222 10.0.2.15 22 0 0
...
I believe the SYN_SENT (FD 33) corresponded to the host nc command, and this matched the HOST_FORWARD line (FD 12). However, it never became ESTABLISHED. And a few seconds later, nc died with Connection reset by peer. , and the FD 33 line disappeared.
If I nc localhost 22222, I can see the OpenSSH banner.
So it seems only port 22 forwarded. Any idea about the cause or how to debug?
Both host and guest had no firewalliptables configured, and SELinux is permissive.
Thanks
Edit:
As a temporary workaround, I configured a second nic, and used port 22 of the new interface for forwarding my service. I also switch to the newer -nic option, but hostfwd still worked for port 22 only.
qemu-system-x86_64 -m 4096 -drive file=vmimage.qcow2,if=virtio \
-boot once=c,menu=on \
-nic user,model=virtio-net-pci,hostfwd=tcp::60022-:22 \
-nic user,model=virtio-net-pci,net=10.0.3.0/24,hostfwd=tcp::8080-10.0.3.15:22
To forward successfully, I also need to
Configure sshd to listen to port 22 the first nic only.
Configure my service to listen to port 22 of the second nic.
Configure the second nic to use a different network. Otherwise, both nics were assigned the same IP (10.0.2.15. I may better hardcode the IP for both nics.)
The problem was actually about firewall. My VM (based on Oracle Linux 8.5 on Oracle Linux VM Templates) actually had firewall rules in both iptables and nft. After disabling both iptables and nft, the port forward worked.
In summary, although I've set a firewall rule that allows tcp:80, my GCE instance, which is on the "default" network, is not accepting connections to port 80. It appears only port 22 is open on my instance. I can ping it, but can't traceroute to it in under 64 hops.
What follows is my investigation that led me to those conclusions.
gcloud beta compute firewall-rules list
NAME NETWORK DIRECTION PRIORITY ALLOW DENY
default-allow-http default INGRESS 1000 tcp:80
default-allow-https default INGRESS 1000 tcp:443
default-allow-icmp default INGRESS 65534 icmp
default-allow-internal default INGRESS 65534 tcp:0-65535,udp:0-65535,icmp
default-allow-rdp default INGRESS 65534 tcp:3389
default-allow-ssh default INGRESS 65534 tcp:22
temp default INGRESS 1000 tcp:8888
gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
ssrf3 us-west1-c f1-micro true 10.138.0.4 35.197.33.182 RUNNING
gcloud compute instances describe ssrf3
...
name: ssrf3
networkInterfaces:
- accessConfigs:
- kind: compute#accessConfig
name: external-nat
natIP: 35.197.33.182
type: ONE_TO_ONE_NAT
kind: compute#networkInterface
name: nic0
network: https://www.googleapis.com/compute/v1/projects/hack-170416/global/networks/default
networkIP: 10.138.0.4
subnetwork: https://www.googleapis.com/compute/v1/projects/hack-170416/regions/us-west1/subnetworks/default
...
tags:
fingerprint: 6smc4R4d39I=
items:
- http-server
- https-server
I ssh into 35.197.33.182 (which is the ssrf3 instance) and run:
sudo nc -l -vv -p 80
On my local machine, I run:
nc 35.197.33.182 80 -vv
hey
but nothing happens.
So I try to ping the host. That looks healthy:
ping 35.197.33.182
PING 35.197.33.182 (35.197.33.182): 56 data bytes
64 bytes from 35.197.33.182: icmp_seq=0 ttl=57 time=69.172 ms
64 bytes from 35.197.33.182: icmp_seq=1 ttl=57 time=21.509 ms
Traceroute quits after 64 hops, without reaching the 35.197.33.182 destination.
So I check which ports are open with nmap:
nmap 35.197.33.182
Starting Nmap 7.12 ( https://nmap.org ) at 2017-06-18 16:39 PDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.06 seconds
nmap 35.197.33.182 -Pn
Starting Nmap 7.12 ( https://nmap.org ) at 2017-06-18 16:39 PDT
Nmap scan report for 182.33.197.35.bc.googleusercontent.com (35.197.33.182)
Host is up (0.022s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 6.84 seconds
… even when I’m running nc -l -p 80 on 35.197.33.182.
Ensure that VM level firewall is not intervening. For example, Container-Optimized OS is a bit special in comparison to all other default images:
By default, the Container-Optimized OS host firewall allows only outgoing connections, and accepts incoming connections only through the SSH service. To accept incoming connections on a Container-Optimized OS instance, you must open the ports your services are listening on.
https://cloud.google.com/container-optimized-os/docs/how-to/firewall
Checking the two check boxes "Allow HTTP traffic" and "Allow HTTPS traffic" did the trick. This created two Firewall rules, that opened the ports 80 and 443.
Manually adding rules for those port didn't work for some reason, but it worked with checking the boxes.
On a quick glance, your setup seems to be correct.
You have allowed INGRESS tcp:80 for all instances in the default network.
Your VM is on the default network.
Traceroute will not give a good indication when you have VMs running on Cloud providers, because of the use of SDNs, virtual networks and whole bunch of intermediate networking infrastructure unfortunately.
One thing I notice is that your instance has 2 tags http-server and https-server. These could be used by some other firewall rules possibly which is somehow blocking traffic to your VM's tcp:80 port.
There are other variables in your setup and I'm happy to debug if needed further.
Tag based firewall rules
You can try tag based firewall rules which will apply the firewall rule only to instances which have the specified target tag.
Network tags are used by networks to identify which instances are
subject to certain firewall rules and network routes. For example, if
you have several VM instances that are serving a large website, tag
these instances with a shared word or term and then use that tag to
apply a firewall rule that allows HTTP access to those instances. Tags
are also reflected in the metadata server, so you can use them for
applications running on your instances. When you create a firewall
rule, you can provide either sourceRanges or sourceTags but not both.
# Add a new tag based firewall rule to allow ingress tcp:80
gcloud compute firewall-rules create rule-allow-tcp-80 --source-ranges 0.0.0.0/0 --target-tags allow-tcp-80 --allow tcp:80
# Add the allow-tcp-80 target tag to the VM ssrf3
gcloud compute instances add-tags ssrf3 --tags allow-tcp-80
It might take a few seconds to couple of minutes for the changes to take effect.
NOTE: Since you're opening up ports of VM's external IPs to the internet, take care to restrict access accordingly as per the needs of your application running on these ports.
After lots of trail and error, the following worked for me on ubuntu-1404-trusty-v20190514
, with a nodejs app listening on port 8080. Accept port 80 and 8080, and then redirect 80 to 8080.
sudo iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
sudo iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Incase you are a windows server instance , You could try to turn off the Windows Defender and check if it's blocking the incoming connection.
I installed sendmail on both server1 and server2. They use the same configuration file: sendmail.mc. I can send/receive mails to/from the users on the same server using an email client from my PC. But I can not send email to the users on the other server. For example, I can not send an email to bbb#server2domain.com from aaa#server1domain.com using the email client. I've added the ip address of my PC to /etc/mail/access on server1(Connect:zz.zz.zz.zz RELAY) and rebuilt access.db. Looking into /var/log/maillog, sendmail on server1 successfully accepted the mail from the PC but waited for a long time when connecting to server2
Apr 3 07:21:06 server1 sendmail[19771]: v33BKxfr019769: SMTP outgoing connect on server1.xxxxx.com
then timeout:
Apr 3 07:26:06 server1 sendmail[19771]: v33BKxfr019769: timeout waiting for input from server2domain.com. during client greeting
Apr 3 07:26:06 server1 sendmail[19771]: v33BKxfr019769: to=, ctladdr= (501/501), delay=00:05:04, xdelay=00:05:00, mailer=esmtp, pri=121178, relay=server2domain.com. [yy.yy.yy.yy], dsn=4.0.0, stat=Deferred: Connection timed out with server2domain.com.
On server2, the log is:
Apr 3 07:18:02 server2 sendmail[20121]: v33BI2Os020121: assigned id
Apr 3 07:18:02 server2 sendmail[20121]: NOQUEUE: connect from [xx.xx.xx.xx]
Apr 3 07:18:02 server2 sendmail[20121]: AUTH: available mech=ANONYMOUS,
allowed mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
Apr 3 07:18:02 server2 sendmail[20121]: v33BI2Os020121: Milter: no active filter
Apr 3 07:23:02 server2 sendmail[20121]: STARTTLS=server, info: fds=6/4, err=5
Apr 3 07:23:02 server2 sendmail[20121]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1, relay=[xx.xx.xx.xx]
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: disconnect level 1
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: in background, pid=20121
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: [xx.xx.xx.xx] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL
I can successfully send email to server2 on server1 using the openssl command and do not need to input user name/password.
The sendmail.mc is:
divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux')dnl
OSTYPE(`linux')dnl
define(`confDEF_USER_ID', ``8:12'')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl
define(`confCRL', `/etc/pki/tls/certs/revoke.crl')
define(`confCLIENT_CERT', `/etc/pki/tls/certs/sendmail.pem')
define(`confCLIENT_KEY', `/etc/pki/tls/certs/sendmail.pem')
define(`confTO_IDENT', `0')dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
DAEMON_OPTIONS(`Family=inet, Port=465, Name=MTA-SSL, M=s')dnl
CLIENT_OPTIONS(`Family=inet')dnl
FEATURE(`accept_unresolvable_domains')dnl
LOCAL_DOMAIN(`localhost.localdomain')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 465')
define(`ESMTP_MAILER_ARGS', `TCP $h 465')
MAILER(smtp)dnl
MAILER(procmail)dnl
Both sendmail listen on port 465. I doubt the problem is related to auth but do not know the reason.
Please help, thank you!
After adopting Andrzej A. Filip's suggestion and removing the two lines in sendmail.mc, the following error occurs in the log on server1:
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: makeconnection (server2domain.com. [yy.yy.yy.yy]) failed: Connection refused by server2domain.com.
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: makeconnection (server2domain.com. [yy.yy.yy.yy]) failed: Connection refused by server2domain.com.
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: to=, ctladdr= (501/501), delay=05:41:23, xdelay=00:00:01, mailer=esmtp, pri=301178, relay=server2domain.com. [yy.yy.yy.yy], dsn=4.0.0, stat=Deferred: Connection refused by server2domain.com.
There is no message logged on server2.
I think without the two lines, sendmail on server1 will try to connect the server2 via port 25, not the port 465 that sendmail is listening.
sendmail and OUTGOING smtps (465) connections
smtps (465) starts SSL session before any SMTP level communications. AFAIR sendmail does not support it natively for outgoing connections.
Remove the following two lines, recompile your sendmail.mc into sendmail.cf, restart or (send signal) HUP your sendmail daemon.
define(`RELAY_MAILER_ARGS', `TCP $h 465')
define(`ESMTP_MAILER_ARGS', `TCP $h 465')
I've installed Orion Context Broker 0.23.0 and it behaves rare: it only works half of the times. For instance, when trying to retrieve the version I get this error message:
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 18 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 53 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
This behaviour is deterministic, I mean, after failing it always works, and after working it always fails. This occurs with all the operations within the REST API.
I've checked the listening ports and the process running them matches the Orion's one:
$ sudo netstat -ntlp | grep 1026
tcp 0 0 0.0.0.0:1026 0.0.0.0:* LISTEN 9944/contextBroker
tcp 0 0 :::1026 :::* LISTEN 9944/contextBroker
$ ps ax | grep contextBroker | grep -v grep
9944 ? Ssl 0:13 /usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion -multiservice
Any hints? Thanks!
Orion runs by default listening to IPv4 and IPv6. We have found that in cases similar to the ones you described disabling IPv6 solves the problem (we don't know yet the exact cause, maybe is related with the operating system or it is involved is some way...).
Tu run Orion in only-IPv4 mode you have to use the -ipv4 option either in the contextBroker command line or (if you are running Orion as a service) editing the /etc/sysconfig/contextBroker file to add -ipv4 to the BROKER_EXTRA_OPS variable (have a look to the documentation for more information about configuring Orion as a service). After modifying /etc/sysconfig/contextBroker you have to restart Orion using:
sudo /etc/init.d/contextBroker restart
I am trying to run MySQL through XAMPP on Mac Version 10.9.3.
When I try to run it i get
But after about 30 seconds it reverts to this
Here is the XAMPP application log:
I've looked into whether or not port 3306 is being used but it seems like its not being used:
Last login: Wed May 28 19:10:04 on ttys000
John-MacBook-Air:~ John$ lsof -i -P | grep -i "listen"
SpotifyWe 230 John 6u IPv4 0x1a81be5beea7cc07 0t0 TCP localhost:4370 (LISTEN)
SpotifyWe 230 John 7u IPv4 0x1a81be5beea7c41f 0t0 TCP localhost:4380 (LISTEN)
Dropbox 233 John 28u IPv4 0x1a81be5be15b041f 0t0 TCP *:17500 (LISTEN)
Dropbox 233 John 38u IPv4 0x1a81be5be1606c07 0t0 TCP localhost:26164 (LISTEN)
Can somebody spot the problem?
EDIT: I've run this several times over the past week and it has worked.
EDIT: Starting apache first doesn't fix the problem.
EDIT: log url https://www.dropbox.com/s/gz9zqt55mbd219m/log
This has happened to me several times over the course of a few months.
I've found that you need to do the following:
Quit XAMPP
Open activity monitor ( basically task manager for mac )
Navigate to CPU tab
Find process "mysqld" and kill it ( click on it and click x in top left hand corner )
This has been working for me so far. Will update if any further solutions become available.