there are many different solutions to secure a cassandra cluster. One of them is to enter public IPs and open the 7000/9042 port on each sever. Another one is to have everything in a private network with private IPs and connect the nodes with some kind of VPN solution. I have OPNsense with Wireguard for this, but I'm wondering if this makes any problems in production. What are you guys using to prevent attacks on public ports? Thank you so much.

I am running a **MariaDB server and an OpenVPN server** (SoftEther in this case) on an **Ubuntu 20.04 LTS** machine. On my **Raspberry Pi**, I am running a **MariaDB** server aswell. My goal is to enable a **Master-Slave-Replication of the MariaDB**, whereby the **Raspi acts as master** and the **Ubuntu server as slave** *(as described in this well-done article https://www.linuxbabe.com/mariadb/master-slave-replication-ubuntu-18-04-18-10).* Therefore, I need the Raspi to have a **static or at least known IP address** so that the slave DB-server knows where to get the data from (IP address needs to be hardcoded in config file). The tricky part is that due to the desired application of the Raspi it will be plugged in into multiple networks from time to time so that a "normal" procedure with DynDNS at a single router etc. will obviously not work sufficiently. Hence, my idea is to configure the **Raspi as a VPN client**, which automatically connects to the VPN server (which runs on the same machine as the MariaDB-slave) on startup. This way I can read the IP address of the Raspi in the VPN from the server log and use it for the SQL replication config. **Connecting the Raspi as client to the VPN server works sufficiently, *BUT* if I try to connect the MariaDB slave (server) to the MariaDB master (Raspi) by using the Raspi's IP address in the VPN (adapter tun0), the slave cannot reach the master.** How is that possible, given that the Raspi is successfully connected to the VPN server **running on the same machine** as the MariaDB slave server? Is there a **need to "connect"** the MariaDB application (on the server) into the same VPN as the MariaDB master (Raspi)? Every help is greatly appreciated.

So my organization is using VPN and Remote Desktop (RDP) for telecommuting. Due to some internal issues it has been requested of our Network staff to open ports 1433 and 1434 (SQL Server ports) to VPN traffic only so that local windows apps and SSMS can access SQL Server directly without RDP. So this is not opening up to public. My question is, is this a big security risk to open those ports to the VPN traffic? It is being debated in our organization now. I don't think it would be a big risk because a hacker would need to gain VPN access and then get AD credentials or service account credentials to access the actual SQL Server. I believe those two layers of security make this low risk not high. Additionally, we recently updated all AD passwords to require more characters (15), special char, numeric, upper, lower.

I saw a couple of questions already submitted 1 or 2 year ago, without a clear answer. I'd like to know if I can connect my private Network, or whatelse to an Azure Sql Server. Point-to-Site VPN I'd like to attach a VNET to my Azure Sql Server, Set up a Network Security Group and VPN GATEWAY and connect (with enterprise certificate or self signed) to my DB's directly from Visual Studio or Microsoft Sql Management studio.

I'm running SSMS 2019 on my laptop, connecting to 2 different SQL Servers - 2008 R2 and a SQL 2016 machine. When I'm physically in the building where the servers reside, Intellisense works great. But on days when I'm working from home, connected through VPN, Intellisense is very spotty. Usually it completely fails to work at all, but every once in a while, it'll auto-fill a database name as I type, but never a table or field name. I've tried refreshing the local cache (CTRL+Shif+R), but that hasn't helped. Any ideas? As requested below, here are the results of running Test-NetConnection "Emden" -port 1433 over VPN connecion:

PS C:\Users\cjm> Test-NetConnection "Emden" -port 1433


ComputerName     : Emden

RemoteAddress    : 192.168.10.56

RemotePort       : 1433

InterfaceAlias   : Ethernet 2

SourceAddress    : 192.168.11.46

TcpTestSucceeded : True

I am trying to establish a (logical) replica of a database on a remote site. Therefore we established a permanent VPN connection to that site where we are running two machines. One is an Ubuntu 18.10 box we use for maintenance and client operations. The other one is a Debian 9.11 which is actually running the replica Postgres 11.5 DB Host. I wasn't able to connect the master node via the SUBSCRIPTION, therefore I tried to connect via psql from the replica node to my master node. I get asked to type in the password and then the connection timesout after about a minute. When I try to connect from our maintenance box everything works fine. We double checked Firewall rules of the tunnel, pg_hba.coonf and deactivated all local firwalls, without success. Hosts are pingable and ports are open and listening. I don't have any further ideas what else could cause the client to not connect to a postgres server instance. The database is postgres 10.7, the client is 11.5. What else could cause a client connection timeout like this? EDIT: the exact error message on the client side is > psql: could not connect to server: Connection refused Is the server > running on host "" and accepting TCP/IP connections on port 5432? On the serverside the log contains nothing. The server is configured to listen on '*' and accept connections as host from 0.0.0.0/0 md5 on all databases from all users. As said, the connection from another box on the remote site is working. The working client is `psql (PostgreSQL) 10.9 (Ubuntu 10.9-0ubuntu0.18.10.1) ` The non-working client is psql (PostgreSQL) 11.5 (Debian 11.5-3.pgdg90+1) EDIT2: I reconfigured log verbosity of our postgres db server to DEBUG5...this is what I get

2020-06-18 11:32:14.310 CEST  DEBUG:  find_in_dynamic_libpath: trying "C:/Program Files/PostgreSQL/11/lib/pg_stat_statements"
2020-06-18 11:32:14.310 CEST  DEBUG:  find_in_dynamic_libpath: trying "C:/Program Files/PostgreSQL/11/lib/pg_stat_statements.dll"
2020-06-18 11:32:14.310 CEST  DEBUG:  loaded library "pg_stat_statements"
2020-06-18 11:32:14.310 CEST  LOG:  connection received: host=192.168.110.124 port=47246
2020-06-18 11:32:14.321 CEST  DEBUG:  postgres child: starting with (
2020-06-18 11:32:14.321 CEST  DEBUG:  	postgres
2020-06-18 11:32:14.321 CEST  DEBUG:  )
2020-06-18 11:32:14.321 CEST  DEBUG:  InitPostgres
2020-06-18 11:32:14.321 CEST  DEBUG:  my backend ID is 3
2020-06-18 11:32:14.322 CEST  DEBUG:  mapped win32 error code 2 to 2
2020-06-18 11:32:14.322 CEST  DEBUG:  StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
2020-06-18 11:32:14.334 CEST  DEBUG:  shmem_exit(0): 1 before_shmem_exit callbacks to make
2020-06-18 11:32:14.334 CEST  DEBUG:  shmem_exit(0): 6 on_shmem_exit callbacks to make
2020-06-18 11:32:14.334 CEST  DEBUG:  proc_exit(0): 3 callbacks to make
2020-06-18 11:32:14.334 CEST  DEBUG:  exit(0)
2020-06-18 11:32:14.334 CEST  DEBUG:  shmem_exit(-1): 0 before_shmem_exit callbacks to make
2020-06-18 11:32:14.334 CEST  DEBUG:  shmem_exit(-1): 0 on_shmem_exit callbacks to make
2020-06-18 11:32:14.334 CEST  DEBUG:  proc_exit(-1): 0 callbacks to make
2020-06-18 11:32:14.337 CEST  DEBUG:  reaping dead processes
2020-06-18 11:32:14.337 CEST  DEBUG:  server process (PID 4860) exited with exit code 0

A working connection from the same subnet (other machine) looks like this in the logs

2020-06-18 11:41:16.373 CEST  DEBUG:  forked new backend, pid=576 socket=4932
2020-06-18 11:41:16.392 CEST  DEBUG:  find_in_dynamic_libpath: trying "C:/Program Files/PostgreSQL/11/lib/pg_stat_statements"
2020-06-18 11:41:16.392 CEST  DEBUG:  find_in_dynamic_libpath: trying "C:/Program Files/PostgreSQL/11/lib/pg_stat_statements.dll"
2020-06-18 11:41:16.392 CEST  DEBUG:  loaded library "pg_stat_statements"
2020-06-18 11:41:16.392 CEST  LOG:  connection received: host=192.168.110.111 port=44920
2020-06-18 11:41:16.403 CEST  DEBUG:  postgres child: starting with (
2020-06-18 11:41:16.403 CEST  DEBUG:  	postgres
2020-06-18 11:41:16.403 CEST  DEBUG:  )
2020-06-18 11:41:16.403 CEST  DEBUG:  InitPostgres
2020-06-18 11:41:16.403 CEST  DEBUG:  my backend ID is 5
2020-06-18 11:41:16.403 CEST  DEBUG:  StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
2020-06-18 11:41:16.415 CEST  DEBUG:  received password packet
2020-06-18 11:41:16.415 CEST  LOG:  connection authorized: user=swwat database=swwat
2020-06-18 11:41:16.417 CEST  DEBUG:  CommitTransaction(1) name: unnamed; blockState: STARTED; state: INPROGRESS, xid/subid/cid: 0/1/0

I need to connect to a remote SQL Server database of a client to do some syncing and other stuff. They use a VPN connection and have provided me the VPN address, RDP to SQL Server, username and password. * VPN Address: *... * RDP to SQL Server: ..**.* : 4001 * Username: *************gonal * Password: ********** * DB name: IS_***** What I managed to do was connect with a new VPN connection I created with the VPN address, username and password that were given to me.Worked fine on a linux and a windows machine. The main issue I seem to be having is when I try establish a connection to their DB. I use DBeaver on Linux and HeidiSQL on windows. Both give me errors, see below: DBeaver (Linux): HeidiSQL (Windows): Is there something I am missing? I'm trying everything and would appreciate any help at all. Could it be a firewall issue? Thanks in advance!

I have a very simple setup. SQL Server X (2012) and SQL Server Y (2016). X has a linked server to Y using the setting "Connections will: Be made using the login's current security context". SPNs are set up, and internal users on our domain can query the linked server. I can see their connections authenticating through KERBEROS if I run this query: select session_id,net_transport,client_net_address,auth_scheme from sys.dm_exec_connections WHERE net_Transport = 'TCP' However, a few external users connect via VPN. They then shift+right click on SSMS and "run as a different user" and use their account located on our domain. They can connect to the instances separately, but hit the 'double-hop' issue like below when trying to query the linked server: Msg 18456, Level 14, State 1, Line 1 Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' If I run the above query, I can see their connections are using NTLM authentication, not KERBEROS, so that explains why credentials are not passed through. Why are being authenticated with NTLM? Is this a configuration issue with the VPN? Maybe a limitation to a VPN? **** UPDATE **** Further testing has shown that if a user connects to a machine on our network via RDP and leaves that connection open, connections from their local SSMS then seem to use KERBEROS. When the user logs off of the RDP session, new connections from SSMS then start using NTLM again. In other words, they are doing NOTHING inside the RDP session, but as long as that's open, connections from SSMS use KERBEROS. (Maybe a coincidence, but that's the best I've got now)