Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Proxmox setup reverse proxy for containers
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Proxmox setup reverse proxy for containers

kmmmkmmm Member
edited July 2019 in Help

Hi guys

In my last post I had some problems with internet but they are solved now and I am working on setting up containers and internal network.

My plan will be:

  • Proxmox host should be a "clean" system, means nothing but Proxmox direct installed.
  • I have 5 IPv4 and /64 IPv6 and 4 domains: 1 IPv4 for Proxmox host, 4 IPv4 for 4 domains. Each domain and its subdomains pointed to by same IPv4 and v6.
  • Each domain comes with subdomains for different self hosted services/apps each runs in own LXC container, for example Wordpress run alone in 1 container and pointed to by blog.xxx.com)
  • To redirect traffic to service/app on subdomain: Each domain assigned to 1 container, this container has nginx installed and works as reverse proxy, redirect traffic to corresponding container.

So the system can be described like this:

  • x.x.30.62 ... is the IPv4 for Proxmox, x.x.30.63 .... are IPv4 for domain, and assigned to reverse-proxy-container.
  • Slave containers (like 1.1, 1.2, 2.1 ...) have kind of internal network so they can talk to each other. They use some kind of NAT network to reach the outside world.

After a few hours tinkering I think this plan is not possible because Proxmox network doesn't work like that. What do you think, is the plan feasible? If not, how would you suggest to setup the it?

Comments

  • NeoonNeoon Community Contributor, Veteran
    edited July 2019

    You can do
    vmbr0 => Container => vmbr1 => Container 2.1
    vmbr0 => Container => vmbr2 => Container 1.1

    or

    vmbr0 => Container => vmbr1 => Container 2.1
    vmbr0 => Container => vmbr1 => Container 1.1

    The containers need something inbetween to communicate.

    Thanked by 2Falzo kmmm
  • exactly as @Neoon wrote:

    add another bridge that gives all your containers a second network interfaces with an internal IP, so that they can communicate with each other. if you want to separate things more from each other use different subnets on different bridges...

    Thanked by 2mehargags vimalware
  • Neoon is right.

    I just wonder why you don't setup both blog.ip63.com and forum.ip63.com as virtual host on container 1? It will achieve better performance in my point of view.
    Your architecture will work better if you have several different physical server but for a single dedicated, I see no differences. Or you have special reason?

  • kmmmkmmm Member

    @Neoon said:
    You can do
    vmbr0 => Container => vmbr1 => Container 2.1
    vmbr0 => Container => vmbr2 => Container 1.1

    or

    vmbr0 => Container => vmbr1 => Container 2.1
    vmbr0 => Container => vmbr1 => Container 1.1

    The containers need something inbetween to communicate.

    @Falzo said:
    exactly as @Neoon wrote:

    add another bridge that gives all your containers a second network interfaces with an internal IP, so that they can communicate with each other. if you want to separate things more from each other use different subnets on different bridges...

    I apologise for being a noob here, but I didn't get it:

    1. What does the "=>" mean here? And what does "vmbr0 => Container" as well as "Container => vmbr1" mean? What IPv4 do the bridges have?

    2. If anything above means that I should create a bridge inside a container I afraid that Proxmox doesn't allow that. I am running a VPS without nested virtual, so say no with VM @levnode.

  • no, it means just create another bridge on the node. call it vmbr1 for instance with a private address like 10.0.0.1/24 ot 172.16.0.1/24 or similar.

    now add another network device with that bridge assigned to the containers you want to be able to communicate with each other and assign IPs from the given subnet inside the guests obviously.

    if you want to separate more create vmbr2 with another subnet and so on...

    Thanked by 1kmmm
  • kmmmkmmm Member

    @Falzo said:
    no, it means just create another bridge on the node. call it vmbr1 for instance with a private address like 10.0.0.1/24 ot 172.16.0.1/24 or similar.

    now add another network device with that bridge assigned to the containers you want to be able to communicate with each other and assign IPs from the given subnet inside the guests obviously.

    if you want to separate more create vmbr2 with another subnet and so on...

    Yes this is clearly how to get internal network. But the problem is, how to give internet access to container 1.1 under the IP x.x.30.63? The idea is let container 1 act as reverse proxy so the outside world will communicate with container 1.1 through container 1 with IP x.x.30.63.

    (I use bridged mode to assign IP to container, therefore I see no way to give vmbr1 with 10.0.0.1/24 internet, even use NAT)

  • @kmmm said:

    But the problem is, how to give internet access to container 1.1 under the IP x.x.30.63? The idea is let container 1 act as reverse proxy so the outside world will communicate with container 1.1 through container 1 with IP x.x.30.63.

    (I use bridged mode to assign IP to container, therefore I see no way to give vmbr1 with 10.0.0.1/24 internet, even use NAT)

    no you probably understood that wrong. you don't need to use NAT or giving the private subnet internet access, if you don't want to.

    however - it might make sense to use NAT on vmbr1 on top to allow the internal IPs a connection into the public internet to be able to install them from repos and update them etc.
    that does not mean, that all traffic from container 1.1 would go through the .63 IP but rather take the way through main IP to the outside world.

    that's why you want to use a proxy for specific domains pointing to the .63 IP, which essentially relays them to the correct internal destination - regardless of the natted connection.

    so let's say container 1 gets your .63 and an internal IP, f.i. 10.0.0.10
    container 1.1 only gets an internal IP, f.i. 10.0.0.11
    container 1.2 only gets an internal IP, f.i. 10.0.0.12

    the nginx (or whatever) inside container 1 now listens on your .63 to the world and whenever a request for blog.ip63 comes in, it proxies that request to 10.0.0.11, hence the container 1.1 (which obviously also needs to be running a webserver)
    or whenever a request for forum.ip63 comes in, it proxies that request to 10.0.0.12, hence the container 1.2 (which obviously also needs to be running a webserver)

    this is not the same as NAT or port forwarding, so try to not mix it up and see the different concepts to finally wrap your head around it ;-) ;-) best of luck!

  • kmmmkmmm Member

    @Falzo said:

    @kmmm said:

    But the problem is, how to give internet access to container 1.1 under the IP x.x.30.63? The idea is let container 1 act as reverse proxy so the outside world will communicate with container 1.1 through container 1 with IP x.x.30.63.

    (I use bridged mode to assign IP to container, therefore I see no way to give vmbr1 with 10.0.0.1/24 internet, even use NAT)

    no you probably understood that wrong. you don't need to use NAT or giving the private subnet internet access, if you don't want to.

    however - it might make sense to use NAT on vmbr1 on top to allow the internal IPs a connection into the public internet to be able to install them from repos and update them etc.
    that does not mean, that all traffic from container 1.1 would go through the .63 IP but rather take the way through main IP to the outside world.

    that's why you want to use a proxy for specific domains pointing to the .63 IP, which essentially relays them to the correct internal destination - regardless of the natted connection.

    so let's say container 1 gets your .63 and an internal IP, f.i. 10.0.0.10
    container 1.1 only gets an internal IP, f.i. 10.0.0.11
    container 1.2 only gets an internal IP, f.i. 10.0.0.12

    the nginx (or whatever) inside container 1 now listens on your .63 to the world and whenever a request for blog.ip63 comes in, it proxies that request to 10.0.0.11, hence the container 1.1 (which obviously also needs to be running a webserver)
    or whenever a request for forum.ip63 comes in, it proxies that request to 10.0.0.12, hence the container 1.2 (which obviously also needs to be running a webserver)

    this is not the same as NAT or port forwarding, so try to not mix it up and see the different concepts to finally wrap your head around it ;-) ;-) best of luck!

    Thanks for your clearly answer, but the onlything that is bothering me is: how container 1.1 answer the request? How can the answer travel from container 1.1 and reach the client (requester), and it must hast x.x.30.63 in header?

  • FalzoFalzo Member
    edited August 2019

    kmmm said: Thanks for your clearly answer, but the onlything that is bothering me is: how container 1.1 answer the request? How can the answer travel from container 1.1 and reach the client (requester), and it must hast x.x.30.63 in header?

    the container 1.1 never answers the client directly but ofc to the proxy, which sends that answer back, just as you would expect it:

    client --> proxy at .63 --> container at 1.1
    client <-- proxy at .63 <-- container at 1.1

    or you could put it that way:

    public internet request a webpage at .63 - proxy receives and relays that request into the internal network to 1.1 - 1.1 receives and answer to the proxy on internal network - proxy relays the internal answer to the external client using .63 ;-)

  • kmmmkmmm Member

    Ah I know it: container 1 must act as a proxy, it exam the packet from container 1.1 and replace the ip header and send the packet to outside world, OR it and container 1.1 know the existence of each other and aware the real-ip of request; container 1.1 know the real ip of request and „intended“ send the packet to real-ip destination, and the first hop is container 1 (which is known by c1.1 as 10.0.0.10) so the packet can be forwarded to its real-ip destination.

    Is that correct? :)

  • jvnadrjvnadr Member
    edited August 2019

    I'll try to give some handy tutorial.

    First of all, create a bridged vmbr1 virtual adapter with an internal ip range (e.g. 10.0.0.0/24). In my tutorial, we will give to vmbr1 the address 10.0.0.1 . Link the vmbr1 to vmbr0.
    Enable in in /etc/sysctl.conf this: net.ipv4.ip_forward=1 and start the new config using the command sysctl -p
    Create your container or vm. For container, enable vmbr1 as network adapter and give an internal ip address, e.g. 10.0.0.12 with 255.255.255.255 netmask (10.0.0.12/32) and gateway 10.0.0.1 (the address of the vmbr1).
    I always create a script that gives me access easily to all of my containers, using a port. So, create something like /etc/init.d/routing and put in there something like this:
    https://pastebin.com/raw/HQbPkY5Y

    It is not necessary to do port forwarding, but it is extremely handy for managing the new vps. Ypu may notice that in the beginning I delete all previous rules, to clean up the set and not creating duplicates every time I add a new container. If you have some irrelevant ip rules, be sure either to create them again or to add them to this script, to be created automatically every time you run it.
    Chmode +x this script and run it using this: /etc/init.d/routing start
    In debian, you can use this update-rc.d routing defaults to run it in every boot or just add it as a cron jop with @restart in the beginning of the line.

    Install nginx in your node. We will use nginx as reverse proxy, as you want in your diagram.
    Now, for each site you want proxy forwarding, you will create a config file (I create separate configs just to handle them more easily).

    Create something like this /etc/nginx/conf.d/mydomain.net.conf

    And put this inside:

    server {
    listen 80;
    server_name mydomain.net *.mydomain.net;
    location / {
    proxy_pass              http://10.0.0.12;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
     client_body_buffer_size 128k;
    }
    }
    

    For ssl access, add this:

    server {
    listen 443 ssl;
    server_name mydomain.net *.mydomain.net;
    ssl_certificate /etc/nginx/ssl/mydomain.crt;
    ssl_certificate_key /etc/nginx/ssl/mydomain.key;
    location / {
    proxy_pass              https://10.0.0.12;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
    client_body_buffer_size 128k;
    }
    }
    

    Now, go to (or create) /etc/nginx/ssl/ folder and create the two files: mydomain.crt and mydomain.key . Insert your ssl keys there. If you are using Let's Encrypt that is generated automatically on your container, just sync the keys from your container to those files in your proxmox node (it's rather easy: I use cronjobs to rsync them every 1 minute having before connect the proxmox node to the container using ssh keys).

    Restart nginx and point your domain to the external ipv4 of the proxmox node.
    You are ready!

    P.S. For a KVM, don't forget to enter via proxmox's vnc to the new vm and enter manually your internal ip there (10.0.0.12) using vmbr1's address (10.0.0.1) as gateway.

    P.S.2: You can add as many subdomains in your nginx config as you want, pointing them either to the same vm or to another vm.

    Thanked by 1Falzo
  • @kmmm said:
    Ah I know it: container 1 must act as a proxy, it exam the packet from container 1.1 and replace the ip header and send the packet to outside world, OR it and container 1.1 know the existence of each other and aware the real-ip of request; container 1.1 know the real ip of request and „intended“ send the packet to real-ip destination, and the first hop is container 1 (which is known by c1.1 as 10.0.0.10) so the packet can be forwarded to its real-ip destination.

    Is that correct? :)

    yes, you need to configure nginx as proxy for that obviously, telling it were to send stuff for domain XY to and maybe forwarding the ip header etc.
    so you probably want to start looking into its documentation soon, as that's something apart from the network config itself ;-)

  • @jvnadr said:

    I'll try to give some handy tutorial.

    very nicely written. however, he wants to have nginx not directly on the node but in a separate container, which then could have his bridged public IP via vmbr0 and also one from the internal network via vmbr1. other then that obviously all your wrote applies ^^

    Thanked by 1jvnadr
  • jvnadrjvnadr Member
    edited August 2019

    Falzo said: very nicely written. however, he wants to have nginx not directly on the node but in a separate container, which then could have his bridged public IP via vmbr0 and also one from the internal network via vmbr1. other then that obviously all your wrote applies ^^

    I didn't notice that, but it is extremely easy to achieve it using this. Create a container with an internal address (e.g. 10.0.0.250), install there nginx and forward all necessary ports from the external ip or vmbr0 that listens to the external ip to the container. Then, the nginx container will forward requests to another internal container. It can also forward request to an entirely external ipv4 that is hosted in another node, or to a second ipv4 in the same node.

    The sky is the limit!

    P.S.: However @kmmm I think that using nginx in the node would be something much more efficient and simple and does not limit to be used for more than one set of internal ips or even to proxy also to an apache instance in the node, if something is hosted there. Why don't you want to use nginx on the proxmox node and need a container for that?
    If you have multiple ips, just bridge the second ipv4 (x.x.30.63) with a vmbr and bridge vmbr1 with the vmbr of the second ip.

    Thanked by 1Falzo
  • And adding something to my previous comments: @kmmm you can install nginx on the proxmox node and let it listen only to the x.x.30.63 or x.x.30.64 or every and any ips you want, excluding x.x.30.62. Just be sure that in listen 80; and listen 443; directives on any config file, you add the specific ip you want to listen (listen x.x.30.62:80 and listen x.x.30.62:443)

    Thanked by 2Falzo kmmm
  • kmmmkmmm Member
    edited August 2019

    @jvnadr said:
    And adding something to my previous comments: @kmmm you can install nginx on the proxmox node and let it listen only to the x.x.30.63 or x.x.30.64 or every and any ips you want, excluding x.x.30.62. Just be sure that in listen 80; and listen 443; directives on any config file, you add the specific ip you want to listen (listen x.x.30.62:80 and listen x.x.30.62:443)

    Thanks guys I will try your suggestions asap.

    Although I used nginx for reversing traffic before, my head was repeatedly banged in the last few weeks and I am a new guy to Proxmox and had a lot of troubles setting up the host => not easy to stick stuffs together.

    Some reason for NOT using nginx directly on node @jvnadr:

    • I want to keep Proxmox host clean.
    • I want to apply different rules on incoming traffic to each IP/domain, and still keep the node's IPtables clean.
    • I want to separate every applications/services in own container so I can archive the most isolation and easier to destroy/recreate thing, independently!
    • Performance is not the thing I am considering now on this setup, it is much like an experiment, for collecting experiences :).
  • kmmm said: I want to keep Proxmox host clean. I want to apply different rules on incoming traffic to each IP/domain, and still keep the node's IPtables clean. I want to separate every applications/services in own container so I can archive the most isolation and easier to destroy/recreate thing, independently!

    It's a thing to keep proxmox node clean and another thing to let it naked... IMHO, a proxmox node NEEDS to have several addition stuff in it, like security software like fail2ban, a nginx setup for proxying, ip table rules for handling the vms and for aborting / firewalling things and, last but not least, a webmin installation for, you know, tons of stuff regarding monitoring, handling, automate etc.
    Those things does not add garbage or unecessary things to the node, but maximizing it productivity.
    Adding nginx to the node has nothing to do with seperating application in containers. If you do not have at least one ip for every container ot vm, then, iprules and nginx is a must. Otherwise, you installed proxmox and won't take advantage on it at all.
    Also, creating a container to manage other containers, does exactly the opposit on avoiding what you wrote. It ads much more complexivity, more points of failure and dependency not on the node itself, but on just a vm for all the rest of your vms.
    Ip rules should be on the node. It doesn't make sense the "keep node's iptables clean", when the scope of iptables is to make things on routing work. Clean means not bloated. If you do it properly, like the script I suggested, then, the controlling can achieved just on editing the script, because on every run it cleans all the rest or garbage that are not inside it.
    Anyhow, good luck with your experiment.

    Thanked by 1kmmm
  • kmmmkmmm Member

    @jvnadr said:

    kmmm said: I want to keep Proxmox host clean. I want to apply different rules on incoming traffic to each IP/domain, and still keep the node's IPtables clean. I want to separate every applications/services in own container so I can archive the most isolation and easier to destroy/recreate thing, independently!

    It's a thing to keep proxmox node clean and another thing to let it naked... IMHO, a proxmox node NEEDS to have several addition stuff in it, like security software like fail2ban, a nginx setup for proxying, ip table rules for handling the vms and for aborting / firewalling things and, last but not least, a webmin installation for, you know, tons of stuff regarding monitoring, handling, automate etc.
    Those things does not add garbage or unecessary things to the node, but maximizing it productivity.
    Adding nginx to the node has nothing to do with seperating application in containers. If you do not have at least one ip for every container ot vm, then, iprules and nginx is a must. Otherwise, you installed proxmox and won't take advantage on it at all.
    Also, creating a container to manage other containers, does exactly the opposit on avoiding what you wrote. It ads much more complexivity, more points of failure and dependency not on the node itself, but on just a vm for all the rest of your vms.
    Ip rules should be on the node. It doesn't make sense the "keep node's iptables clean", when the scope of iptables is to make things on routing work. Clean means not bloated. If you do it properly, like the script I suggested, then, the controlling can achieved just on editing the script, because on every run it cleans all the rest or garbage that are not inside it.
    Anyhow, good luck with your experiment.

    (The basic and security packages like fail2ban, ... will be there directly on the node.)
    I was setting up the node like you and @Falzo suggested. But then I got a problem:

    • In bridged mode: Nginx on node didn't log any access to x.x.20.64 so I assume I need to assign x.x.20.64 on a bridge/interface on node or container, but I don't know where?
    auto lo
    iface lo inet loopback
    
    iface ens3 inet manual
    
    auto vmbr0
    iface vmbr0 inet static
            address  x.x.20.63
            netmask  23
            gateway  x.x.20.1
            bridge-ports ens3
            bridge-stp off
            bridge-fd 0
    
    auto vmbr1
    iface vmbr1 inet static
            address  10.0.0.1
            netmask  24
            bridge-ports vmbr0
            bridge-stp off
            bridge-fd 0
    
    • In routed mode: The vmbr0 has IP x.x.20.64. If try ping -I vmbr0 8.8.8.8=> 100% packet loss. Ping its IP from my home PC => ok, but ens3 answered because ifconfig vmbr0 show no change at packet received. I create vmbr1 and do like you said (that is: the script, internal IP, ...) => from outside I can reach the web (clearly, traffics do not go through vmbr0. I have the feeling this bridge is there only to tell "this node has an IP x.x.20.64), but I do not have internet to outside world in container. Change the script to
    post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o ens3 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o ens3 -j MASQUERADE
    

    => have Internet. Of course through ens3. Do you have problem like that?

    auto lo
    iface lo inet loopback
    
    auto ens3
    iface ens3 inet static
            address  x.x.20.93
            netmask  23
            gateway  x.x.20.1
            post-up echo 1 > /proc/sys/net/ipv4/ip_forward
            post-up echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp
    
    auto vmbr0
    iface vmbr0 inet static
            address  x.x.20.64
            netmask  23
            gateway  x.x.20.1
            bridge-ports none
            bridge-stp off
            bridge-fd 0
    
    auto vmbr1
    iface vmbr1 inet static
            address  10.0.0.1
            netmask  24
            bridge-ports vmbr0
            bridge-stp off
            bridge-fd 0
            post-up echo 1 > /proc/sys/net/ipv4/ip_forward
            post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
            post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
    
  • FalzoFalzo Member
    edited August 2019

    sounds like you are moving to fast / mixing up things. better work it out step by step.

    first you wrote you use vmbr0 in bridged mode to assign the different IPs to the containers for proxying, that's fine.
    so with the part from your first config postet for ens3/vmbr0 you should be able to reach the container via the .64 IP, for ssh as well as nginx - for that you wrote above that this already worked...
    that does not rely or has anything to do with the internal network. so make sure it works first, aka with a standard nginx you should see at least the test page when opening the IP in a browser.

    if you now add vmbr1 as you did, ideally you use the version from your second config which includes port forwarding and NAT - though, no need to change ens3/vmbr0, just leave them be.

    be aware that you need to add a second network interface to your container with vmbr1 in proxmox and not just change the bridge on the main interface...

    once you have the second interfaces configured - which via NAT also allows outgoing access, you should create your second container which will be the destination for your proxies requests.

  • kmmmkmmm Member
    edited August 2019

    @Falzo said:
    sounds like you are moving to fast / mixing up things. better work it out step by step.

    first you wrote you use vmbr0 in bridged mode to assign the different IPs to the containers for proxying, that's fine.
    so with the part from your first config postet for ens3/vmbr0 you should be able to reach the container via the .64 IP, for ssh as well as nginx - for that you wrote above that this already worked...
    that does not rely or has anything to do with the internal network. so make sure it works first, aka with a standard nginx you should see at least the test page when opening the IP in a browser.

    if you now add vmbr1 as you did, ideally you use the version from your second config which includes port forwarding and NAT - though, no need to change ens3/vmbr0, just leave them be.

    be aware that you need to add a second network interface to your container with vmbr1 in proxmox and not just change the bridge on the main interface...

    once you have the second interfaces configured - which via NAT also allows outgoing access, you should create your second container which will be the destination for your proxies requests.

    I mean that I will not use separate container for Nginx instances but install Nginx directly on node @Falzo:

    I was setting up the node like you and @Falzo suggested.

    The biggest problem now is: why tf doesn't vmbr have internet in routed mode? ping -I vmbr0 8.8.8.8100% loss. Create container with IP x.x.20.64 or 65, bridged vmbr0 => no internet.

  • kmmm said: I mean that I will not use separate container for Nginx instances but install Nginx directly on node

    okay, sorry I totally misunderstood that.

    so if you leave all IPs on the node level you don't need a seperate bridge. you could use a bridge like in the first part of your first config example and simply add the IP directly to it (ip addr add ...).

    or if you keep it with ens3 add the second IP there and bridge vmbr1 to ens3 instead. no vmbr0 needed at all.

    however you need to tell the node in one of the devices that it also has that .64 IP assigned...

    the way your last complete config is mixed together, vmbr0 bridges to nothing and vmbr1 routes to vmbr1 - that's not gonna work ;-)

    Thanked by 1kmmm
  • kmmmkmmm Member
    edited August 2019

    @Falzo said:

    kmmm said: I mean that I will not use separate container for Nginx instances but install Nginx directly on node

    okay, sorry I totally misunderstood that.

    so if you leave all IPs on the node level you don't need a seperate bridge. you could use a bridge like in the first part of your first config example and simply add the IP directly to it (ip addr add ...).

    or if you keep it with ens3 add the second IP there and bridge vmbr1 to ens3 instead. no vmbr0 needed at all.

    however you need to tell the node in one of the devices that it also has that .64 IP assigned...

    the way your last complete config is mixed together, vmbr0 bridges to nothing and vmbr1 routes to vmbr1 - that's not gonna work ;-)

    Thanks that solve the problem. Now I am wondering why I didn't get it before ;)

    I am learning how to use/config Proxmox and have some more questions @Falzo @jvnadr:

    • What do you use for firewall? The Proxmox's one or iptables?
    • Usually there are a lot of unwanted visits and I don't want to allow them putting their toes in my house. What is the best way to archive this? I used to use ufw to block all IPs from http://iplists.firehol.org/ for example but this is Proxmox ... And how okay is http://iplists.firehol.org/?
    • Can you share some experiences configuring Proxmox?
  • yes, iptables all the way, fail2ban for tackling bruteforce attempts
    yes, some lists from firehol but instead of ufw I just use ipset with a small update-script that runs via cron ( based on this: https://github.com/trick77/ipset-blacklist/blob/master/update-blacklist.sh )

    if you have nginx already running on the node, you can use it to hide the control panel itself behind it with httpauth on top: https://www.lowendtalk.com/discussion/91919/restricting-access-to-proxmox-web-interface-with-nginx

    while proxmox offers a lot more features I barely use them (no clustering and stuff), so can't tell much more. their forums are sometimes helpful, especially if looking for specific stuff.

  • I have CSF on the proxmox host, mainly out of familiarity but also down to feature set.

Sign In or Register to comment.