I am using oracle cloud to create a http server for learning , so I am new on this. Thank you for your any help!
Instance information
Image: Canonical-Ubuntu-20.04-2022.02.15-0
Shape: VM.Standard.E2.1.Micro
Have added ingress rule on subnet(7500 port):
Picture of subnet
Source IP Protocol Source Port Range Destination Port Range Allows
0.0.0.0/0 TCP All 7500 TCP traffic for ports: 7500
Using python to create a http server:
python3 -m http.server 7500 &
It was showing：
ubuntu#tcp-server:~$ Serving HTTP on 0.0.0.0 port 7500 (http://0.0.0.0:7500/) ...
Calling lsof -i returns
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3 1806 root 3u IPv4 33281 0t0 TCP *:7500 (LISTEN)
Allowed 7500 port on ufw:
ufw Status: active
To Action From
7500 ALLOW Anywhere
7500 (v6) ALLOW Anywhere (v6)
But I can not visit public_Ip_address:7500.
Using telnet:
sudo telnet 152.69.123.118 7500
Returns:
Trying 152.69.123.118...
and does not connect
Thank you in advance!
The reason is from iptables setting:
sudo nano /etc/iptables/rules.v4
add this sentence:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 7500 -j ACCEPT
then:
sudo su
iptables-restore < /etc/iptables/rules.v4
Done!
ubuntu image from oci has been modified by oracle, the default setting has limitted ports accepted.
Therefor we have to open the port manually.
There are some important attributes you need to be aware of when using a fresh ubuntu image on oci. For the sake of this discussion firewall and iptables are synonymous
By default
there are 4 chains standard INPUT, FORWARD, OUTPUT and InstanceServices
OUTPUT will have 1 rule
InstanceServices all -- * * 0.0.0.0/0 169.254.0.0/16
InstanceServices destination 169.254.XXX.YYY point to oci services like bootvolume ect ...
FORWARD rejects all
Your default INPUT chain will look like
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
this allows ssh and udp port 123 for NTP only
create a rule for port 7500 and place it with the existing tcp rule for ssh
sudo iptables -I INPUT 6 -p tcp -m tcp --dport 7500 -j ACCEPT
now INPUT chain is
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7500
7 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
as long as we have the correct VCN route table entries, Security list entries or network security group entries for tcp 7500 you can get thru the instance firewall to destination port 7500
Notes
Its really import not to delete the InstanceServices rule in the OUTPUT chain AND not to delete the InstanceServices chain
This can happen if you are new to iptables and you do something like
iptables -F
iptables -X
Its worth it to learn iptables however firewalld is easier.
Oci does not recommend ufw
Your iptable rules will not survive a reboot unless you persist them
these issues are well documented here under subheading Essential Firewall Rules
Related
I'm struggling to configure my nf tables rules on my distro. I'm using nft 1.0.4 and Linux 4.9.
When I am using the ct state instruction, nft throw the following error:
nftables.cfg:25:17-43: Error: Could not process rule: Protocol wrong type for socket
ct state established accept
^^^^^^^^^^^^^^^^^^^^^^^^^^^
My Kernel config contains the following parameters
# enable nftables support
CONFIG_NF_TABLES=y
CONFIG_NF_TABLES_INET=y # inet allows IPv4 and IPv6 config in single rule
CONFIG_NF_TABLES_NETDEV=y
CONFIG_NF_CONNTRACK=y # for NAT support
CONFIG_NF_NAT=y # for NAT support
CONFIG_NF_TABLES_SET=y # to use brackets (sets)
CONFIG_NFT_EXTHDR=y
CONFIG_NFT_META=y
CONFIG_NFT_CT=y
CONFIG_NFT_RBTREE=y
CONFIG_NFT_HASH=y
CONFIG_NFT_COUNTER=y
CONFIG_NFT_LOG=y
CONFIG_NFT_LIMIT=y
CONFIG_NFT_MASQ=y
CONFIG_NFT_REDIR=y
CONFIG_NFT_NAT=y
CONFIG_NFT_QUEUE=y
CONFIG_NFT_REJECT=y
CONFIG_NFT_REJECT_INET=y
CONFIG_NFT_COMPAT=y
CONFIG_NFT_CHAIN_ROUTE_IPV4=y
CONFIG_NFT_REJECT_IPV4=y
CONFIG_NFT_CHAIN_NAT_IPV4=y
CONFIG_NFT_MASQ_IPV4=y
# CONFIG_NFT_REDIR_IPV4 is not set
CONFIG_NFT_CHAIN_ROUTE_IPV6=y
CONFIG_NFT_REJECT_IPV6=y
CONFIG_NFT_CHAIN_NAT_IPV6=y
CONFIG_NFT_MASQ_IPV6=y
# CONFIG_NFT_REDIR_IPV6 is not set
CONFIG_NFT_BRIDGE_META=y
CONFIG_NFT_BRIDGE_REJECT=y
my ruleset is something like
#!/sbin/nft -f
flush ruleset
table inet myfilter {
chain myinput {
type filter hook input priority 0; policy drop;
ct state established,related accept
tcp dport ssh accept
tcp dport 53 accept
udp dport 53 accept
ip protocol icmp accept
iif "lo" accept
tcp dport 2181 accept
tcp dport 9092 accept
}
chain myoutput {
type filter hook output priority 0; policy drop;
ct state established accept
tcp dport ssh accept
tcp dport 53 accept
udp dport 53 accept
udp dport snmp accept
tcp dport http accept
tcp dport https accept
ip protocol icmp accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
}
Do you have any idea how to fix this?
Actually the error come from the version of the kernel I am using: 4.9.
nftables needs at least v4.10 to fully support ct states as stated in debian documentation here https://packages.debian.org/stretch/nftables
A Linux kernel >= 3.13 is required. However, >= 4.10 is recommended.
I have an OpenVPN server I've set up on an AWS EC2 instance that is pulling an IPV6 address, and can traceroute6 and ping6 ipv6.google.com. The client can do neither and does not return an address when using online tests like ipleak, or testipv6. The server and client can ping6 and traceroute6 each other.
The client appears to pull the correct address locally, and via ip -6 route. IPV4 has always worked fine without issue. Everything appears good on the AWS side per their instructions here so the instance does have ipv6 enabled with the proper routing on the aws/vpc side. Security groups are pretty wide open for ipv6 as well.
I am assuming it's my routing, but I'm not really sure at this point as I'm no ipv6 or routing expert. Please help!
Relevant config info:
ipv6 addr of AWS instance:
aaaa:bbbb:cccc:dddd::/64
server.conf
local 172.31.44.1
port 443
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
server-ipv6 aaaa:bbbb:cccc:dddd:80::/112
push "redirect-gateway-ipv6 def1 bypass-dhcp-ipv6"
push "route-ipv6 aaaa:bbbb:cccc:dddd::/64"
push "route-ipv6 2000::/3"
push "route 172.31.44.1 255.255.255.255 net_gateway"
push "dhcp-option DNS6 2001:4860:4860::8888"
push "dhcp-option DNS6 2001:4860:4860::8844"
/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
ip6tables:
-A INPUT -p udp --dport 443 -j ACCEPT
-A FORWARD -m state --state NEW -i tun0 -o eth0 -s aaaa:bbbb:cccc:dddd::/64 -j ACCEPT
-A FORWARD -m state --state NEW -i eth0 -o tun0 -d aaaa:bbbb:cccc:dddd::/64 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Don't use proxy NDP. It's a mess.
What you need is to delegate (=route) a prefix to the EC2 instance, then configure this prefix in the OpenVPN config (server-ipv6 keyword with the assigned prefix and mask, e.g. 2001:db8:dead:beef:1::/80), then assign connected users addresses from the prefix.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-prefixes.html
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
I am using lsof to check connections to a remote Tibco server(7000). I am using this command..
line
lsof -p 4567 | grep TCP | grep 7000
java 4446 app 319u IPv6 9150778 0t0 TCP localhost:49756->test-tibco-test.com:ramp (ESTABLISHED)
java 4446 app 325u IPv6 9150793 0t0 TCP localhost:49756->test-tibco-test.com:54561->dfw-tibco-vems1.prod.walmart.com:7000 (ESTABLISHED)
What does the "ramp" mean in the first output?
lsof translates "well-known" port numbers to human readable string (e.g., 25 -> smtp, 80 -> http etc.). Per http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml, "ramp" should mean port 7227 (the "Registry A & M Protocol").
Note that this only means that port 7227 is being used, not that you actually have the "Registry A & M Protocol" (whatever that is) running on that port. Most likely, somebody configured a TIBCO EMS server to use port 7227 (its default port is 7222 and many people start counting upwards from there if they need multiple servers with different ports running on the same machine).
You can add the option -P (capital letter P) to your lsof command to avoid this translation of port numbers into human readable names.
In amazon ec2, I have 2 instances in a placement group. First node is 172.31.12.76/20, second, 172.31.12.77/20 I can ssh both nodes from my pc. They share the same security group that has got these 2 rules:
Inbound rules:
Type Protocol Port Range Source
SSH TCP 22 0.0.0.0/0
All IMCP All N/A 0.0.0.0/0
(no outbound rules)
Both nodes see to each other in L2:
root#ip-172-31-12-76:~# arp
[...]
ip-172-31-12-77.eu-west ether 0a:ad:5e:e4:12:de C eth0
[...]
root#ip-172-31-12-77:~# arp
[...]
ip-172-31-12-76.eu-west ether 0a:34:a1:17:57:28 C eth0
[...]
iptables are empty on both nodes.
But ping does not work between each other
I have already checked a previous post:
EC2 instances not responding to internal ping
but it does not address the issue. It looks like there are no other similar posts.
Any idea? Thank you very much!
I got the answer; I need to also allow outbound icmp on each host in order to be able to ping both external and internal IPs.
I am confuse why my IPTable does not work in Router. what I'm trying to do is redirect any packets from source ip destined to port 80 and 443 to 192.168.1.110:3128. however when I tried this:
iptables -t nat -A PREROUTING -s 192.168.1.5 -p tcp --dport 80:443 -j DNAT --to-destination 192.168.1.110:3128
does not work. however when I add this,
iptables -t nat -A POSTROUTING-j MASQUARADE
it works. but the problem with masquarade is I do not get the real ip but instead the ip of the router. I need to get the source ip so my proxy server could record all ip connected to it. can some one tell me how to make it work without making POSTROUTING jump to Masquarade?
For real transparent proxying you need to use the TPROXY target (in the mangle table, PREROUTING chain). All other iptables-mechanisms like any NAT, MASQUERADE, REDIRECT rewrite the IP addresses of the packet, which makes it impossible to find out where the packet originally was intended to.
The proxy program has to bind() and listen() on a socket like any other server, but needs some specific socket flags (which requires some Linux capabilities (type of permission) or root). – Once connected, there is some way to get the “intended server” from the OS.
Sorry, I’m a little lazy about the details, but searching for “TPROXY” as keyword will get you going quickly!
If I am not wrong, the correct syntax of the rule would be:
iptables -t nat -A PREROUTING -s 192.168.1.5 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.110:3128
--dport 80:443 will forward all ports from 80 to 443
--dports 80,443 will forward port 80 and 443 only.
If you want traffic hitting 192.168.1.5 on port 80 and 443 to be forwarded to 192.168.1.110's 3128 port then you should use the below rule:
iptables -t nat -A PREROUTING -d 192.168.1.5 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.110:3128
You should also make sure the gateway on 192.168.1.110 is pointed to your router ip.
Finally you can use the masquerade rule as below.
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE
eth1 should be your outgoing interface.
I had the same issue and the solution was to tell the transparent proxy to forward the source ip in the right header fields.
In case of my nginx proxy the rules were close to:
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://name_of_proxy;
proxy_redirect off;
}
i used the iptables -t nat -A PREROUTING -p tcp -s foreign ip to your device --dport 80:443 -j DNAT --to-destination your application or local ip:port.i think you did the prerouting the packet in your device out which never connect to port 80 or 443,these is for web server connect to device.192.168.1.5 is like my local address.
and remember to configecho 1 > /proc/sys/net/ipv4/ip_forward
I think you are doing NAT in both directions by not specifying an interface. Try adding -o eth0 to your -j MASQUERADE line. (Substitute whatever your "external" interface is, instead of eth0, depending on your setup.)