All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Need help - applied Hetzner firewall - now I can't browse Internet
One issue maybe solved, but it created a new issue. Short: I have applied Hetzner firewall on one of my servers. It's a IPv4 firewall for incoming traffic.
I have just opened port 3389 for RDC and 21/990 for FTP. RDC and FTP both from my server and to my server is working great.
But, I can't get access to internet from my server. Can't browse webpages, can't ping webpages. I do of course have internet connection, since both my RDC and FTP is working. I also can use FTP from my server.
The strange thing is that Google is working. I can search in Google, and get results. But if I click on any of the links, the pages will not work.
I tried to make a incoming firewall rule that opened port 80 and 443. That did not help.
If I create a incoming rule that allow all ports and all protocols. internet work right away.
So what ports and protocols do I need to open to get Internet to work again? Still blocking all other ports?
Comments
Maybe you want to post those rules here for us to look at it?
Not using any form of web proxy / VPN / Browser with inbuilt Proxy/Cache
Could be a DNS issue: google's domain IP is cached but not others.
Do you allow DNS outbound?
Your rules would help, for sure...
Explanation: Rule 1 - 6 is to my main server.
Rule 2 is just an test - look away from it. It will be the rule that open http surfing.
Rule 3 and 6 is for FileZilla server. just one IP has access to FileZilla from the outside.
Rule 5 is my owncloud server, also hosted on Hetzner, and to get Owncloud to work on my main server (the client software) I have to give that server IP access to my main server.
Rule 7 - 10 is to my other VM's - since the firewall works on all my IP's, I have opened all protocols and port to thees IP's.
No, but I actually tried to use VPN on my server, open the VPN port that I use, but the VPN do not get access to web, so it will not logon to the VPN server.
I then tried OpenVPN to my own VPN server, that worked, but as soon as I connect, I'm disconnected from RDC, and can't get access to the server again. So I have to get LARA console to logon to my server.
you probably need some related/established rule to be able to receive incoming answers on your outgoing requests. do you have general rules like accepting all outgoing traffic and dropping all incoming? haven't dealt with hetzners firewall so far, but maybe it helps to define outgoing rules to 80 and 443 for the firewall to adapt to it?
@Falzo Hetzner firewall just have rules for incoming traffic - so I can't create any outgoing rules.
I have tried this rule (outlined in red), opening port 80 and 443 on all protocols. But it do not work at all.
And I have just found out why Google is working, it uses IPv6
Do you have 'ip' under the protocol tab?
@ExpertVM here is my options under the protocol tab. But I understand that
*is valid for all ports. Thats based on that the only entry in the Firewall, when I started, was a entry with all fields blank and*at the protocol.maybe I can have a look on it later at my hetzner account. From your pics my understanding would be for a general outgoing rule one would set the server ip as source and 0.0.0.0/0 as destination or alike?
yet I can't tell if this will help and I guess you already searched their knowledgebase...
PS: even if the firewall takes care of related/established connections you would need to at least be able to send and receive dns requests and answers. Had troubles with that lately on a vpn-server acl setup...
So you are pinging google over ipv6 and lowendtalk over ipv4. Probably your ipv6 works (not blocked by the firewall), ipv4 doesn't work (blocked).
Yea, thats sounds right, but IPv4 work for RDC and for FTP, that I have opened up for in my Firewall.
@Falzo thank you, and very nice of you if you can test on your own server.
Have not found anything in their KB.
I have found a "bush" fix that I can live with, but of course the best thing is to find out how I can use the Firewall, and still have access to IPv4 web.
The "fix" is as follows: I'm using my OpenVPN server with OpenVPN client. As soon as I connect to my OpenVPN server I loose RDC access.
I then use my OpenVPN client on one of my other computers, and login to the same OpenVPN server as my Hetzner server uses.
Then I can connect to RDC again.
It's not very important that the server has web access all the time. When I want to get some updates or other things, I just use the VPN solution.
Still, if someone can find out what incoming rule I have to create to get IPv4 web traffic on my server, with what ports and protocols, I will be very grateful.
try incoming source port 53 and protocol udp accept
It did not do any difference. No web access.
Can you try the following:
Allow INCOMING FROM ANY source, source ports 80+443 [TCP]
Allow OUTGOING TO ANY destination destination ports 80+443 [TCP]
That should take care of HTTP/S.
I don't know how to setup the "established" rules based on the Hetzner setup (from the above screenshots).
Repeat the above but use UDP port 53 that should take care of most of DNS (you can also add TCP port 53 for additional DNS traffic).
Works?
P.S: Correct way is of course to allow incoming related/established connections. Hopefully you can figure out how to do that.
try this.
dest port 80,443
set protocol to tcp (as you leave it as * above)
You might want to create a ICMP rule to allow any/any procotol icmp so you can do PING in cmd
@nullnothere @ExpertVM
I have tried incoming from ANY source, port 53,80,443 protocol TCP and aslo
*Do not work. I have also tried with ICMP also.
@nullnothere as mention, Hetzner Firewall do not give access to outgoing rules. So I can only add incoming rules.
There has to be another port that has to be opened. Maybe like I had to do with FTP. To get FTP working, showing folder etc, I had to open port 32768-65535
But since only one computer need FTP access, I have used a Source IP on that entry.
@myhken - just to confirm that you have opened ANY SOURCE and SOURCE PORT 80,443 and PROTOCOL TCP (for HTTPS).
You can leave destination IP as your own IP (or even *) and similarly destination port as undefined or * (not sure which is "right").
For DNS, you'll mainly need UDP port 53 (any source, source port 53, protocol UDP).
(again I'm clarifying if you've put SOURCE port in the above rules).
If you do have another machine (some other network, somewhere else), you can perhaps run a tcpdump there to see if packets from your Hetzner box are coming there and confirm that replies are going out - which will give you a clue as to whether there is also an outgoing rule (or something else) that is interfering (from the Hetzner side).
One more try: please try to put destination ports as 0-66535 for the HTTP/S rules just to see if that has to explicitly be defined as well (use your IP as destination IP).
i.e:
SRC IP = any
SRC PORTS = 443 + 80
DST IP = (your IP)
DST PORTS = (0-65535)
PROTOCOL = TCP
Does the above work for HTTP/S?
(the 0-65535 just because your screen shots show that as background text - so not sure if you don't put anything if that is the default or if you've to explicitly put it down).
Does the above work for HTTP/S?
Yes, when I do that it work. If I just set the DST PORTS = 53,80,443 PROTOCOL = TCP it do not work. So clearly I have to open some more ports. But how safe is it with Source PORT = 53,80,443 and DEST Port 0-65535? I'm thing about my other tread: https://www.lowendtalk.com/discussion/106209/how-is-it-possible-that-someone-can-try-to-login-via-rdc-when-i-have-a-ip-block
had a first quick look at it, and you are right - it definitely says incoming rules (wasn't visible on your screenshots ;-)) so most probably that should exactly be what to expect from it.
interesting enough: if you choose one of their predefined rule-sets it always has a last rule called 'established' checking higher ports for 'ACK' as flag:
also note that they don't define any source or destination IPs for the usable services in first place. of course one might think about using this to restrict certain service even further like your rdp on source IPs - but I probably would test how it works if at least the destination IP field is left blank instead of giving the server-ip.
as far as I understand it, the firewall config is bound to each server individually, so specifying different destination IPs may only make sense for further VM guests using additional IPs...
haven't seen you already tried some things while I was writing ;-)
I'd suggest trying to setup a rule for the RDP port with your source IPs, also FTP ports with source IPs. omit destination IPs on both (may add those later if really necessary).
also add a general rule like the #4 from hetzners template checking for ACK flag but not limiting to any IP. you probably might even change that range to 1024-65535 and protocols to *
port 80 and 443 incoming shouldn't be neccessary or at least not change anything, as you don't run a webserver. communication usually will have your browser connect (outgoing) to port 80/443 of a foreign webserver establishing a connection/receiving answer on a randomly chosen high port, which then needs to be available (hence the ACK)
EDIT: if one keeps in mind the initial problem you should also be able to just leave the firewall rule like the default (allow all) and just put two rules before that:
rdp access, your source IP, port 3389, ALLOW
rdp block, any source ip, port 3389, DISCARD
(3. allow all)
@mhyken - if you do not have an "allow incoming established" rule then you must have the rules I mentioned to allow incoming HTTP client traffic (i.e. you are using a browser on your Hetzner machine to browse public websites - i.e. your Hetzner machine is a HTTP/S CLIENT).
I don't know if it is a "stateful" firewall or not but as @Falzo points out, using the incoming rule with the ACK flag (actually it should be ACK+FIN+RST ie. except SYN flag) will take care of all related traffic (incoming) and you shouldn't need that catch all incoming HTTP/S traffic rule (and security wise this is safer option). This will not handle incoming related UDP traffic (so you'll still need the UDP port 53 rules for DNS).
hetzner claims it to be a "stateless firewall" - https://www.hetzner.de/ot/hosting/news/kostenlose-firewall-fuer-ihre-dedicated-root-server
@Falzo - thanks for the clarification.
So @myhken it is best to also restrict source ports for incoming traffic to be safer:
Example for HTTP/S client traffic (you/Hetzner machine browsing websites):
SRC IP = *
SRC PORTS = 443 + 80
DST IP = * or Empty or your IP (go with what Falzo's says on leaving this undefined to test).
DST PORTS = 1024-65535
PROTOCOL = TCP
FLAGS = ACK + RST + FIN (i.e. NO SYN) [allows related/established traffic]
The above rule should handle HTTP/S. Customize for other TCP traffic.
For UDP, you'll have to just blindly allow all incoming traffic like:
SRC IP = *
SRC PORTS = 53
(DST IP/PORTS like above for TCP)
PROTOCOL = UDP
(FLAGS = Ignore flags or allow all or *)
The above will allow your machine to get answers to DNS queries from public dns servers (e.g. 8.8.8.8).
You'll have to add TCP rule (like HTTP/S above) with port 53 for some DNS special cases.
I think that should be it.
Of course run an NMAP and verify :-)
(3. allow all)
I don't want to do this yet, since I'm pretty sure my original issue is with port 3389. I have tried both Telnet and every RDC client I have found, and used lots of servers around the world, and nobody get access to port 3389 if they don't use one my approved IPs.
And there is no mention of my attempts in my Security log.
So something else is open on my servers, that make it possible for someone with some kind of software, do actual login attempts on my servers.
It's pretty simple now. Running RDP Guard some time have found attempts on both of my main servers. On my Hetzner server, I have applied their Firewall, and I'm now sure that nobody have access to any other port that the ports I have opened in my Firewall.
On my other server, I'm just running Windows Firewall as before. I matter of days or weeks, I will see if there are any more attempts on my Hetzner server, compared with my OVH server.
Do you think it's a bad test?
@nullnothere @Falzo @ExpertVM
This is my current setup, did remove PORT 53, just have PORT 80 and 443, and web borwsing is still working. Added
ack|rst|fin. Any other changes you "want"?if it works for you it looks good enough to me ;-)
after you brought up the topic RDP , I also checked out my (only) win rdp and hurried to move the open port away from 3389 - which clearly helped so far, no further login attempts in the logs. yet, as mentioned in the other thread I simply achieved this by changing the forwarded port as I have that running on a guest VM :-)
custom username (deactivated default Administrator account) and strong pw, so don't really live in fear anyways, but really don't need that noise at all.
your solution with restricting per your IPs and having something like rdpguard banning the rest after very few attempts also should be very secure - yet I understand the curiosity for the failed attempts. For my VM I need to add a forwarding rule incoming 3350 and 5911 to get a connection established, so maybe any further digging into the basics of RDP may reveal how one can try to connect even without being able to access port 3389 directly...
@nullnothere @Falzo @ExpertVM thank you for all the help. Always good to have LET when you (me) get strange issues. LET should have the support tip that online.net have. Choose a username and tip them a Euro/Dollar
Why do we not have that @Jarland ?
I'm curious about one point though - so you're saying that browsing is working but you've not (based on the screenshot) allowed UDP port 53 (for DNS). So how come DNS is working?
Also, from the above, you're allowing (RDP) port 3389 only from a specific source IP to your destination IP - you needn't allow UDP (i.e. lock it down to TCP port 3389, allowing all flags) and that should be sufficient (again test+confirm).
Also, do pings work (again how come when I don't see any rule)?
Is there some other "allow" rules that you've setup that is not in the screenshot?
(I guess I'm now interested in understanding a bit more on the Hetzner firewall)
(also, there are some important ICMP types that must be allowed for IPv4 - so to keep things simple allow all ICMP's incoming).
@nullnothere Hetzner Firewall just allow 10 entries. So what in the picture it's all there is.
Yes I can ping IPv4 with this setup. The only thing that make this happen is rule number 2.
Why DNS is working? I really don't know. You are the experts, not me.