So, this is my setup: I have computer A and a computer B, both with Ubuntu 20.01. Each computer has openssh-server working just fine. Yesterday, I used rsync to copy a large file from A to B, and it didn't seem to have any issue (it was the first time rsync was used). Today, I tried to connect via SSH from B to A and I had a "No route to host" error. Then I tried to connect via SSH from A to B and "No route to host" happened again. Then, on each computer I did a: ssh user@127.0.0.1 and none gave me any issue. Then, I did a: ssh -T git@github.com on both computers and both were successful. Then, I did an: nmap -Pn -p22 192.168.xx.yy on both computers trying to connect to the other, the results are: PORT STATE SERVICE nmap tested in A with IP of A: 22/tcp filtered ssh nmap tested in A with IP of B: 22/tcp open ssh nmap tested in B with IP of A: 22/tcp filtered ssh nmap tested in B with IP of B: 22/tcp open ssh What really bugs me out is that yesterday, before using rsync, the ssh connection was working just fine. The file was copied successfully, and both computers have been restarted since, so I don't know if there's some file that was corrupted or something like that. I'm not even sure if the rsync is what caused the issue. Just to be sure, in computer A, I did a: sudo lsof -i -P -n | grep 192.168 And the only IP address that I see is the one from A. Not sure if this might help, but I only used one rsync command, and is the one that follows: rsync -rvz -e 'ssh -p XXXX' --progress /PATH/TO/SOURCE/FILE user@192.168.xx.yy:/PATH/TO/DESTINATION/FILE EDIT: I don't think the path is the issue, since I ran rsync from a dicerctory in /home/user, but for disclosure, the actual rsnc command was: rsync -rvz -e 'ssh -p 2222' --progress ./someDB.sql user@192.168.0.70:/home/user/DBs And as for the absolute path of where I ran the command, it was: /home/user/DB/

With ufw disable on remote postgres system i'm able to connect from my local system However, the connection does not work when I ufw enable as shown below: C:\Users\HOME>telnet 80.240.24.195 5432 Connecting To 80.240.24.195...Could not open connection to the host, on port 5432: Connect failed Below is my postgres configuration at the time of restart. cat /etc/postgresql/12/main/postgresql.conf # - Connection Settings - listen_addresses = '*' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost'; use '*' for all # (change requires restart) port = 5432 # (change requires restart) max_connections = 100 # (change requires restart) #superuser_reserved_connections = 3 # (change requires restart) unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories cat /etc/postgresql/12/main/pg_hba.conf # Database administrative login by Unix domain socket local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 host all all 0.0.0.0/0 md5 # IPv6 local connections: host all all ::1/128 md5 telnet works when tried from the postgres host itself, but then I try to make the connection from my local laptop it fails. root@DKERP:/# ufw status numbered Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN Anywhere [ 2] 8069 ALLOW IN Anywhere [ 3] 443/tcp DENY IN Anywhere [ 4] 443 DENY IN Anywhere [ 5] 80/tcp DENY IN Anywhere [ 6] 80,443,5432/tcp DENY IN Anywhere [ 7] 80 DENY IN Anywhere [ 8] 4433/tcp DENY IN Anywhere [ 9] 5432/tcp ALLOW IN Anywhere 22 (v6) ALLOW IN Anywhere (v6) 8069 (v6) ALLOW IN Anywhere (v6) 443/tcp (v6) DENY IN Anywhere (v6) 443 (v6) DENY IN Anywhere (v6) 80/tcp (v6) DENY IN Anywhere (v6) 80,443,5432/tcp (v6) DENY IN Anywhere (v6) 80 (v6) DENY IN Anywhere (v6) 4433/tcp (v6) DENY IN Anywhere (v6) 5432/tcp (v6) ALLOW IN Anywhere (v6) Can you please suggest what needs to be further done to get the postgres to connect to work from my local laptop?

- With RHEL 8.8 currently, and RHEL 9.x, the latest NFS version is 4.2. - When NFS 4 was introduced, it did away with a few things in NFS3 one of which was multiple port numbers: - *NFS4 **mandates** all traffic now exclusively TCP **uses the single well known port 2049**.* - https://www.snia.org/sites/default/files/SNIA_An_Overview_of_NFSv4-3_0.pdf - you can find more mostly reputable articles stating the same thing. - I have confirmed this by having only TCP 2049 open in firewalld for NFS 4.1 in RHEL 7.9; it does not use port 111 or any other unless you change the default configurations of /etc/nfs.conf or /etc/sysconfig/nfs. And in fact when I did get rdma working (over port 20049) that the rdma protocol specifically bypasses firewalld, an inherent aspect of why rdma saves cpy cycles and is faster i suppose. > The NFS **insecure** option in /etc/exports sets the server to listen to a request from any port on the client. Changing it to 'secure' (default) makes sure that the server will listen to only requests originating from ports 1-1024 of the client. Thus an unauthorized user on the client is kept from starting an NFS dialogue. For reference : https://security.stackexchange.com/questions/246527/what-is-insecure-about-the-insecure-option-of-nfs-exports The default is **secure** vs *insecure* when doing an NFS4 export if neither is mentioned in /etc/exports. With **security rules** it is oftentimes stated *The NFS server must not have the insecure file locking option enabled.*. First with the /etc/exports secure option in play, be default, the *will only operate on secure ports less than 1024` seems to be completely not true since NFS4 runs on port 2049. The number 2049 is greater than 1024... what am I missing? With regards to RDMA which by convention happens on port 20049 there seems to be a little missed fact that one needs to **explicitly** state the **insecure** option in /etc/exports if a mount -o rdma is to be used otherwise the mount always happens as proto=tcp and not proto=rdma with no indication why. I did validate that, using MLNX_OFED_LINUX-23.04-1.1.3.0-rhel8.8-x86_64.iso installed in place of the Redhat InfiniBand Support packages that a mount -o rdma,port=1023 does work with a mount on the client side showing proto=rdma. **However** one must also do (with MLNX only?) an echo rdma 20049 > /proc/sys/nfsd/portlist. Or in the case with secure export an *echo rdma 1023*. Does anyone know how/why these values are not in /proc/sys/nfsd/portlist in the first place and why I must do them manually ? **And then what is the correct way to put those numbers there**, so that after boot my /etc/fstab nfs mounting of my data folder as rdma happens successfully? The MLNX instructional pdf falls short. I have been banging my head against the wall getting RDMA to work, there seems to be a lot of shortcoming with NFS overall, and I have a paid for cluster mgr software that has RDMA placeholders for configuration, but all mounts are always proto=tcp. So if anyone can provide any information on anything described would be helpful, I will + any answer. **Also:** I will end up doing /etc/exports with secure and choose some port number 1023 and below to satisfy security rules. How do I choose a proper number in that range? As ron nobody my understanding was I should never use port numbers below 1000 or 1024 for stuff I set up? **update:** it appears that the /etc/exports parameter of *secure* or *insecure* is inconsequential. What matters is having rdma 20049 in /proc/fs/nfsd/portlist on the nfsserver. With that, or any number, it appears to work with the *secure* exportfs.

I'm trying to dockerize a rpc application I made using C lang and rpcgen, I have the byte executable and everything, I tried a lot of docker os image like ubuntu 22.04/ debian and so on, the executable run and the rpc service run too but there's no listening to port 111 that can enable me to get the UDP and TCP port numbers so I can connect my external client to it, any solution? this is the Dockerfile

FROM ubuntu:22.04

WORKDIR /app

COPY . .

RUN apt-get update && \
    apt-get install -y rpcbind && \
    mkdir -p /run/sendsigs.omit.d && \
    chmod +x run.sh

CMD rpcbind && ./run.sh

this is the shell script

#!/bin/sh
./server &
rpcinfo -p

yet I get `rpc-server| No remote programs registered. rpc-server exited with code 0`

I have installed the KDE Connect application on my desktop and on my phone [Xiaomi Redmi 3S Prime]. However the desktop application would not detect my phone and vice versa. I have checked the ports. They are open. There is no firewall installed. I have also tried adding my PC manually by entering the IP address in the Android App and that did not work. I also tried restarting the kdeconnectd daemon, but that also didn't work. EDIT: Here are the things that I have tried. 1. Check if the kdeconnectd daemon is running. 2. Check if I have the ports blocked and if firewall is enabled. 3. Check if KDE Connect is listening on the port. Please help with all the solutions you can. PS. It might seem like a duplicate but I have tried almost all the solutions out there but none of it seems to work for me. Hence, I am here.

[Named ports can be defined in /etc/services](https://unix.stackexchange.com/questions/611406/how-to-assign-a-friendly-name-to-a-port-number-in-linux) but none of curl, http.Get() (Go) or reqwest::get() (Rust) [respects the definition](https://stackoverflow.com/questions/18182076/ssh-port-issuecurl-6-couldnt-resolve-host-127-0-0-1ssh) . While it is possible to manually lookup the integer port number by the service name via [libc's getservbyname()](https://linux.die.net/man/3/getservbyname) or [getent command](https://stackoverflow.com/a/8497399/8776746) , it would be great if there is any way to define named ports which are transparently (automatically) resolved by any network applications such as curl. Is there any such way?

I have disabled a USB (2.0) port on a production Linux system with this command:

echo 1 > /sys/bus/usb/devices/usb2/2-1/2-1.8/port/disable

It successfully disabled the 8th USB port on hub #1. Devices plugged in this port are no longer enumerated. But now, I want to re-enable it (without resetting the controller or rebooting the system). I could not find the solution in documentation for the kernel. The folder 2-1.8 is gone, and also command echo "2-1.8" > /sys/bus/usb/devices/usb2/2-1/subsystem/drivers/usb/bind fails with No such device error.
How can I re-enable it?

In Linux, if I enable net.ipv4.tcp_l3mdev_accept with sysctl utility, I can reach all TCP ports listening at 0.0.0.0/[::] if there is a reachable IP inside a VRF. The listening point can belong to a process outside the VRF (not bound with SO_BINDTODEVICE or running with "ip vrf exec \"). > sudo sysctl -w net.ipv4.tcp_l3mdev_accept=1 Inside a VRF, is there a way to block all TCP listening points belonging to processes running outside the VRF and have net.ipv4.tcp_l3mdev_accept enabled at same time?

I've seen this has an answer while there is no data being transmitted, but what about for when it is? Is this something I need to look into or am I fine? This was taken off my Nethogs

In my InfoSec course assignment, we were given the task to analyze the different communications that were displayed when we run the command netstat -an. While analyzing I saw the following communication: TCP [::]:135 [::]:0 LISTENING, which I have not really encountered before and do not know how to interpret. I searched for the answer on the web and couldn't find much information related to my specific question.

I want to reserve certain port numbers on a VM host for use by the VMs themselves. Is there a mechanism by which the host can exclude those ports from being allocated to processes not related to the VMs by looking them up in a list or checking them against preset rules? If some other software requests a port without checking with the host it should find it blocked as though it is in use. The VMs themselves are also software running on the host so I guess they could be blocked themselves, so it should be more of a system reserving certain ports for some particular utilities used by the VM manager to allocate those ports. It could also be relevant for docker containers. Update: The VMs share the IP address with the host, and some incoming ports need to be forwarded to services running on the VMs or the containers. I don't know if the outgoing ports need to be reserved unless they will interfere with the listening services. I guess the iptables rules can distinguish them, or not.

I'm working on a private Debian package that deploys a service which binds to port 80.

[Service]
ExecStart=/usr/bin/foo --port 80

I realize almost every other package which serves HTTP is also going to try to bind to port 80. apache2.service for example, comes with this site enabled by default:

# /etc/apache2/sites-enabled/000-default.conf

    ...

Options: 1. Let the programs race for the bind(). Fastest wins 2. Add Before=apache2.service to foo.service 3. Add Conflicts=apache2 to debian/control With files, we often use update-alternatives to let packages negotiate (or users configure) what package gets to supply a specific file, but do we have anything similar for ports? ---- If I have apache2 installed and bound to port 80, then apt install nginx, I get:

$ sudo apt install nginx-light
...
Setting up nginx-common (1.18.0-6.1+deb11u3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
Setting up nginx-light (1.18.0-6.1+deb11u3) ...
Not attempting to start NGINX, port 80 is already in use.

So perhaps the solution is to enabling a service conditionally based on whether the port is already bound during installation (though nginx is now enabled, so I presume apache2 and nginx will race on next boot).

I got a problem with an openvpn server on dedicated hosting vm - the problem is that the packets do not pass to the client after the connection is established (although during the establishment of that connection, they do reach client succesfully). Port forwarding is enabled, ufw is configured - and no matter what there are no packets to client Any advice what should I check? Versions

Ubuntu 22.04.2

OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 27 2024
library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10

Client logs

2024-09-23 13:19:38.246711 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:63081
...
2024-09-23 13:19:43.685541 Initialization Sequence Completed
2024-09-23 13:19:43.685563 MANAGEMENT: >STATE:1727086783,CONNECTED,SUCCESS,10.8.0.6,5.180.55.57,1194,,
2024-09-23 13:19:43.685610 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_ACK_V1 kid=0 [ ]
2024-09-23 13:19:43.685684 UDP READ  from [AF_INET]5.180.55.57:1194: P_CONTROL_V1 kid=0 [ ] pid=2662 DATA len=280
2024-09-23 13:19:43.685709 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_ACK_V1 kid=0 [ ]
2024-09-23 13:19:43.685737 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685756 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685774 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685835 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685855 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685874 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685892 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685920 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685937 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685952 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685973 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.685989 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.686006 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.686025 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87
2024-09-23 13:19:43.686042 UDP WRITE  to [AF_INET]5.180.55.57:1194: P_DATA_V2 kid=0 DATA len=87

That is it, no UDP_READ ever at all. And after timeout client start to reconnecting. Server logs

Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: MULTI: multi_create_instance called
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Re-using SSL/TLS context
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=358 DATA len=40
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 TLS: Initial packet from [AF_INET]client_ip:57537, sid=277076f6 1cd8249e
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=358 DATA len=52
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=870 DATA len=317
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=614 DATA len=1114
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=870 DATA len=1102
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=1126 DATA len=299
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=1638 DATA len=1114
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=1894 DATA len=1102
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 VERIFY OK: depth=1, CN=Easy-RSA CA
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 VERIFY OK: depth=0, CN=vt_client
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=1638 DATA len=210
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=2150 DATA len=532
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_VER=2.4.12
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_PLAT=mac
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_PROTO=2
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_NCP=2
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_LZ4=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_LZ4v2=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_LZO=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_COMP_STUB=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_COMP_STUBv2=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_TCPNL=1
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5971_4.0.1__build_5971)"
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=1894 DATA len=280
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: client_ip:57537 [vt_client] Peer Connection Initiated with [AF_INET]client_ip:57537
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 MULTI: Learn: 10.8.0.6 -> vt_client/client_ip:57537
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 MULTI: primary virtual IP for vt_client/client_ip:57537: 10.8.0.6
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 23 12:19:38 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 23 12:19:39 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=2918 DATA len=75
Sep 23 12:19:39 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 PUSH: Received control message: 'PUSH_REQUEST'
Sep 23 12:19:39 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 SENT CONTROL [vt_client]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Sep 23 12:19:39 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:39 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=2406 DATA len=280
Sep 23 12:19:42 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_CONTROL_V1 kid=0 [ ] pid=2662 DATA len=280
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_ACK_V1 kid=0 [ ]
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 READ  from [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=87
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN WRITE 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN READ 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=83
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN READ 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=83
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN READ 
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 UDPv4 WRITE  to [AF_INET]client_ip:57537: P_DATA_V2 kid=0 DATA len=83
Sep 23 12:19:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 TUN READ 

...
Sep 23 12:23:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 [vt_client] Inactivity timeout (--ping-restart), restarting
Sep 23 12:23:43 vm3028493.stark-industries.solutions ovpn-udp: vt_client/client_ip:57537 SIGUSR1[soft,ping-restart] received, client-instance restarting

Server conf

username@vm3028493:/etc/openvpn$ cat udp.conf 
port 1194
proto udp

dev tun

ca ca.crt
cert server.crt
key server.key
dh none

# crl-verify crl.pem

server 10.8.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

duplicate-cn
keepalive 10 120

tls-crypt ta.key
cipher AES-256-GCM
auth SHA256

user nobody
group nogroup

persist-key
persist-tun

verb 6

explicit-exit-notify 1


username@vm3028493:/etc/openvpn$ cat tcp.conf 
port 443
proto tcp

dev tun

ca ca.crt
cert server.crt
key server.key  
dh none

server 10.9.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

duplicate-cn
keepalive 10 120

tls-crypt ta.key
cipher AES-256-GCM
auth SHA256

user nobody
group nogroup

persist-key
persist-tun

verb 3

Client conf

client
dev tun

remote host_white_ip 1194 udp
remote host_white_ip 443 tcp

resolv-retry infinite

nobind

persist-key
persist-tun

remote-cert-tls server
cipher AES-256-GCM
auth SHA256
key-direction 1

verb 6

...


...


...


...

pf is active (output is for demo only, there is same string in /etc/sysctl.conf)

username@vm3028493:/etc/openvpn$ sudo sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

ufw

username@vm3028493:/etc/openvpn$ sudo ufw status verbose 
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), allow (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
1194/udp                   ALLOW IN    Anywhere                  
443/tcp                    ALLOW IN    Anywhere                  
2022/tcp                   ALLOW IN    Anywhere                  
1194/udp (v6)              ALLOW IN    Anywhere (v6)             
443/tcp (v6)               ALLOW IN    Anywhere (v6)             
2022/tcp (v6)              ALLOW IN    Anywhere (v6)     


username@vm3028493:/etc/openvpn$ sudo cat /etc/ufw/before.rules 
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/8 -o ens3 -j MASQUERADE
-A POSTROUTING -s 10.9.0.0/8 -o ens3 -j MASQUERADE
COMMIT
# END OPENVPN RULES


# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Here is what’s routing table looks like:

sysop@vm3028493:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         5.180.55.1      0.0.0.0         UG        0 0          0 ens3
5.180.55.0      0.0.0.0         255.255.255.0   U         0 0          0 ens3
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun1
10.9.0.0        10.9.0.2        255.255.255.0   UG        0 0          0 tun0
10.9.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0

I wrote a simple telegram bot and it works great without conflicting with my firewall. But my question is this, in the firewall I have ports 80 and 443 allowed for my site, but when I write a TCP socket in Python that should work through port 443 or port 80, the OS tells me that I need to run the program from the user's root, but if I start the bot, then the OS does not swear at all about the rights and the bot works quietly. If I still decide to run a socket on port 443 or 80, then the OS replies that these ports are busy. So, please explain to me why the telegram bot does not conflict with processes and ports? My server is Ubuntu 22.04

I'm currently trying to install Arch Linux on a new disk, but I'm encountering a networking issue that I can't seem to resolve. I'm getting a "Destination Port Unreachable" error when I try to ping external addresses (e.g., Google DNS at 8.8.8.8). Here are the details: - **Connection Type**: Wired Ethernet - **Router**: I can successfully ping my router (192.168.0.1) from the Arch Linux environment. - **Current OS**: Live USB with Arch Linux - **Other OS**: On the same machine, everything works perfectly on Windows. ### Background: I previously had Kali Linux installed on this disk, but the internet suddenly stopped working entirely from one day to the next. I backed up the necessary data and formatted the disk. Now, I'm trying to install a new system, and this is the situation. ### Additional Notes: - **No NAT Issues**: Other devices, including the same machine on Windows, connect to the internet without problems. - **No DHCP Issues**: IP address and default gateway are correctly assigned. ### Current Symptoms: - Can't ping external IP addresses (e.g., 8.8.8.8) - "Destination Port Unreachable". - Local network (router ping) works fine. ### What i have tried so far: 1. **Interface Status**: Checked and the interface enp3s0 is UP and has an IP assigned (192.168.0.111). 2. **Routing Table**:

default via 192.168.0.1 dev enp3s0
    default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.111 metric 100
    192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.111 metric 100
    192.168.0.1 dev enp3s0 proto dhcp scope link src 192.168.0.111 metric 100

3. **DNS Configuration**: Manually set DNS in /etc/resolv.conf:

nameserver 8.8.8.8
    nameserver 8.8.4.4

Restarted systemd-resolved but still no luck. 4. **Log Checks**: Reviewed journalctl -xe but didn't find any network-related errors. 5. **Firewall**: No firewall rules blocking traffic (iptables -L shows no blocks). 6. **Attempted Diagnostics**: - Tried traceroute but can't install it without internet. - Can't use arp as the command isn't available in the live environment. Any advice on what I might be missing or what additional steps I should take would be greatly appreciated. Thanks in advance.

On my Linux machine, I have a UDP server listening on IP 192.168.1.5 port 44123 and an application that sends UDP packets to other devices on the same network, in particular to devices with IP 192.168.1.x port 44124 I want to create an iptables rule to forward all UDP packets from the application to the UDP Server but having difficulties doing so. Example: I wish that the application sends a UDP packet to 192.168.1.10 port 44124 and that it is forwarded to the UDP Server listening on 192.168.1.5 port 44123. Can someone help please? Note: I have set net.ipv4.ip_forward=1

I tried to transfer a file from an HPC system to a remote CentOS system using the following command line:

scp /ANKAN/data/abc.pdf maslab-3@192.168.69.231:/data/ANKAN

But I am getting the following error:

ssh: connect to host 192.168.69.231 port 22: Connection refused lost connection

I tried all the commands given in the How to Fix the SSH “Connection Refused” Error webpage at phoenixNAP knowledge base, but nothing worked! For your information, the port number of the HPC (from where I am transferring the files) is 4422. But when I gave the following command in the remote CentOS system:

sudo grep Port /etc/ssh/sshd_config

the following lines are printed:

Port 22
#GatewayPorts no

So, I tried using the following command lines:

scp -P 4422 /ANKAN/data/abc.pdf maslab-3@192.168.69.231:/data/ANKAN

and

scp -P 22 /ANKAN/data/abc.pdf maslab-3@192.168.69.231:/data/ANKAN

But I am getting the same errors.  I can't figure out what is going wrong here.  Can anyone please help me to solve this issue?

I'm setting up an OpenVPN access server and I continuously get the error "connection refused" on my client(s).  So I decided to start debugging from the beginning (the server) and tried

telnet 127.0.0.1 2194

The result:

openvpn_as_test_1:~$ telnet 127.0.0.1 2194
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

So this means the issue is on the server.  So I checked if the port was open in ufw with sudo ufw status and noticed the port was not allowed by the firewall.  After adding the port with ufw allow 2194/udp (and ufw allow 2194/tcp even when this is needed), I checked ufw status again, and this was the result:

Status: active

To                         Action      From
--                         ------      ----
2194/udp                   ALLOW       Anywhere
2194/tcp                   ALLOW       Anywhere
22                         ALLOW       Anywhere
2194/udp (v6)              ALLOW       Anywhere (v6)
2194/tcp (v6)              ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)

The port is allowed by the internal firewall, so I tried telnet 127.0.0.1 2194 again and guess what: still connection refused:

openvpn_as_test_1:~$ telnet 127.0.0.1 2194
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Ok, what else could be the problem?  Maybe telnet does not work properly, so I tried:

openvpn_as_test_1:~$ telnet 127.0.0.1 22
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

Great, telnet is working fine, so… let's check netstat to see if we listen to port 2194:

openvpn_as_test_1:~$ netstat -al | grep "LISTEN"
tcp        0      0 0.0.0.0:943             0.0.0.0:*               LISTEN
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:https           0.0.0.0:*               LISTEN
tcp        0      0 localhost:904           0.0.0.0:*               LISTEN
tcp        0      0 localhost:905           0.0.0.0:*               LISTEN
tcp        0      0 localhost:906           0.0.0.0:*               LISTEN
tcp        0      0 localhost:907           0.0.0.0:*               LISTEN
tcp        0      0 localhost:908           0.0.0.0:*               LISTEN
tcp        0      0 localhost:909           0.0.0.0:*               LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
unix  2      [ ACC ]     SEQPACKET  LISTENING     13660    /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     22260    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     22264    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     22265    /run/user/1000/snapd-session-agent.socket
unix  2      [ ACC ]     STREAM     LISTENING     22266    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     22267    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     22268    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     22269    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     13568    /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     13578    /run/systemd/journal/stdout
unix  2      [ ACC ]     STREAM     LISTENING     16810    /run/uuidd/request
unix  2      [ ACC ]     STREAM     LISTENING     16816    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     16828    /run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING     16830    /run/snapd.socket
unix  2      [ ACC ]     STREAM     LISTENING     16832    /run/snapd-snap.socket
unix  2      [ ACC ]     STREAM     LISTENING     13662    /run/lvm/lvmpolld.socket
unix  2      [ ACC ]     STREAM     LISTENING     13839    /run/lvm/lvmetad.socket
unix  2      [ ACC ]     STREAM     LISTENING     16861    /var/lib/lxd/unix.socket
unix  2      [ ACC ]     STREAM     LISTENING     20300    /usr/local/openvpn_as/etc/sock/sagent
unix  2      [ ACC ]     STREAM     LISTENING     20303    /usr/local/openvpn_as/etc/sock/sagent.localroot
unix  2      [ ACC ]     STREAM     LISTENING     20304    /usr/local/openvpn_as/etc/sock/sagent.api
unix  2      [ ACC ]     STREAM     LISTENING     16865    @ISCSIADM_ABSTRACT_NAMESPACE

Port 2194 is not listed here. Ok, now I have no idea how to continue. Where is my issue?

I have been running an Apache web server for numerous years and have been using ports as a medium to serve requests. Recently, I began using Unix sockets to serve MySQL requests. The function of Unix sockets I understand as: - the 'socket' is a specific location in memory, represented as a system file with extension '.sock'. When used as a communication medium, a process can write to (or read from) this file to communicate with another process. What, and where, are system ports ? Do files exist in the filesystem that facilitate the same communication purpose as Unix sockets ? If I wish to interface with, say, port 80, and interpret a HTTP request, how could I achieve that ?

Im trying to use my raspberry pi as a wireguard server. When connecting my raspberry Pi to my router via Ethernet cable, my router assigns pi to ip **192.168.1.35** Ive confirmed the pi receives internet access via running **ping www.startpage.com** when SSH'd into the pi However, once I run **wg-quick up wg0** on the pi, I lose all internet access. Ping via ssh no longer works. To regain internet access I have to run **wg-quick down wg0** Wireguard is doing somthing to break my internet My Raspberry Pi wireguard config file sudo nano /etc/wireguard/wg0.conf [Interface] PrivateKey = PI_PRIVATE_KEY Address = 192.168.1.100 ListenPort = 51820 [Peer] PublicKey = CLIENT_PUBLIC_KEY AllowedIPs = 0.0.0.0/0, ::0 Client config file sudo nano /etc/wireguard/wg0.conf [Interface] PrivateKey = CLIENT_PRIVATE_KEY Address = 192.168.1.101/24 [Peer] PublicKey = PI_PUBLIC_KEY AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = PI/ROUTER_PUBLIC_IP:51820 NOTE : I have changed the AllowedIPs settings numerous times within both configs, to test different results, wg-quick up wg0 on my Pi still breaks the internet through my pi, without it, internet runs normally I notice that **wg-quick up wg0** is modifying my nft ruleset when **up** sudo nft list ruleset table ip wg-quick-wg0 { chain preraw { type filter hook prerouting priority raw; policy accept; iifname != "wg0" ip daddr 192.168.2.100 fib saddr type != local drop } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } when wg0 interface is down, these rules dont exist So maybe something in these rules is blocking internet access within the pi **Problem Elimination** 1. 192.168.1.100 isnt used by any other device on router 2. uncommenting **net.ipv4.ip_forward=1** in **/etc/sysctl.conf** makes no difference, the exact problem remains the same, *inet access* with ip4 commented or uncommented with wg0 down, no *inet access* with ip4 commented or uncommented with wg0 up 3. the wireguard client-side is irrelevant at this stage 4. The problem isnt anything to do with wireguard private/public keys, as it throws errors when it is.