Server not accepting request on port 9999 - linux

I am trying to deploy my socket[phpws library] on amazon EC2 instance. For this I deployed code and run socket. I have selected port 9999 for socket handshake, but it is not working.
I tried to captured request on this server by command :
sudo tcpdump -i any port 9999
Then I hit this port, I did not received any request. I thought this is because of iptables. So I checked it by command :
sudo iptables -L
But it clearly shows allow for all requests. Here is output :
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
At this point I am clueless how to move forward. Any help is gently appreciable. Looking for response.

You have to also open port 9999 in the AWS Security Group attached to the EC2 instance.

Related

Netcat server and intermittent UDP datagram loss

The client on enp4s0 (192.168.0.77) is sending short text-messages permanently to 192.168.0.1:6060. The server on 192.168.0.1 listen on 6060 via nc -ul4 --recv-only 6060
A ping (ping -s 1400 192.168.0.77) from server to client works fine. Wireshark is running on 192.168.0.1 (enp4s0) and detects that all datagrams are correct. There are no packages missing.
But netcat (as also a simple UDP-server) receives only sporadic on datagrams.
Any Idea what's going wrong?
System configuration:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# ip route
default via 192.168.77.1 dev enp0s25 proto dhcp metric 100
default via 192.168.0.1 dev enp4s0 proto static metric 101
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.1 metric 101
192.168.77.0/24 dev enp0s25 proto kernel scope link src 192.168.77.25 metric 100
192.168.100.0/24 dev virbr0 proto kernel scope link src 192.168.100.1
# uname -a
Linux nadhh 5.1.20-300.fc30.x86_64 #1 SMP Fri Jul 26 15:03:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Port redirect through iptables to kvm machine (Windows server)

I have a dedicated server Kimsufi Ks-3 with stock kernel and KVM virtualization.
I have installed windows server on a kvm guest, and I'm trying to redirect a port from host machine to the rdp windows port (3389). For do than I have used iptables with this commands:
root#ns370482:~# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.100.208:3389
root#ns370482:~# iptables -t nat -A PREROUTING -i eth0 -p udp --dport 2222 -j DNAT --to-destination 192.168.100.208:3389
192.168.100.208 is the guest Windows Server.
When I try to connect trough host machine with remmina to te private ip it works, but when I try from the public IP of the server with publicip:2222, it doesn't work.
root#ns370482:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:2222 to:192.168.100.208:3389
DNAT udp -- anywhere anywhere udp dpt:2222 to:192.168.100.208:3389
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE tcp -- anywhere anywhere tcp dpt:3389
MASQUERADE udp -- anywhere anywhere udp dpt:3389
What I'm doing wrong?

Strongswan RoadWarrior VPN-Config

I want to setup an VPN-Server for my local web traffic (iPhone/iPad/MacBook).
So far I managed to setup basic configuration with CA & Client-Cert.
For the moment my client can connect to the server and access server resources, but has no route to the internet.
The server is accessible directly via public IP (no home installation...).
What do I need to change to route all my client traffic through the VPN-Server and enable internet access for my clients?
Thanks in advance
/etc/ipsec.conf
config setup
conn rw
keyexchange=ikev1
authby=xauthrsasig
xauth=server
auto=add
#
#LEFT (SERVER)
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
leftcert=serverCert.pem
#
#RIGHT (CLIENT)
right=%any
rightsubnet=10.0.0.0/24
rightsourceip=10.0.0.0/24
rightcert=clientCert.pem
iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.0.0.1 anywhere policy match dir in pol ipsec reqid 1 proto esp
ACCEPT all -- anywhere 10.0.0.1 policy match dir out pol ipsec reqid 1 proto esp
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Found the solution!
/etc/ipsec.conf
rightsubnet=10.0.0.0/24
iptables
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
System
sysctl net.ipv4.ip_forward=1

Running Nodejs application on VPS OVH

I just rent a VPS at OVH and i'm trying to run a Nodejs application on port 1337.
The application runs correctly, when I try :
curl 0.0.0.0:1337
It gives me the code of the page (works with 127.0.0.1 too)
But when I try to connect to 176.31.184.111:1337, it doesn't work.
#root: iptables -L -v -n
Chain INPUT (policy ACCEPT 8645 packets, 592K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 7556 packets, 729K bytes)
pkts bytes target prot opt in out source destination

snmpd is not listening on port 161 on Ubuntu server

I have installed snmpd on my Ubuntu server via apt-get install snmpd snmp. Then I changed the line in /etc/default/snmpd
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 0.0.0.0'
After that, I restarted the snmpd server(/etc/init.d/snmpd restart). However, when I ran netstat -an | grep "LISTEN ", I don't see snmpd is listening on port 161.
I don't have any firewall which blocks that port.
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
User "nos" is correct; UDP bindings do not show up as "LISTEN" under "netstat". Instead, you will see a line or two like the following, showing that "snmpd" is indeed ready to receive data on UDP port 161:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:161 0.0.0.0:* 1785/snmpd
udp6 0 0 ::1:161 :::* 1785/snmpd
The "netstat" manpage has this to say about the "State" column:
The state of the socket. Since there are no states in raw mode and usually no states used in UDP, this column may be left blank.
Thus, you would not expect to see the word "LISTEN" here.
From a practical perspective, however, there is one more thing that I'd like to note. Often, the default Net-SNMP "snmpd.conf" configuration file limits incoming connections to only local processes.
Default /etc/snmp/snmpd.conf
# Listen for connections from the local system only
agentAddress udp:127.0.0.1:161
# Listen for connections on all interfaces (both IPv4 *and* IPv6)
#agentAddress udp:161,udp6:[::1]:161,tcp:161,tcp6:[::1]:161
Usually, the point of setting up "snmpd" is so that another machine can monitor it. To accomplish this, make sure that the first line is commented out and that the second line is enabled.
Looks like it is listening on 161/UDP. From the man page:
By default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. However, it is possible to modify this behaviour by specifying one or more listening addresses as arguments to snmpd. A listening address takes the form: [<transport-specifier>:]<transport-address>
Read the man page for more details

Resources