Ice Drake's questions

I recently did some cable management (including ethernet). After I was done, I found that none of my Synology NAS units weren't able to reconnect to the Active Directory on my domain server. To be exact, they did intermittently reconnect, but disconnect roughly every other time I checked it. Fiddling with the domain setting on the NAS made no difference.

Tracing back, the only thing that was different is that I installed the recent server updates before shutting it down for cable management:

1. 2024-11 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5046612)
2. Security Update for SQL Server 2017 RTM GDR (KB5046857)
3. 2024-09 Servicing Stack Update for Windows Server 2016 for x64-based Systems (KB5043124)

I tried reverting back by uninstalling the updates, but it makes no difference. After troubleshooting for the past few days, I noticed something I haven't before. The ethernet port on the Domain Controller has NetBIOS over TCP/IP disabled. Research says that NetBIOS is required for SMB to work, which makes sense why the Synology NAS units can't properly reconnect if they can't get SMB to work reliably. (Note that I have disabled SMB 1.0 long ago for security and performance reason, and it did work with no issue when SMB 1.0 was disabled.)

However, I can't seem to figure how to get NetBIOS over TCP/IP enabled. Is it not possible for ethernet port, vEthernet (Virtual Switch)?

What I have tried:

1. Changing the setting in the WINS tab of IPv4 setting from Default to Enable NetBIOS over TCP/IP with IPv6 disabled.
2. Edit the registry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters for all the interfaces I saw for the key value NetbiosOptions from 0 to 1.

Thinking that it might be a Windows bug, I installed the latest update, but it is still disabled: 2024-12 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5048671)

I currently have Windows Server setup with one physical ethernet port (eth0) as an external VLAN trunk connected to a Hyper-V virtual external switch for VMs to share with the host. The host uses specifically VLAN1 while the virtual switch allows VMs to use and share from VLAN1 to VLAN3.

Now I want to connect another physical ethernet port (eth1) to the same virtual switch or something similar so I can connect an external network device to it (eth1) and have the communication be able to pass through the other physical external VLAN trunk (eth0).

Typically, it would be a much easier task to do if it was on a router configuration, but I can't figure how I go about doing the same thing on Windows. The configuration for network adapters in the current network setup confused me, let alone the new network configuration.

I am trying to direct all HTTPS traffic to Nginx server where it will handle all the requests as HTTP requests to all internal servers. So far, I am able to get the template below to work for most of my servers.

server {
    listen 443 default ssl;
    ssl_certificate /etc/letencrypt/live/somesite.com/fullchain.pem;
    ssl_certificate_key /etc/letencrypt/live/somesite.com/privkey.pem;
    server_name somesite.com;

    location ^~ /Service {
      proxy_pass http://192.168.1.2;
    }

    location / {
      proxy_pass http://192.168.1.3;
    }
}

However, I am restricted to always having to match up https://somesite.com/Service with http://192.168.1.2/Service in order for the above to work.

I can't have https://somesite.com/Service to work with http://192.168.1.2/Hello.

Or that I can't direct this to other port like https://somesite.com/Service with http://192.168.1.2:3000.

For instance, when I changed the above to this:

location /Service/ {
    proxy_pass http://192.168.1.2:80/;
}

location / {
    proxy_pass http://192.168.1.3;
}

Using the following logging setup:

log_format upstreamlog '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time';
access_log /var/log/nginx/access.log upstreamlog;

This is the log I got:

[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/ HTTP/1.1 upstream_response_time 0.004 msec 1611309388.445 request_time 0.004
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/js/default.cache.a331c8c3.js HTTP/1.1 upstream_response_time 0.000 msec 1611309388.547 request_time 0.002
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/favicon.ico HTTP/1.1 upstream_response_time 0.012 msec 1611309388.757 request_time 0.012
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.3:80: GET /api/v1/oauth.json?_=1611309389573 HTTP/1.1 upstream_response_time 0.016 msec 1611309388.771 request_time 0.017

It can be seen that from the log that the first three fetches are correct. The fourth one is wrong. No further request was made afterward. After tracing a bit more, I realize that 192.168.1.2 already has a Nginx server running and processing PHP pages using FastCGI. I don't know if that makes a difference or not.

So I tried using rewrite in combination of what I have above, but I ran into a Page Not Found. I presume that it doesn't seem to work for HTTPS maybe? Thus, it led me to asking the question of how to configure Nginx to reverse proxy with URL rewrite and HTTPS externally.

I am trying to configure Nginx on one server to route to a default GitLab installation on another server (192.168.1.3) through reverse proxy such that GitLab would work at the path http://myserver/gitlab, https://myserver/gitlab, http://192.168.1.3, and https://192.168.1.3. However, I think I ran into trouble since the server with GitLab also use Nginx as its own reverse proxy. Thus, I am not sure how to configure Nginx on both servers for GitLab to work properly.

Here is the current Nginx's configuration on the main Nginx server:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    server_name myserver;

    location / {
        proxy_set_header HOST $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass $scheme://192.168.1.4;
    }

    location ~/gitlab/(.*)$ {
        proxy_set_header HOST $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass $scheme://192.168.1.3/$1;
    }
}

Here is the default Nginx's configuration on the GitLab server:

upstream gitlab {
    server unix:/home/git/gitlab/tmp/sockets/gitlab.socket fail_timeout=0;
}

upstream gitlab-workhorse {
    server unix:/home/git/gitlab/tmp/sockets/gitlab-workhorse.socket fail_timeout=0;
}

server {
    listen 0.0.0.0:80;
    include /etc/nginx/include/gitlab-proxy;
}

server {
    listen 0.0.0.0:443 ssl;
    include /etc/nginx/include/ssl;
    include /etc/nginx/include/gitlab-proxy;
}

Here is what is on /etc/nginx/include/gitlab-proxy:

root /home/git/gitlab/public;

access_log /var/log/nginx/gitlab.access.log;
error_log /var/log/nginx/gitlab.error.log;

location / {
    try_files $uri $uri/index.html $uri.html @gitlab;
}

location @gitlab {
    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_set_header X-NginX-Proxy true;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_pass http://gitlab;
    proxy_redirect off;
    proxy_buffering off;
}

location ~ [-\/\w\.]+\.git\/ {
    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_set_header X-NginX-Proxy true;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_pass http://gitlab-workhorse;
    proxy_redirect off;
    proxy_buffering off;

    proxy_connect_timeout 300;
    proxy_read_timeout 300;
}

The host name of gitlab is addressed to 127.0.0.1 on the GitLab server.

FYI, this question is similar to the question here except that it is asking for SSL in particular. The GitLab environment GITLAB_RELATIVE_URL_ROOT is changed. It is something I don't know how to change or even want to change as I want it to be still accessible via http://192.168.1.3 and https://192.168.1.3. Also, it uses Docker container for Nginx.