Architecture for securing home network with exposed web server
-
@stephenw10 oh, so that risk would only happen if i forwarded a port on my isp router? Because I didn't
In order to use my web server I'm using a cloudflare tunnel which doesn't require any port forwarding
-
Some level of increased risk yes.
How is the tunnel connected? Something is connecting out to Clouflare I assume. But not from the VM since the firewall rules you have prevent that.
-
@stephenw10 It really is weird now that you say that.
Because the only open port is 80. Could that be done through port 80?
Because in Cloudflare I only set the IP of the Ubuntu VM and nothing else, on port 80:
172.16.20.100:80
Is Cloudflare tunnel based on Wireguard? If so, could it be that the initial handshake to the Cloudflare tunnel was done before I created the firewall rules, and that was able to do that initial handshake? So if for example I now create a new tunnel, I won't be able to get that first handshake?
Or, I have something misconfigured :)
-
I believe it is based on Wireguard, yes. Where are you running the client?
That IP address for the VM is a private address so Cloudfllare would only be able to access it across a tunnel.
Where exactly is port 80 open?
-
@stephenw10 it's the rule in the picture in the above comment where it shows the destination is the OPTX Address and the Port is 80 so I think that's it?
I also checked other things like updating the server (sudo apt-get update) and indeed I cannot update. So if I recall correctly, WireGuard only needs the first handshake with the peer and then it sends keep alive pings all the time.
I can do a test and create a new tunnel to see if this is really it
-
That's the anti-lockout rule. It added by pfSense to allow hosts, on what would normally be the LAN, to always have access to the pfSense webgui.
It would not allow the VM to connect too Cloudflare. Nor Couldflre to connect to the VM. -
When you say connect to the tunnel, you mean the peer handshake? For example, if the initial connection was done on port 51820 - this is what you mean by not allow the connection?
-
Yes. The rule you have there would block all outbound traffic from the VM to cloudflare.
It's possible it had already connected before you added the rule in which case the connection would remain until the state is lost at reboot for example.
-
It's so weird (and annoying). Everything was working, and then I removed the firewall rule, so actually opened everything, and now nothing works - the tunnel stopped working and I can't even ping to the WAN anymore, and can't do sudo apt-get update.
How?! I removed the firewall rule, then how it did the opposite?
Last time it happened, I switched from DNS resolver to DNS forwarder and it started working. But now - the DNS forwarder is still the one enabled. so now I'm lost as to what happened.
Edit: I now created a "pass" rule for Any/Any and I can ping to the WAN again. However, DNS still doesn't work again.
-
Yes you would need a pass rule to allow it.
If it's pass all and any protocol then DNS should work as long as it's configured in the VM correctly.
-
@stephenw10 said in Architecture for securing home network with exposed web server:
Yes you would need a pass rule to allow it.
If it's pass all and any protocol then DNS should work as long as it's configured in the VM correctly.
thank you.
I am curious though now regarding the previous discussion - so in the case where I closed all ports earlier (after the handshake), and then only port 80 was open.
So surfing the website on my domain was possible according my theory. But, the HTTP request needs a response - and the response needs to go out from the server to the world via port 80. But the Anti-Lockout rule is only from source (*) and destination OPTX address. but not opposite - so how did the response go back out to whoever go to the domain? Or, it all happens in the same connection - request in port 80 - response goes back in this connection?
-
Nope that rule would not have allowed an outbound connection. But none of those prevent inbound connections and once the state is open the replies can use that.
However that would require something allowing inbound connection to reach the pfSense VM. So a port forward on the ISP router and another port forward on the pfSense VM to reach the server.
You don't have those as far as I know so if you were able to browse the site hosted on the server coming from some external IP address then the connection must have been coming over the tunnel to Cloudflare. That tunnel must have been created outbound from the server when you had a rule to allow it at some point. I would bet that if you had rebooted the server or pfSense at that point the connection would have failed.
