Able to remotely connect to Portainer (wan IP:9000) when it is NOT in my Cisco Firepower ACL.

You're asking us about the (mis)configuration of your firewall appliance, you must be joking.

Do you have UPNP (https://en.wikipedia.org/wiki/Universal_Plug_and_Play) enabled on your FPR device ?

Zitat von fbeye

Oh it may be misconfigured for sure, not denying that. I was just lost as to how on the firewall I only have 4 ports open, none being 9000, and how I am able to connect to that IP:9000 and get through if its closed! Upon looking into it, I am thinking maybe because Port 9000 is listening in general, maybe that is how it is allowing bi-directional connectivity. Almost like because it ,portainer, is listening, it bypasses my ACL's/firewall allowing me in. Just because I do not have an ACL allowing incoming (initiated) incoming, it allows me in cause portainer itself is opening the path itself. It was not a me vs you vs them. I was just wondering if this was something I could get perspective on.

Like I was hoping maybe someone would say "Oh, because Portainer is already listening to 9000 it sort of opens a tunnel which bypasses ACL's on firewall" . Was not trying to start anything.

To my knowledge and via a test I just did to confirm, portainer does not open port 9000 via upnp in my firewall. You must have something set odd in there, and will have to look closer

Assuming that your firewall appliance is between the "internet" and your local network ...

If your firewall is doing what it's supposed to do, then no incoming traffic on any port (other than 22, 4443, 8080 and 8181) should be allowed.

How about UPNP on your firewall appliance ?

Zitat von fbeye

All I have enabled for the IP for OMV/Portainer on the FPR is NAT which is simply WAN x.x.x.177 to LAN 192.168.5.42 (No port association, simply WAN to LAN NAT and then 4 ACL's which are the ones I mentioned.

Ah, It all starts to become clear now.

Not a clue about that router in particular, but there should be no need to do a specific WAN to LAN NAT normally if you are using it for firewall purposes. By setting up that NAT, you have probably done essentially the same thing as putting your server directly on the internet, which is why your portainer is visible. The NAT simply connects the two IP addresses directly together. All of your other posts where you are concerned about exposing ports are completely thrown out the window by doing this because all ports of your server are exposed to the internet.

Routers can generally be configured for 2 purposes, connecting networks or firewall. If you want firewall, disable the configured NAT, and use port forwarding to direct just the required ports to the server.

NAT and port forwarding are different, but they are often used in conjunction with each other.

NAT is network address translation. It translates traffic from one IP address to another. An example: NATing your WAN IP address 1.2.3.4 to your internal webserver 192.168.0.1.

Port forwarding (sometimes called PAT - Port Address Translation) is similar, but it functions on the port level. You can forward port 80 from your WAN IP address to your internal webserver, for example.

Zitat von fbeye

All I have enabled for the IP for OMV/Portainer on the FPR is NAT which is simply WAN x.x.x.177 to LAN 192.168.5.42 (No port association, simply WAN to LAN NAT

And you were always concerned about safety??????

The statement below says everything.

Zitat von BernH

All of your other posts where you are concerned about exposing ports are completely thrown out the window by doing this because all ports of your server are exposed to the internet.

Zitat von fbeye

To both those recent response, I did not know this!!!! I thought I had to NAT my WAN to LAN IP's because I had a Block of 8 STATIC IP's. I just thought that how would my LAN IP know what WAN IP to use without NAT.. It is not just 1 WAN IP to many LAN IP's.

My WAN (Router) is x.x.x.182 but I was NAT'ng my x.x.x.177 to 192.168.5.42.

When I get home I will look into this.

Based on what you are saying, I am essentially creating a tunnel from WAN IP to LAN IP and thus my ACL's (firewall) are irrelevant and therefore Firewall would be done host side, OMV/Debian?

You are not even creating a tunnel from WAN to LAN really. You are just putting your server on the internet because all the router is doing is making anything that sees your WAN IP get re-directed to your LAN IP. (ie. WAN = LAN) To the right hacker type, you may have exposed your entire network even, because there is no security, and no encryption.

This is the whole purpose of using port forwarding and a reverse proxy with forced ssl to re-direct traffic to the correct server or web app. I wouldn't even expose the other ports you mentioned, especially the port 22 that you mentioned as that is used for ssh. If you need to be able to remote admin via ssh, set up wireguard or openvpn and connect via that, then establish the ssh connection over the vpn. And while you would have to open the ports for that, it is a secure encrypted connection that requires server and client certificates to establish the connection.

So to recap what we have been telling you across the several threads on the forum:

Do not use a direct NAT.

Via port forwarding to your server, only open 80 & 443 for web server access, the ports for the VPN if you are setting one up, and anything else that you need that can't be handled by those such as 3478 for nextcloud talk or something similar.

Use the reverse proxy for website direction and ssl encryption.

You do not need a separate static IP for each server or even a separate DNS mapping for each server if you don't want it.

The reverse proxy looks after all the various web servers via domains and subdomains.

As I think I mentioned in the thread about the reverse proxy, I have several web accessible things running but they can be accessed with one duckdns domain that I have subdomains set up for.

for an example illustrating this setup:

on duckdns I could define mydomain.duckdns.org pointing to my WAN IP (and yes most of us only have one WAN IP)

In my router, I port forward 80 and 443 to my server on ports 8080 and 4443

my nginx-proxy-manager or SWAG listens on 8080 and 4443 externally, but internally they use 80 and 443. The router converts 80-8080 and 443-4443, and the container does the inverse, so as far as the reverse proxy is concerned the 8080 and 4443 don't even exist.

I have defined in nginx-proxy-manager or SWAG servers such as calibre.mydomain.duckdns.org, jellyfin.mydomain.duckdns.org, plex.mydomain.duckdns.org, etc.

nginx-proxy-manager or SWAG uses those server definitions with the subdomains of calibre, jellyfin, plex, etc, to rout the traffic to the correct docker container, virtual machine, LXC container, etc, on the ports that they are listening on.

multiple web servers, one reverse proxy server, many sub-somains, one domain (or up to 5 if required in duckdns) I actually use 2 domains, but it can all be done with one.

And finally, I don't mean to sound rude, but given your level of knowledge on this stuff, I would suggest that you start with nginx-proxy-manager instead of SWAG. SWAG requires editing of text based config files to make it work while nginx-proxy-manager uses a much simpler webpage GUI (and please don't expose this to the internet. Access it via the VPN connection if required from outside your LAN) SWAG can do a lot more, but if you don't need a lot more, you don't really need SWAG. You can always switch to SWAG if you outgrow nginx-proxy-manager.

As I said before, when using a router as a firewall between networks there should not be a direct NAT to a computer's IP. Normally the router will act as a DHCP server to the LAN side and will automatically allow outgoing access. Incoming access is done at the port level for security reasons.

Yes your setup is wrong as far a using a router as a firewall is concerned, and I think you may be trying to over-complicate things with your extreme concern over security, but in doing so, you have essentially placed your server in directly on the internet and in front of your router, negating any security a router/firewall can offer. However, if you are happy with the way it is using the iptables of the server to block access that is entirely up to you.

Zitat von fbeye

Alright so your last comment bothered me immensely, in a good way. I will ask questions over and over and over again until you hate me and I am fine with that, but one thing I am as well is, yearning to learn.

Literally could not sleep, over in my mind around and around.

I took yesterday off and read about 200 pages from various sources etc, and guess what I cam up with.

On the FPR1010 there is a default action; Trust, Allow and Block. This is to take place at the end of all "Allow" ACL's. BUT I had mine set to ALLOW which essentially bypassed every firewall rule no matter what I did. Badda BING. Changed it to BLOCK and so whatever is NOT on ACL, gets blocked.

So I may be annoying but I am also seeking knowledge and refused to "band-aid" a situation. So thank you for keeping on me about being wrong, as it paid off.

Alles anzeigen

Sorry, I didn't want to to miss a day's work, but I'm happy to hear that you have corrected the misconfiguration and secured your network better. I'm also sorry I could tell you that information directly, but I am not familiar with that router, so it is up to you as the owner/user to learn the correct setup.

I do find it odd that you said there is no mention of port forwarding in the router, as that is a fairly standard term for routers, but your mention of ACL in the router is a term that is not standard. It's been 10 years or so since I have been into a Cisco router so perhaps Cisco is doing something very different in that one.

All that said, I have no problems helping anyone who is willing to learn, and will do whatever it takes to do so.

Zitat von fbeye

I know what you mean, I have seen Port Forwarding on every Router I have been on. With this Cisco I believe they got creative and simply removed "Port Forwarding" as a label and within their ACL's (firewall rules) they do have a source "port" and "network" as well as a destination "port" and "network" so I am to believe that is their version of it.

Indeed, that does sound like port forwarding, just with a different name.