@eddiejennings said in Reverse Proxy for Single Public Facing Server:

@dashrender said in Reverse Proxy for Single Public Facing Server:

@eddiejennings said in Reverse Proxy for Single Public Facing Server:

@dashrender said in Reverse Proxy for Single Public Facing Server:

That's pretty easy to do when you're self hosted, but if you're doing something like Vultr instances, I'm guessing it's a bit harder - unless Vultr allows for the creation of VMs that only exist on a private network.

True and that why I specifically mentioned a self-hosting scenario. I think I have a thread from the past asking about whether or not people bother with reverse-proxy for things hosted in Vulture or the like.

I don't think that it makes a difference.

I like the idea of the web application firewall, and that looks like something that can setup on the same VM as what would be running Nextcloud, etc.

@WLS-ITGuy said in Reverse Proxy install question:

@scottalanmiller said in Reverse Proxy install question:

@WLS-ITGuy said in Reverse Proxy install question:

@scottalanmiller said in Reverse Proxy install question:

@WLS-ITGuy said in Reverse Proxy install question:

@scottalanmiller said in Reverse Proxy install question:

@WLS-ITGuy said in Reverse Proxy install question:

@wrx7m said in Reverse Proxy install question:

@WLS-ITGuy What version of vsphere are you running?

6.7u2

They say it is supported...

https://blogs.vmware.com/guestosguide/2019/05/red-hat-enterprise-linux-8.html

REHL 8 is - But using the drop down and selecting Fedora it says it isn't.

Either way, I'll just use REHL 8 and be done.

The drop down list told you RHEL isn't, either. Yet we know it is. ESXi is just broken.

That one doesn't actually tell me it isn't supported:

alt text

But the other RHEL one does. So clearly it's broken if it gives conflicting information. In one case, RHEL isn't supported, then RHEL 8 is. But RHEL 8 is still RHEL.

I understand. I guess they don't update the dropdown in the software 😄

Then best to not use it and not to consider anything from it. Just skip it and protect yourself.

@wrx7m said in Configure Nginx as Reverse Proxy for ScreenConnect to Enable Lets Encrypt:

Less to that than I thought there would be.

It's surprisingly simple and basic. It's really just passing one port to another, and using SSL. About the most basic setup you can have.

If you get external DNS to go to the nginx proxy you could probably allow all traffic to the URL path that lets encrypt needs and then create a whitelist for everything else.

@black3dynamite said in NGINX Reverse Proxy Help - Error code: SSL_ERROR_RX_RECORD_TOO_LONG:

In the server block, add ssl_protocols TLSv1.2; and reload nginx

no joy. Incognito mode did not work either.

@flaxking said in Traefik Reverse Proxy:

Are you currently using it in production?

Not at work. I'm using it for projects outside of that though. My docker compose stack at home uses it.

we use Kemp to publish Skype for Business and SharePoint. Their guides are excellent!

@scottalanmiller said in NGinx Configuration Block for Zimbra Reverse Proxy:

Someone was looking for this specifically so...

server { client_max_body_size 80M; server_name my.domain.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_redirect off; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass https://myip:443/; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } listen 80; ssl_stapling on; ssl_stapling_verify on; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/my.domain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot }

Remember to create one for the Admin console on port 7071.

@Romo said in Collabora CODE and NextCloud Integration Shows Blank Editing Page and Spinning Circle:

Just got it working, it was indeed a DNS issue. When launching the docker container I added the --add-host name:ip option to add an entry to the hosts file that pointed to the internal ip of our nextcloud server and that made it properly work.

0_1543340489749_collabora-2.png

Its now properly working 😃

I'll have to try that tonight!

@taurex said in Cloudflare and Nginx reverse proxy background.:

@travisdh1 Are there any benefits of configuring your own reverse-proxy if it's running behind CloudFlare that is essentially the one already? I know they offer their own Origin CA certs that you can install on your web servers to encrypt the traffic between CF and your cloud. As long as you're happy to stick with CloudFlare, there will be no need to run cron jobs with certbot renewals every 3 months.

As @JaredBusch said, you can run self-signed certs with CloudFlare just fine. This was for my home lab, so I purposely do things the hard way sometimes, just to see what it's like. That's why I originally tackled this anyway. Running a reverse proxy mostly so I don't have to pay for nearly 30 IP addresses on the box I rent for it.

@scottalanmiller said in Anyone Using Collabora and NextCloud Behind NGinx?:

Not sure how I should have things configured. I believe that I followed all of the instructions properly, but it is not working and there are no really clear instructions for a dual server scenario. All of the official stuff lists single server and Apache.

The one thing I remember having issues with was that it wants to communicate over the same "channel" in between the Collabora and NextCloud servers, so if the external browser connection is https, then it's not happy and throws errors if the back end isn't communicating over https as well. Getting that https channel setup with the recommended Drupal container and instructions for that didn't seem to work, and was such a pain I gave up trying to get it fixed at the time.

https://serverfault.com/questions/663855/haproxy-for-load-balancing-vsftpd-servers

@jaredbusch said in 302 Moved Error:

That auto generated stuff is only sending stuff to the Apache host on the same box as Nginx.

Thanks for your valuable comments.

I solved this problem.
I've erased all routing on Nginx/Apache :smiling_face_with_smiling_eyes: ,

I created a virtual server for HAproxy, I installed HAproxy and currently all virtual servers routing process was completed.

Only I have one problem with HAproxy conf. file, I do not know how to do FTP Routing.
if you want to see the topic, please visit this topic.

It's now 2/15/2024 with Fedora 39, and this is still working.

Just setup a new reverse proxy.

This behavior is different than the last time I setup a reverse proxy like this. But that was also on CentOS 7 and not Fedora. So policy could be different.

@syko24 free... and useless:

Limitations of the free license:

The free license is limited to five locks per day which means the free edition defends your system against five unique attacks per day. [...] The free license does not contain reporting (like the PRO edition does).

Also, no official support for Windows Server 2016.

https://cyberarms.net/download-pricing/installation-configuration.aspx

@black3dynamite said in Problem with Nginx conf file:

Comparing the two configs

CRM under location / does not have this:
proxy_set_header X-Forwarded-Proto $scheme;

That probably went missing when I was troubleshooting. I was copy pasting in pieces and removing them trying to figure out why it was not working.

This way you can share the config(s) under conf.d between multiple machines using the same roles (or whatever Salt calls them) and have different main NGINX server settings.