Apparently, my EC2 instance can’t access the internet properly. Here is what happens when I try to install a Python module:
[ec2-user#ip-172-31-90-31 ~]$ pip3 install flask
Defaulting to user installation because normal site-packages is not writeable
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7fab198cbe10>: Failed to establish a new connection: [Errno 101] Network is unreachable')': /simple/flask/
etc.
However, the website that is hosted on the same EC2 instance can be accessed using both http and https.
The security group is configured as follows:
Port range
Protocol
Source
80
TCP
0.0.0.0/0
22
TCP
0.0.0.0/0
80
TCP
::/0
22
TCP
::/0
443
TCP
0.0.0.0/0
443
TCP
::/0
The ACL inbound rules are:
Type
Protocol
Port range
Source
Allow/Deny
HTTP (80)
TCP (6)
80
0.0.0.0/0
Allow
SSH (22)
TCP (6)
22
0.0.0.0/0
Allow
HTTPS (443)
TCP (6)
443
0.0.0.0/0
Allow
All ICMP - IPv4
ICMP (1)
All
0.0.0.0/0
Allow
All trafic
All
All
0.0.0.0/0
Deny
and the outbound rules are:
Type
Protocol
Port range
Source
Allow/Deny
Custom TCP
TCP (6)
1024 - 65535
0.0.0.0/0
Allow
HTTP (80)
TCP (6)
80
0.0.0.0/0
Allow
SSH (22)
TCP (6)
22
0.0.0.0/0
Allow
HTTPS (443)
TCP (6)
443
0.0.0.0/0
Allow
All ICMP - IPv4
ICMP (1)
All
0.0.0.0/0
Allow
All trafic
All
All
0.0.0.0/0
Deny
This is what the route table associated with the subnet looks like:
Destination
Target
Status
Propagated
172.31.0.0/16
local
Active
No
0.0.0.0/0
igw-09b554e4da387238c
Active
No
(no explicit or edge associations).
As for the firewall, executing sudo iptables –L results in
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
and sudo iptables -L -t nat gives
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
What am I missing here? Any suggestions or ideas on this would be greatly appreciated.
Thanks
You did not list your settings for the Outbound rules of the security group(s) attached to the instance. You should keep the "Allow All" outbound rules to allow the instance to access the Internet.
In general, you should not modify the ACL rules away from their default "Allow All" setting unless you have a very specific need (eg creating a DMZ). I recommend that you start by removing all custom rules from the ACLs and set the 'All traffic' option to "Allow". At least try this temporarily to try and identify the problem.
For example, when establishing a connection to the Internet, traffic will come from a randomly-assigned port. Your ACL is currently blocking all such ports. (To clarify: You might be connecting to port 80 on a remote computer, but that request is not coming from port 80 on your own computer. It is coming from a randomly-assigned port.)
Related
I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.
Chats are working, but voice calls are not, failing at "Connecting".
Is there something special I need to configure in order to proxy Telegram voice traffic?
I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.
Thanks!
UPD: Thats piece of log while i am trying to call somebody:
Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.36562
Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.49065
I can answer the call at destination device but connection is looping and getting error after 30 seconds.
Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.
Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:
Client instantiates a TCP socks5 connection.
Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
Server will keep the UDP port bound until the TCP socks5 connection terminates.
As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.
UDP relaying configuration with Dante
Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
# udp.portrange: 40000-45000
command: udpassociate
log: error connect disconnect
}
udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}
If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.
If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.
Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.
A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):
# 203.0.113.12 – the external IP
# 1080/tcp - Dante TCP port
# 40000:45000 – Dante UDP portrange
iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
# If external address is not added to any network device on that
# machine, then add it to the loopback interface, so the kernel
# would know where to route the DNATed packets:
ip addr add 203.0.113.12/32 dev lo
I had the same problem. Found the solution.
You have to add udpassociate bindreply udpreply commands to conf file. here is my conf file that works with voice calls.
logoutput: syslog /var/log/danted.log
internal: ip port = 1080
external: ip
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
log: error connect
}
Allow clients' voice traffic
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: connect disconnect error
socksmethod: username
}
iptables -A INPUT -p udp -m multiport --dports 1024:65535 -j ACCEPT
You should enable calls via proxy in your telegram settings.
I've configured my server to run with the following flags:
Server--> Server Types --> WebSphere application servers --> Additional Properties --> Debugging Service:
JVM Debug Arguments= -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8888
JVM Port= 8888
I configured eclipse debug configuration with the server ip (verified that ip is reachable with the ping command) and port
To be sure i increased the debugger timeout as well .
I've got: Failed to connect to remote VM. Connection refused.
Connection refused: connect
so i did a port scan on the server with (nmap xxx.xxx.xxx.xxx -p 8888) and the port seems:
PORT STATE SERVICE
8888/tcp closed sun-answerbook
moreover looking at the section Server--> Server Types --> WebSphere application servers --> Communications-->Ports of WebSphere admin consolle
i don't see the port 8888 in the list.
what do i need to do?
open the port on the machine? (how?)
add the port in the list of the above mentioned section?
other?
###### EDITED ########
ADDITIONAL CHECKS
netstat -na | grep 8888 --->no listening port/doesn't show me nothing
----------------------------------------------------------------------------
[root#dmgr ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
----------------------------------------------------------------------------
C:\Users\alex>nmap 192.168.115.235 -p 8888
Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-23 10:58 ora solare Europa occidentale
Nmap scan report for xxxx.xxxxxxxxxxxx.com (192.168.115.235)
Host is up (0.0018s latency).
PORT STATE SERVICE
7777/tcp closed cbt
Nmap done: 1 IP address (1 host up) scanned in 4.59 seconds
so, no listening port on 8888, no iptables rules that deny the connection, how to investigate further?
You are almost there :-)
On the Debugging Service page where you set the port and arguments, there is a checkbox - Enable service at server startup - ensure that it is checked.
If not, check, and restart the server.
After that you should see the debugging port open. You can check it for example via netstat -an.
If the port is open and you still cannot connect then it is probably the firewall issue.
Here some more details about setting the debug - Starting the application server in debug mode
I want configure the system as following:
There are several web app servers, each of which have global IP addresses.
The web app servers make HTTP and HTTPS requests to several (unidentified) external services. The source IP address of packets (thus destination port 80/tcp or 443/tcp) need to be fixed to a global IP address, so actually I need transparent proxy for HTTP/HTTPS, not affecting other traffic.
Other packets should not use the global IP address above, but should use global IP addresses that the server is each assigned.
The web application is very old and it's impossible to modify it to use proxy (CONNECT) protocol.
So I tried to use iptables to DNAT from 80/tcp and 443/tcp to the squid proxy on all web servers, and configured squid as an interception proxy.
However I failed it by redirection loop error.
I investigated what squid is doing by strace and found that it tries to connect to 10.0.0.252:80 after receiving a request, and therefore forwarding loop is detected.
I believe it is because of misconfiguration but I have no idea which should be fixed, or maybe totally I misunderstand what I should do.
(I googled but couldn't find the examples that NAT on each server.)
Hope could someone help solve the problem, or suggest another better way (not limited to using squid proxy)
All servers are on Amazon EC2, so it is a choice to use a vyos for a router...
ip a result on squid proxy
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0a:1c:ba:c3:9c:1d brd ff:ff:ff:ff:ff:ff
inet 10.0.0.211/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::81c:baff:fec3:9c1d/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0a:a9:2c:5e:eb:d7 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.252/24 brd 10.0.0.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::8a9:2cff:fe5e:ebd7/64 scope link
valid_lft forever preferred_lft forever
iptables on squid proxy
iptables -t nat -A PREROUTING -s 10.0.0.252 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.252:3129
iptables on web servers
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 10.0.0.252:80
cache.log
2016/06/22 06:15:22 kid1| WARNING: Forwarding loop detected for:
GET / HTTP/1.1
User-Agent: squidclient/3.5.19
Accept: */*
Via: 1.0 unknown (squid/3.5.19)
X-Forwarded-For: 10.0.0.211
Cache-Control: max-age=259200
Connection: keep-alive
Host: ifconfig.moe
Full squid.conf
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl Safe_ports port 1025-65535 # unregistered ports
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
#http_access deny to_localhost
http_access allow localnet
http_access allow localhost
cache_dir ufs /var/spool/squid 100 16 256
coredump_dir /var/spool/squid
visible_hostname unknown
# Squid normally listens to port 3128
http_port 3128
http_port 3129 intercept
http_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myCA.pem
always_direct allow all
ssl_bump none localhost
ssl_bump server-first all
# temporary: just test
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
http_access deny all
If you DNAT to the proxy, you're changing the destination to the IP of the proxy. In this case, the proxy will lose the information about the original destination.
For http this is ok, since the host header can be used to resolve the target, but for https the proxy would need to rely on SNI in the TLS ClientHello packet to learn the target and connect to it, bootstrap the TLS layer and go from there.
I had a running EC2 server with an elastic IP address that was happily running memcached and beanstalkd listening on the external IP at port 11211 and 11300 respectively. I took a AMI of the server to upgrade the size and when the server restarted, neither memcached nor beanstalkd were running. Troubling for memcached as this was init.d to restart but beanstalkd was run as daemon from command line.
However, after several hours, I can't seem to figure out how to get them up and running again.
For memcached the config file reads:
# Default connection port is 11211
-p 11211
# Specify which IP address to listen on. The default is to listen on all IP addresses
-l <EXTERNAL IP ADDRESS>
When I try and run memcached as root from the command line:
memcached -d -m 1024 -u root -l <EXTERNAL IP ADDRESS> -v -p 11211
I get:
bind(): Cannot assign requested address
failed to listen on TCP port 11211: Cannot assign requested address
Yet when I look at netstat, nothing is bound to that port already:
netstat -ant | grep LIST
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
And if I grep the processlist, there is no other memcached running.
Iptables reports the following:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp spt:11300 state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:11211 state ESTABLISHED
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
The EC2 instance is using the same security group as the original server, so the required ports are open.
Finally, maybe a hint is that the ifconfig IP address is different to the elastic IP address. If I try listening on either the inet adds: Bcast: the memcached service runs and binds however I can't seem to access memcached via the elastic IP.
I MUST be doing something stupid and obvious to you. Thanks for your help.
bind to 0.0.0.0 that should be public.
Settings of my security group on EC2
TCP
Port(Service) Source Action
22 (SSH) 0.0.0.0/0 Delete
80 (HTTP) 0.0.0.0/0 Delete
443 (HTTPS) 0.0.0.0/0 Delete
Output: When I run the telnet
JP$ telnet passionate4.net
Trying 50.18.159.124...
telnet: connect to address 50.18.159.124: Operation timed out
telnet: Unable to connect to remote host
on ubuntu ec2 server
ubuntu#ip-10-166-185-18:~$ sudo netstat -nup -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:68 0.0.0.0:* 400/dhclient3
Telnet uses port 23, you don't have it in your security group.
type this:
JP$ telnet passionat4.net 80
80, 443, 3389, or whatever port you're testing for.
Windows example:
C:/> telnet www.google.com 80