I have a magento web (192.168.148.151) and remote mysql (192.168.140.147) box that im trying to create a rule so that the frontend will talk to the mySQL db
Im using IPTables (ubutun 16.04) Linode
When I disable IPTables I can telnet to the mysql box fine.
Magento runs fine also.
I would like to enable some rules in IP Tables on the Web Server so only the bare min ports like 80,443,22 are open
On the Web Server, with ip tables disabled I can telnet to the mySQL box
For example:
telnet 192.168.140.147 3306
When I however turn on IPTables my rule doesnt work
Here is my rule
-A INPUT -p tcp --dport 3306 -s 192.168.148.151 -d 192.168.140.147 -j ACCEPT
How can I communicate from IP:192.168.148.151 to mySQL on IP: 192.168.148.151 using an rule in IPTables?
Regards
Brendan
Related
My problem is similar to this question but since I don't have enough reputation to write a comment AND the answer to that question dindn’t help, I am starting a new question.
I have an GCE VM instance with LEMP with MySQL Ver 15.1 Distrib 10.1.18-MariaDB and I'm trying to connect remotely to it from my local machine.
I already tried all the suggestions in the question link that I mentioned before.
This is my firewall configuration:
In my.cnf file I have:
bind-address = 0.0.0.0
And about MySQL users privileges I have the following:
When I try to connect remotely with wkreport user I get the following result:
My question is, what am I missing ?!
I just found the solution to my problem,
Special thanks to #Slava for pointing me the way, after all it was iptables.
So, I kept receiving a "MySQL connection refused" message when trying to connect remotely so I searched for a way to see TCP connection logs and I found the tcpdump command.
By running sudo tcpdump port 3306 -vvv -n I saw the following output every time I tried to connect remotely:
I searched the tcpdump man page and saw that R means for TCP RST (RESET) flag.
Searched a little bit and found this question and its accepted answer led me again into IPTABLES that #Slava suggested since the first comment.
That's when I looked closely and saw that my INPUT ACCEPT tcp:3306 was defined after the REJECT TCP reject-with tcp-reset rule hence the log was showing.
After this I just removed the rule to accept tcp:3306 and prepended it to the reject tcp rules and voila!
iptables -D INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
iptables -I INPUT {line number from the first reject tcp rule} -p tcp -m tcp --dport 3306 -j ACCEPT
IPTABLES now looks like this and finally I can connect to MySQL remotely:
To list the iptables with line numbers type:
sudo iptables -nL --line-numbers
Final toughts:
This can be improved by whitelisting the source IP address from where you're making the remote connection for security matters.
I had similar problem with a vm instance.
I tested everything and it was solved by creating a new user on mysql.
I used this post to solve it.
I have an Apache server on a computer (win server 2012) with IP "myApacheIP" and a MySQL server on an other computer (win server 2012) with IP "mySQLIP".
In the computer with Apache I installed PhpMyAdmin but I can't access to MySQL server.
Is not a firewall problem because it is turned off in both computers.
Is there anything that I have to configure?
You'd need to update your my.cnf to explicitly allow remote connections.
You would do this by changing #bind-address = 127.0.0.1 to #bind-address = 0.0.0.0 and then restarting your MySQL server.
You would then need to open your 3306 port on your firewall for your specific IP using something like:
iptables -A INPUT -i eth0 -s YOUR_IP_ADDRESS -p tcp --destination-port 3306 -j ACCEPT
I am trying to connect a remote mysql database in my local application. But it was not connecting with the given user name and password. Though I gave the GRANT ALL to that user. After a long study I came to know about firewall. I assume the following rules of firewall is the culprit for not connecting:
REJECT tcp -- anywhere anywhere tcp dpt:mysql reject-with icmp-port-unreachable
Please let me know if I am right. And please suggest me a solution to overcome this.
You can poke a hole in your firewall, to your given IP address by running the following (as root)
iptables -I INPUT -p tcp --dport 3306 --src 103.19.252/24 -j ACCEPT
-I INPUT signifies we are looking at incoming traffic
--dport 3306 means any traffic headed for port 3306 (mysql)
--src 103.19.252/24 will open up the connection to any traffic that originates from the 103.19.252.xx subnet
-j ACCEPT means let it through
You'll also need to make sure your MySQL user is allowed to connect from that ip
We are facing a strange problem from last few days between our application server and database server(Mysql): connection to database server from application server hangs in SYN_SENT state and after that we are not able to make any connection to database server on mysql port(3306). When we checked the netstat output on database server its in SYN_RECV state.
What I can figure out is mysql server is receiving the SYN request and responding also and its not reaching to the client hence SYN_RECV at server side and SYN_SENT at client side. I think SYN_SENT state should go after some time and because of this other db connection attempts to same server should not hang.
Does anybody have any idea how can we resolve this issue?
Out setup details : Application server: RHEL 5.4, kernel-release = 2.6.18-164.el5, x86_64 Database server: Mysql Version : 5.1.49 RHEL 5.4, kernel-release = 2.6.18-164.el5, x86_64
Fix for server with only localhost access:
set 127.0.0.1 in the bind address in my.cnf
Fix for connection to remote ip's
(REMOTE_IP replace with remote ip)
iptables -A INPUT -p tcp -d 127.0.0.1 --dport 3306 -s REMOTE_IP -j ACCEPT
iptables -A INPUT -p udp -d 127.0.0.1 --dport 3306 -s REMOTE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP
iptables -A INPUT -p udp --dport 3306 -j DROP
Also you need to set bind ip in my.cnf to 0.0.0.0. Second rule you don't need, I just made it to be sure ;) (udp part)
Proof of concept:
first allow the connection from remoteip to the destination (-d 127.0.0.1 = localhost)
-p tcp / udp = protocoll tcp or udp
after this rules you need to make a rule to drop all requests to tcp / udp connections to port 3306.
Why is this working:
Because iptables is going is "numeric". Always 1 rule after another.
you can see your rules with the command:
iptables -L INPUT -n --line-numbers
the first rule which is displayed is the first rule so if you say accept all connections and afterward drop from ip x.x.x.x all connections then it doesn't work.
you need to pick as first rule to drop all connections from this ip and afterwards allow all connections. (it's a bad example..)
if you failed an entry you can display your rules and take the number in front of the rule and drop the rule with the command:
iptables -D INPUT <<number here>>
I want to add to MySql another tcp port that I can connect to that port from my application
I have a duplicate of my application and I'm running them both from the same machine. They both are connected to the MySql server that are running on the same machine. The problem is that the default port 3306 is already taken.
You cannot bind mysqld to listen to multiple ports. The only way you can achieve this is with internal routing rules which would forward the target port to 3306.
If you are on linux, you can achieve this using iptables. iptables is a bundle of fun normally reserved for system administrators though.
Is there a reason why both copies of your application can't connect to the same port 3306? Normally you should be able to have any number of clients connecting.
You can do that with something like this:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 9005 -j REDIRECT --to-port 9000
Where eth0 is your network dev, 9005 is your "source port", and 9000 the port where your service is running. Oh, that example is for TCP protocol only.
You can find more examples about port redirection
here. Useful site for Linux, btw.
A single mysql instance can host multiple databases. So an alternative for you is that each application connects to the same mysql instance running at port 3306, but each uses a different database name.