I'm creating resources using terraform and I have a node in the subnet 172.1.0.0 with no security group or rules assigned to the node; the node has two endpoints 22 and 80.
I used nmap to confirm that the ports are open and they are:
nmap -Pn -sT -p T:11 some-ingress.cloudapp.net
Starting Nmap 6.47 ( http://nmap.org ) at 2016-07-08 19:02 EAT
Nmap scan report for some-ingress.cloudapp.net (1.2.3.4
Host is up (0.31s latency).
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 1.34 seconds
nmap -Pn -sT -p T:80 some-ingress.cloudapp.net
Starting Nmap 6.47 ( http://nmap.org ) at 2016-07-08 19:02 EAT
Nmap scan report for some-ingress.cloudapp.net (1.2.3.4)
Host is up (0.036s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
I've installed nginx on the node and running curl 172.1.0.4 and curl 127.0.0.1 and curl 0.0.0.0 gets me the default nginx page.
However running curl <public ip> or curl <dns name> hangs and I get a
curl: (56) Recv failure: Connection reset by peer
My iptables rules are:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Why can't I possibly access nginx at the node's public ip?
The node is in a virtual network 172.1.0.0/16 and a subnet of 172.1.0.0/24 I can post the terraform configs if needed.
Related
The gist of the issue is that if I create and run a docker container (from any image, I tried many) the container does not have network access beyond the default bridge Docker creates; even when using IP addresses (not URLs/names).
I.e.
docker run --rm -it busybox ping 8.8.8.8 hangs/fails for not having accessing the network
docker run --rm -it busybox ping 172.17.0.1 also fails (note that 172.17.0.1 is docker0's IP on the host and also the gateway set by docker in the container)
if I create two containers I can ping either one from the other fine
N.B:
I have two Ubuntu hosts (same version) both running Docker 19.03.6. On one of them (dev machine) I don't have the issue (it works just fine), on the other one I do. Which means it is most likely not an OS and/or Docker version issue but some sort of misconfiguration.
It is not the DNS issue asked in most questions I could find. In fact, it is not a DNS issue at all. It presents itself when I use direct IP addresses as well as with URLs.
I use iptables on the host; these are the rules on the one where it does not work (they are different on the dev machine where networking works fine but I cannot set the here the same):
Chain INPUT (policy DROP)
target prot opt source destination
f2b-postfix-sasl tcp -- anywhere anywhere multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp spt:ntp state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:imap2 state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:imaps state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:submission state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp state NEW,ESTABLISHED
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:ntp state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:imap2 state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:imaps state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:smtp state ESTABLISHED
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-postfix-sasl (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-sshd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-ssh (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
I am not sure what else to add for clarification.
What should I do?
I'm running Debian 8 with iptables.
I have the following rule:
iptables -t mangle -A PREROUTING -p tcp --dport 5000 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 4000
I simply want to redirect all traffic going with destination port 5000 to port 4000.
The standard iptables REDIRECT is not usable in my case, as it alters the packet and changes the original destination port.
Looking at iptables -t mangle -nvL I can see the rule being hit:
Chain PREROUTING (policy ACCEPT 5056 packets, 13M bytes)
pkts bytes target prot opt in out source destination
12 720 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000 TPROXY redirect 0.0.0.0:4000 mark
0x1/0x1
But my service running on port 4000 doesn't intercept the packets.
I have a simple NodeJS application listening for all TCP on port 4000, which doesn't get any packets:
server.listen(4000, () => { console.log('listening on 4000'); });
Also, running wireshark on TCP port 4000 on all interfaces doesn't show anything.
You also need to set up the routing rule:
# 1 is --tproxy-mark parameter in iptables command
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
This question has been asked several times but none of the answers works for me. This is very simple, I want to block some IP access to a server
I tried this:
.htaccess
Order Deny,Allow
Deny from 151.101.52.84
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 151.101.52.0/24 anywhere
REJECT tcp -- 151.101.52.84 anywhere tcp reject-with icmp-port-unreachable
DROP all -- 151.101.52.84 anywhere
DROP all -- 151.101.52.84 anywhere
DROP tcp -- 151.101.52.84 anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:http limit: avg 100/min burst 200
/etc/hosts.deny
ALL : 151.101.52.84
netstat -te | grep 151.101
tcp 0 1 ip-*-*-*-*.us-we:51181 151.101.52.84:http SYN_SENT apache 800352623
Already restarted httpd
Even I blocked the IP via Amazon EC2 VPC
Need to restart entire server? Need something else with iptables?
Have you tried Fail2Ban?
sudo apt-get install fail2ban
I have a Node.js express website that was listening on port 9000, the thing which was fine until I changed the port to 80, now it accepts only connection from local:
wget http://127.0.0.1/ -O -
curl 127.0.0.1:80
Locally it's working fine and they return the html page. But it does not accept remote connections from browser, either using the external IP address or the domain name.
# iptables
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
Well, i have figured the issue, it was my iptables rules forwarding remote connections from outside to another port.
I am new to ssh and Centos 6.4 and I want to run nodejs on port 80. But couldn't make it to work external.
When I type netstat -anp | grep 8080 I can see that my node listening.
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7976/node
But it is not going external.
I tried to add settings to iptables and result is same again. It is not working.
[root#culturalinfluences ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http /* node.js port */
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:webcache /* node.js port */
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Here is my nodejs
var port = 8080;
app.listen(port, "0.0.0.0" ,function() {
console.log("Listening on " + port);
});
Thank you four understand cause I am really new into linux and its iptables system. I am sure people like me will search the same issue and I hope they will find answer from this question.
Thank you for your helps.
You have a
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
right before the "http" ports you're allowing, so those rules will never be reached. Move the REJECT all rule to the bottom of the list instead.
Additionally you may want to use -n on the iptables command line to make sure the port numbers are right and aren't 80 instead of 8080 for example.