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
Related
This is how I run the rabbitMQ image:
docker run -d --restart always --hostname host-rabbit --name cg-rabbit -p 5029:5672 -p 5020:15672 -e RABBITMQ_DEFAULT_VHOST=sample_vhost -e RABBITMQ_DEFAULT_USER=sampleuser -e RABBITMQ_DEFAULT_PASS=samplepass rabbitmq:3-management
Now in netstat -nltp:
ubuntu#infra:~$ netstat -nltp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::5020 :::* LISTEN -
tcp6 0 0 :::5029 :::* LISTEN -
I'm not sure why I see tcp6 when docker exposes ports to host and if it makes issues!
Now when I telnet from within the server I can see that port is open:
ubuntu#infra:~$ telnet MY-SERVER-IP-ADDRESS 5029
Trying MY-SERVER-IP-ADDRESS...
Connected to MY-SERVER-IP-ADDRESS.
Escape character is '^]'.
^]
telnet> Connection closed.
But in my machine when I try to telnet (or from another server):
$ telnet MY-SERVER-IP-ADDRESS 5020
Trying MY-SERVER-IP-ADDRESS...
^C
iptables -L reports:
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5020
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5029
ACCEPT tcp -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:amqp
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:15672
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
It is good to note that I have installed a redis server in server (non-docker) and I am able to telnet to it form outside.
EDIT-1:
sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere !localhost/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:15672
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:amqp
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
DNAT tcp -- anywhere anywhere tcp dpt:15672 to:172.17.0.2:15672
DNAT tcp -- anywhere anywhere tcp dpt:amqp to:172.17.0.2:5672
EDIT-2:
Docker configuration:
ubuntu#infra:~$ sudo cat /var/snap/docker/796/config/daemon.json
{
"log-level": "error",
"storage-driver": "overlay2"
}
This is really odd. By flushing the NAT in iptables everything works as expected:
iptables -t nat -F
My nat before flushing:
ubuntu#infra:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere !localhost/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:15672
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:amqp
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
DNAT tcp -- anywhere anywhere tcp dpt:15672 to:172.17.0.2:15672
DNAT tcp -- anywhere anywhere tcp dpt:amqp to:172.17.0.2:5672
And now after flushing everything is gone:
ubuntu#infra:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
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
Chain DOCKER (0 references)
target prot opt source destination
NOTE: by restarting docker via sudo snap restart docker net rules are back again and I had to flush NATs again!
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
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.
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?
I am trying to disable access to IP 1.2.3.4 for all users except for members of group "neta". This is a new group which I created only for this matter.
iptables -I OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner ! --gid-owner neta -j REJECT
This disables access to 1.2.3.4 for all users, even if they are member of group "neta".
I have an user xx and he is a member of groups xx (main group) and neta. If I change the rule to:
iptables -I OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner \! --gid-owner xx -j REJECT
everyone except user xx is not able to access 1.2.3.4.
I added root to this group xx:
usermod -a -G xx root
but root was still not able to access this IP.If I add main user's group (root, xx) to the rule everything works as expected.
I tried spliting it in two rules just to be sure (and log rejected):
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner --gid-owner neta -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m limit --limit 2/s --limit-burst 10 -j LOG
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -j REJECT
but there is no difference. Everything is being rejected.
There are no other iptables rules.
root#vm1:~# iptables -nvL
Chain INPUT (policy ACCEPT 19 packets, 1420 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 10 packets, 1720 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 1.2.3.4 owner GID match 1001
0 0 LOG tcp -- * eth0 0.0.0.0/0 1.2.3.4 limit: avg 2/sec burst 10 LOG flags 0 level 4
0 0 REJECT tcp -- * eth0 0.0.0.0/0 1.2.3.4 reject-with icmp-port-unreachable
I want to be able to (dis)allow access to this IP by adding/removing users from this "neta" group instead of adding iptables rules for every user.
Ok, to be honest I know to little about linux and iptables to be sure about my theory, but since I wanted to do the same for a VPN here we go.
I assume that the match is done using the process from which the packets originate from and that a linux process doesn't get all groups of a user assigned but instead a process runs with one uid and one gid.
That means that you have to execute the command explicitly using this specific group, or else the command/process is executed using the default group of the user.
Writing this I had an idea to see whether there is such possibility.
I restricted access to a certain IP range using the group VPN. This never worked. Now I tested with the following command and it works:
sg vpn -c "ssh user#10.15.1.1"
So I hope my theory was correct.
Old post, but chiming in since I have run into this exact problem in Ubuntu 16.04.3 LTS server.
Ubuntu's implementation of iptables extensions through netfilter examines the owner of the current network packet, and queries only the primary group id of that user. It doesn't dig deeper and get all the group memberships. Only the primary group is compared to the --gid-owner value. It doesn't look any further.
What the OP was trying to accomplish would work if he/she changed the primary/default user group of all relevant usernames to "neta". Those users would then be captured by the rule.
To use a supplementary group you need to add the --suppl-groups flag to your iptables command
From man page:
--suppl-groups
Causes group(s) specified with --gid-owner to be also checked in the supplementary groups of a process.