Now I use OpenWRT 17.04 firmware for my router, but I need to configure access to my router and open 80 port for specific machines when I add a rule like
WAN='eth0.2
iptables -A input_rule -i $WAN -p tcp --dport 80 -m mac --mac-source XX:XX:XX:XX:XX:XX -j ACCEPT`
where XX:XX:XX:XX:XX:XX - the specific machine which tries to get access, but no results. What happens? Why doesn't it work?
Thanks for advice
There no ways to specify MAC address of a machine. You should use IP address instead of.
Related
The above one seems like an easy question, but believe me I have tried multiple methods but all seems to be in vain
For example : Port is 8080
1st - I followed many oracle docs and tried opening port 8080, but failed miserably
2nd - I followed another stack overflow posts - Opening port 80 on Oracle Cloud Infrastructure Compute node
Opening port 19132 on an Oracle compute instance (ubuntu-20.04)
still no success
3rd - I followed these oracle instructions and tried to open up the port - https://docs.cloud.oracle.com/en-us/iaas/developer-tutorials/tutorials/apache-on-ubuntu/01oci-ubuntu-apache-summary.htm
but not working -> to my surprise, when I tried port no 80 with the same method,it worked well..but not working for any other port at all
In short : ** I enabled port 8080 in Security rules in VNC - didnt work
** I tried ,installing firewalld and allowing through that -> didnt work for me
** Tried this -> didnt work
iptables -I INPUT 5 -i ens3 -p tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT
So I was hoping someone else can find me a solution Please to open up a port, or is there any way to completely disable my firewall so that I can use any port at all - currently I am able to listen to only port 80 from outside
Thank you
Ubuntu images in Oracle Cloud seem to have this 'strange' (compared to other clouds) behavior by default where you need to explicitly enable incoming traffic in the VM:
sudo iptables -I INPUT -j ACCEPT
Then you need to make this permanent:
sudo iptables-save -f /etc/iptables/rules.v4
To open a certain port it may require creating a security application specific to the port before creating the security rule. Please refer to this walkthru on it if you haven't already - https://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/compute/permitting_public_tcp_traffic_to_compute_instances/permitting_public_tcp_traffic_to_compute_instances.html
I am using Oracle Linux and this worked for me.
First add a new rule inside the default security list(see the link below)
firewall-cmd --permanent --zone=public --add-port=8080/tcp
firewall-cmd --reload
Reference : OCI: Amend Firewall Rules
In your case, you have Ubuntu instead of Oracle Linux, so you could try the above two commands as per Ubuntu and check if it works.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
This is an elementary question however one I cannot seem to resolve by perusing the Oracle Cloud Infrastructure documentation. I've created an Ubuntu-based compute node, and it's attached to a subnet. In that subnet I've created a stateful rule with source 0.0.0.0/0, IP protocol: TCP, Source Port Range: All, Destination Port Range: 80.
There is no firewall configured on the server.
Despite this configuration I can't access the compute node's public IP. Any ideas?
I figured it out. The connectivity issue was due to Oracle's default use of iptables on all Oracle-provided images. Literally the very first thing I did when spinning up this instance was check ufw, presuming there were a few firewall restrictions in place. The ufw status was inactive, so I concluded the firewall was locally wide open. Because to my understanding both ufw and iptables look at the netfilter kernel firewall, and because ufw is the de facto (standard?) firewall solution on Ubuntu, I've no idea why they concluded it made sense to use iptables in this fashion. Maybe just to standardize across all images?
I learned about the rules by running:
$ sudo iptables -L
Then I saved the rules to a file so I could add the relevant ones back later:
$ sudo iptables-save > ~/iptables-rules
Then I ran these rules to effectively disable iptables by allowing all traffic through:
$ iptables -P INPUT ACCEPT
$ iptables -P OUTPUT ACCEPT
$ iptables -P FORWARD ACCEPT
$ iptables -F
To clear all iptables rules at once, run this command:
$ iptables --flush
Anyway, hope this helps somebody else out because documentation on the matter is non-existent.
When deploying compute instances at Oracle Cloud Infrastructure you need to take into account few things:
Create Internet Gateway (IGW).
Define routes to point to IGW.
Allow port 80 in the Security List associated with the IGW. By default you only have access to SSH and ICMP 3,4 type.
Allow connectivity on Compute's instance firewall (which is enabled by default).
In your example if you are using a OEL shape:
$ sudo firewall-cmd --zone=public --permanent --add-port=80/tcp
$ sudo firewall-cmd --reload
Always refer to the official guide: https://docs.cloud.oracle.com/en-us/iaas/developer-tutorials/tutorials/apache-on-ubuntu/01oci-ubuntu-apache-summary.htm
$ sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
$ sudo netfilter-persistent save
$ sudo systemctl restart apache2
credited to https://medium.com/#fathi.ria/oracle-database-cloud-open-ports-on-oci-1af24f4eb9f2
Coumputer Instance(Such as Ubuntu) -> Virtual Cloud Network -> Security List -> Ingress Rules -> Please add a rule to allow access to port 80 from anywhere
Pre-Requisite
VM instance should have been created and running
Access to Public and Private keys used during the creation of VM instance
Log into the VM using SSH and run the following command
$ sudo iptables --list --line-numbers
It will show the details about Chain INPUT (policy ACCEPT). From the list
required to Delete REJECT all rule in the IPTABLES.
$ sudo iptables -D INPUT <Reject Line number>
e.g.
$ sudo iptables -D INPUT 6
Check if the REJECT rule is deleted
sudo iptables --list --line-numbers
Access the Default Security List and Edit Ingress Rules to Allow Internet Traffic on Port
Edit the INGRES Rule Add CIDR 0.0.0.0/0 TCP Destination 9999
(N): Networking >Virtual Cloud Networks> Virtual Cloud Network Details>Security Lists> Security List Details
Access your application via web browser
Type http://<public IP address of the VM>:port
I guess if you add the rule below to your iptables it should work; otherwise you'll be disturbing other rules which are related to block volume attachment that comes preconfigured on those Oracle images.
iptables -I INPUT 5 -i ens3 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
If you have not created Internet Gateway yet, that might be the reason. In order to connect the VCN with the public internet you need to have an Internet Gateway and a route table to direct the traffic through the gateway.
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'm in a network and i wanna capture ftp packets from another server in the network but i have a problem with tcpdump about this.
I've used this command :
tcpdump -i eth0 dst X.X.X.X -A and port 21
But it doesn't shows anything! ( i tested and sure that ftp port is 21 )
But if i use this on my server it works properly.
tcpdump -i eth0 -A and port 21
I've this problem when i enter " port " in the command. but if i enter a command without specific port it works and captures properly.
What is the problem?
Thanks.
I don't have enough reputation to ask a question, so this is part question and part insight.
Is the IP you're filtering on the client or the server for the FTP connection?
For the first command, try using src x.x.x.x or just host x.x.x.x and port 21.
For the second command, the "and" is not necessary with the -A flag. This should look more like this:
tcpdump -A -i eth0 port 21
tcpdump -Ai eth0 port 21
Another thing I've seen is if there are vlan tags, normal filtering won't work without adding "vlan and " to your filter. For example:
tcpdump -A -i eth0 "vlan and host x.x.x.x and port 21"
Also keep in mind that FTP uses a control and data connection. The control is over port 21, but the data can vary depending on whether you're using active or passive FTP.
I have a Fedora 21 server running on a local private LAN. I have setup a minecraft server. It is running on port 25565 and running the server produces no errors. My problem is that I cannot get the client to connect to it. The client connects fine to minecraft servers outside of the local private LAN and when I tested minecraft server on an Ubuntu desktop, the windows machine was able to connect to that server. So, it seems isolated to the Fedora 21 machine. It is running as a server, so no GUI! I have performed a netstat -a on it and see that it states that it is listening to port 25565. I have turned off firewalld ('sudo systemctl stop firewalld' and then 'sudo systemctl disable firewalld' just to be sure) to see if that was blocking it. I was still not able to connect. I can provide other information as needed. Oh, I am also using Java 1.8u25 and minecraft_server.1.8.1.
Thanks for your help.
I have found the problem. Apparently the change requires a server reboot. Perhaps just restarting the service may also take care of the issue but definitely rebooting the server cleared the problem.
EDIT: I have found that using iptables will open the firewall to allow the game to connect. I only stated that turning off firewalld allows the game to operate after saving iptables and restarting firewalld.
This should work (let me know if it doesn't):
Be sure to place this before any REJECT statements in the iptables.
You can use iptables -L --line-numbers | less to display the table. I pipe it out to "less" because the table can be quite long and this way one can easily scroll through the information.
iptables -I INPUT ## -p tcp --dport 25565 -j ACCEPT
iptables -I INPUT ## -p udp --dport 25565 -j ACCEPT
iptables-save
To do a restart of the firewalld type sudo systemctl restart firewalld.
Also keep in mind that this is for the default port in server.properties file. Obviously if the default port is changed in this file, then so would the iptables setting.
Hopefully this will help anyone who may run into this same problem.