0

I have Open VPN server to which I can connect from devices from the Internet but I can not connect to the VPN server from devices that are in the same network where the other end of the VPN server is connected to.

Hopefully following picture gives clearer picture what I mean about this.

Network picture

So from Laptop A the VPN works perfectly without any issues, but from Laptop B the VPN connection does not work but only thing that I can see from the server side logs is:

Sat Jul 16 13:01:25 2016 192.168.8.110:54838 TLS: Initial packet from [AF_INET]192.168.8.110:54838, sid=df0e4ebd 28b00efc
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 TLS Error: TLS handshake failed
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 SIGUSR1[soft,tls-error] received, client-instance restarting

My own estimate is that there is something in my iptables that I need to configure more, but not sure what.

iptables-save output of the "Router & VPN server":

# Generated by iptables-save v1.4.21 on Sat Jul 16 15:50:52 2016
*nat
:PREROUTING ACCEPT [30:5047]
:INPUT ACCEPT [8:564]
:OUTPUT ACCEPT [277:46054]
:POSTROUTING ACCEPT [166:38786]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Jul 16 15:50:52 2016
# Generated by iptables-save v1.4.21 on Sat Jul 16 15:50:52 2016
*filter
:INPUT DROP [353:82150]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1338:193477]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Sat Jul 16 15:50:52 2016

eth0 is connected to Local network A and eth1 to Local network B

openvpn server config is:

dev tun 
proto udp
port 1194 
ca   /etc/openvpn/easy-rsa/keys/ca.crt 
cert /etc/openvpn/easy-rsa/keys/vpn.crt
key  /etc/openvpn/easy-rsa/keys/vpn.key
dh   /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.9.0.0 255.255.255.0 

# Allow traffic between clients
client-to-client 
keepalive 10 120 
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 
cipher AES-128-CBC 
comp-lzo 
user nobody 
group nogroup 
persist-key 
persist-tun 
status /var/log/openvpn-status.log 20 
log /var/log/openvpn.log 
verb 3
topology subnet

# Makes openvpn server to advertise this network to other clients
push "route 192.168.43.0 255.255.255.0"

Also net.ipv4.ip_forward = 1 is set on server.

route -n output of the server

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.8.1     0.0.0.0         UG    202    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.43.0    0.0.0.0         255.255.255.0   U     203    0        0 eth1

Client configuration for the Laptop B: NOTE: This configuration is the same that I use for Laptop A only difference is the remote line for Laptop A (public IP).

client
dev tun
proto udp
remote 192.168.8.2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1 
cipher AES-128-CBC
comp-lzo
verb 1
#mute 20
auth-nocache 0
<ca>...</ca>
<cert>...</cert>
<key>...</key>
<tls-auth>...</tls-auth>
Sage
  • 1
  • 2

1 Answers1

0

I think your issue is with the NAT POSTROUTING rule. ANY packet leaving the eth0 interface is subject to MASQUERADE'ing, even packets originating from your OVPN server itself.

The problem comes with your OVPN Client connecting to the OVPN Server on udp/1194, and due to the MASQUERADE rule, the OVPN Server is sending its replies from a different port that the OVPN Client isn't expecting, thus the timeout.

If that rule is in place to allow LAN B access to LAN A, then perhaps the following modification is your fix:

-A POSTROUTING -s <LAN B subnet> -o eth0 -j MASQUERADE

Hope this helps.

maff1989
  • 311
  • 2
  • 7
  • Thanks for the proposal. This didn't solve the issue though, but nothing broke either. So everything still works as before, can access from outside Internet but not from network A. – Sage Jul 26 '16 at 18:35
  • Please update your question to include the output of `route -n` on your OVPN server – maff1989 Jul 26 '16 at 20:06
  • Added the route -n output to the first post. – Sage Nov 18 '16 at 09:44