Cannot access network connected to OpenVPN server
1
The VPN server (Linux) is behind a router. I want to connect from an external network to my VPN server and access devices in the server’s local network (and the server itself).
The local network’s address range is 192.168.178.0/24
I forwarded some ports to my VPN server, too: 1194, 80, 21, 443, 1723
!!I deleted previous information because body limit was reached!!
EDIT 4: Complete list of current settings:
This is my server config:
port 1194
proto udp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/VPNServer.crt
key /etc/openvpn/easy-rsa/keys/VPNServer.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 192.168.178.1"
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 3
My client config looks like this.
port 1194
client
dev tap
proto udp
remote mydyndns
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
My interface configuration for the server looks like this:
auto lo
iface lo inet loopback
allow-hotplug eth0
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
And my rc.local
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
And my sysctl net.ipv4.ip_forward output is net.ipv4.ip_forward = 1
My client log output is as followed:
Fri Sep 12 13:03:58 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 7 2014
Fri Sep 12 13:03:58 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
Enter Management Password:
Fri Sep 12 13:03:58 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:58 2014 Need hold release from management interface, waiting...
Fri Sep 12 13:03:59 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'state on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'log all on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold off'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold release'
Fri Sep 12 13:03:59 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Sep 12 13:03:59 2014 MANAGEMENT: >STATE:1410519839,RESOLVE,,,
Fri Sep 12 13:04:00 2014 UDPv4 link local: [undef]
Fri Sep 12 13:04:00 2014 UDPv4 link remote: [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,WAIT,,,
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,AUTH,,,
Fri Sep 12 13:04:00 2014 TLS: Initial packet from [AF_INET]86.103.178.165:1194, sid=bebc894c 68e04336
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=1, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:02 2014 VERIFY OK: nsCertType=SERVER
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=0, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 13:04:05 2014 [j0chn.spdns.de] Peer Connection Initiated with [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:06 2014 MANAGEMENT: >STATE:1410519846,GET_CONFIG,,,
Fri Sep 12 13:04:08 2014 SENT CONTROL [j0chn.spdns.de]: 'PUSH_REQUEST' (status=1)
Fri Sep 12 13:04:08 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 192.168.178.1,route-gateway 192.168.178.1,ping 10,ping-restart 120,ifconfig 192.168.178.112 255.255.255.0'
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route-related options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 12 13:04:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Sep 12 13:04:08 2014 MANAGEMENT: >STATE:1410519848,ASSIGN_IP,,192.168.178.112,
Fri Sep 12 13:04:08 2014 open_tun, tt->ipv6=0
Fri Sep 12 13:04:08 2014 TAP-WIN32 device [Ethernet 2] opened: \.Global{4DD19686-B673-493E-99DB-23F3D1AF7239}.tap
Fri Sep 12 13:04:08 2014 TAP-Windows Driver Version 9.21
Fri Sep 12 13:04:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.178.112/255.255.255.0 on interface {4DD19686-B673-493E-99DB-23F3D1AF7239} [DHCP-serv: 192.168.178.0, lease-time: 31536000]
Fri Sep 12 13:04:08 2014 Successful ARP Flush on interface [25] {4DD19686-B673-493E-99DB-23F3D1AF7239}
Fri Sep 12 13:04:13 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 86.103.178.165 MASK 255.255.255.255 192.168.42.129
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 192.168.42.129 MASK 255.255.255.255 192.168.42.129 IF 24
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 Initialization Sequence Completed
Fri Sep 12 13:04:13 2014 MANAGEMENT: >STATE:1410519853,CONNECTED,SUCCESS,192.168.178.112,86.103.178.165
Edit 5:
The new server log.
Fri Sep 12 17:15:07 2014 MULTI: multi_create_instance called
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Re-using SSL/TLS context
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 LZO compression initialized
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 TLS: Initial packet from [AF_INET]109.47.193.65:62284, sid=c07bdc21 48d01394
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/ema$
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddres$
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 [j0chns] Peer Connection Initiated with [AF_INET]109.47.193.65:62284
Fri Sep 12 17:15:09 2014 j0chns/109.47.193.65:62284 MULTI_sva: pool returned IPv4=192.168.178.111, IPv6=bccd:800:8ced:200:14c2:700:$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 send_push_reply(): safe_cap=960
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/109.47.193.65:62284
Fri Sep 12 17:18:14 2014 MULTI: multi_create_instance called
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Re-using SSL/TLS context
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 LZO compression initialized
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 TLS: Initial packet from [AF_INET]86.103.178.165:57350, sid=25abeaaa 58473451
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/em$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddre$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 [j0chns] Peer Connection Initiated with [AF_INET]86.103.178.165:57350
Fri Sep 12 17:18:14 2014 j0chns/86.103.178.165:57350 MULTI_sva: pool returned IPv4=192.168.178.112, IPv6=bccd:800:8ced:200:14c2:700$
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 send_push_reply(): safe_cap=960
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gatewa$
Fri Sep 12 17:18:18 2014 j0chns/86.103.178.165:57350 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/86.103.178.165:57350
And another edit:
I increased the verbose level from 3 to 9 and got new information:
Sat Sep 13 17:36:11 2014 us=76111 TLS State Error: No TLS state for client [AF_INET]86.103.202.242:55140, opcode=6
Sat Sep 13 17:36:11 2014 us=76308 GET INST BY REAL: 86.103.202.242:55140 [failed]
Maybe this can help!?
networking vpn openvpn
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
|
show 3 more comments
1
The VPN server (Linux) is behind a router. I want to connect from an external network to my VPN server and access devices in the server’s local network (and the server itself).
The local network’s address range is 192.168.178.0/24
I forwarded some ports to my VPN server, too: 1194, 80, 21, 443, 1723
!!I deleted previous information because body limit was reached!!
EDIT 4: Complete list of current settings:
This is my server config:
port 1194
proto udp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/VPNServer.crt
key /etc/openvpn/easy-rsa/keys/VPNServer.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 192.168.178.1"
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 3
My client config looks like this.
port 1194
client
dev tap
proto udp
remote mydyndns
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
My interface configuration for the server looks like this:
auto lo
iface lo inet loopback
allow-hotplug eth0
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
And my rc.local
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
And my sysctl net.ipv4.ip_forward output is net.ipv4.ip_forward = 1
My client log output is as followed:
Fri Sep 12 13:03:58 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 7 2014
Fri Sep 12 13:03:58 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
Enter Management Password:
Fri Sep 12 13:03:58 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:58 2014 Need hold release from management interface, waiting...
Fri Sep 12 13:03:59 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'state on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'log all on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold off'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold release'
Fri Sep 12 13:03:59 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Sep 12 13:03:59 2014 MANAGEMENT: >STATE:1410519839,RESOLVE,,,
Fri Sep 12 13:04:00 2014 UDPv4 link local: [undef]
Fri Sep 12 13:04:00 2014 UDPv4 link remote: [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,WAIT,,,
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,AUTH,,,
Fri Sep 12 13:04:00 2014 TLS: Initial packet from [AF_INET]86.103.178.165:1194, sid=bebc894c 68e04336
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=1, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:02 2014 VERIFY OK: nsCertType=SERVER
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=0, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 13:04:05 2014 [j0chn.spdns.de] Peer Connection Initiated with [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:06 2014 MANAGEMENT: >STATE:1410519846,GET_CONFIG,,,
Fri Sep 12 13:04:08 2014 SENT CONTROL [j0chn.spdns.de]: 'PUSH_REQUEST' (status=1)
Fri Sep 12 13:04:08 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 192.168.178.1,route-gateway 192.168.178.1,ping 10,ping-restart 120,ifconfig 192.168.178.112 255.255.255.0'
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route-related options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 12 13:04:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Sep 12 13:04:08 2014 MANAGEMENT: >STATE:1410519848,ASSIGN_IP,,192.168.178.112,
Fri Sep 12 13:04:08 2014 open_tun, tt->ipv6=0
Fri Sep 12 13:04:08 2014 TAP-WIN32 device [Ethernet 2] opened: \.Global{4DD19686-B673-493E-99DB-23F3D1AF7239}.tap
Fri Sep 12 13:04:08 2014 TAP-Windows Driver Version 9.21
Fri Sep 12 13:04:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.178.112/255.255.255.0 on interface {4DD19686-B673-493E-99DB-23F3D1AF7239} [DHCP-serv: 192.168.178.0, lease-time: 31536000]
Fri Sep 12 13:04:08 2014 Successful ARP Flush on interface [25] {4DD19686-B673-493E-99DB-23F3D1AF7239}
Fri Sep 12 13:04:13 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 86.103.178.165 MASK 255.255.255.255 192.168.42.129
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 192.168.42.129 MASK 255.255.255.255 192.168.42.129 IF 24
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 Initialization Sequence Completed
Fri Sep 12 13:04:13 2014 MANAGEMENT: >STATE:1410519853,CONNECTED,SUCCESS,192.168.178.112,86.103.178.165
Edit 5:
The new server log.
Fri Sep 12 17:15:07 2014 MULTI: multi_create_instance called
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Re-using SSL/TLS context
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 LZO compression initialized
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 TLS: Initial packet from [AF_INET]109.47.193.65:62284, sid=c07bdc21 48d01394
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/ema$
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddres$
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 [j0chns] Peer Connection Initiated with [AF_INET]109.47.193.65:62284
Fri Sep 12 17:15:09 2014 j0chns/109.47.193.65:62284 MULTI_sva: pool returned IPv4=192.168.178.111, IPv6=bccd:800:8ced:200:14c2:700:$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 send_push_reply(): safe_cap=960
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/109.47.193.65:62284
Fri Sep 12 17:18:14 2014 MULTI: multi_create_instance called
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Re-using SSL/TLS context
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 LZO compression initialized
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 TLS: Initial packet from [AF_INET]86.103.178.165:57350, sid=25abeaaa 58473451
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/em$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddre$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 [j0chns] Peer Connection Initiated with [AF_INET]86.103.178.165:57350
Fri Sep 12 17:18:14 2014 j0chns/86.103.178.165:57350 MULTI_sva: pool returned IPv4=192.168.178.112, IPv6=bccd:800:8ced:200:14c2:700$
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 send_push_reply(): safe_cap=960
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gatewa$
Fri Sep 12 17:18:18 2014 j0chns/86.103.178.165:57350 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/86.103.178.165:57350
And another edit:
I increased the verbose level from 3 to 9 and got new information:
Sat Sep 13 17:36:11 2014 us=76111 TLS State Error: No TLS state for client [AF_INET]86.103.202.242:55140, opcode=6
Sat Sep 13 17:36:11 2014 us=76308 GET INST BY REAL: 86.103.202.242:55140 [failed]
Maybe this can help!?
networking vpn openvpn
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output ofsysctl net.ipv4.ip_forward; which Linux distribution you’re using
– Daniel B
Sep 9 '14 at 19:54
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03
|
show 3 more comments
1
1
1
The VPN server (Linux) is behind a router. I want to connect from an external network to my VPN server and access devices in the server’s local network (and the server itself).
The local network’s address range is 192.168.178.0/24
I forwarded some ports to my VPN server, too: 1194, 80, 21, 443, 1723
!!I deleted previous information because body limit was reached!!
EDIT 4: Complete list of current settings:
This is my server config:
port 1194
proto udp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/VPNServer.crt
key /etc/openvpn/easy-rsa/keys/VPNServer.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 192.168.178.1"
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 3
My client config looks like this.
port 1194
client
dev tap
proto udp
remote mydyndns
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
My interface configuration for the server looks like this:
auto lo
iface lo inet loopback
allow-hotplug eth0
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
And my rc.local
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
And my sysctl net.ipv4.ip_forward output is net.ipv4.ip_forward = 1
My client log output is as followed:
Fri Sep 12 13:03:58 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 7 2014
Fri Sep 12 13:03:58 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
Enter Management Password:
Fri Sep 12 13:03:58 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:58 2014 Need hold release from management interface, waiting...
Fri Sep 12 13:03:59 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'state on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'log all on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold off'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold release'
Fri Sep 12 13:03:59 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Sep 12 13:03:59 2014 MANAGEMENT: >STATE:1410519839,RESOLVE,,,
Fri Sep 12 13:04:00 2014 UDPv4 link local: [undef]
Fri Sep 12 13:04:00 2014 UDPv4 link remote: [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,WAIT,,,
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,AUTH,,,
Fri Sep 12 13:04:00 2014 TLS: Initial packet from [AF_INET]86.103.178.165:1194, sid=bebc894c 68e04336
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=1, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:02 2014 VERIFY OK: nsCertType=SERVER
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=0, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 13:04:05 2014 [j0chn.spdns.de] Peer Connection Initiated with [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:06 2014 MANAGEMENT: >STATE:1410519846,GET_CONFIG,,,
Fri Sep 12 13:04:08 2014 SENT CONTROL [j0chn.spdns.de]: 'PUSH_REQUEST' (status=1)
Fri Sep 12 13:04:08 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 192.168.178.1,route-gateway 192.168.178.1,ping 10,ping-restart 120,ifconfig 192.168.178.112 255.255.255.0'
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route-related options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 12 13:04:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Sep 12 13:04:08 2014 MANAGEMENT: >STATE:1410519848,ASSIGN_IP,,192.168.178.112,
Fri Sep 12 13:04:08 2014 open_tun, tt->ipv6=0
Fri Sep 12 13:04:08 2014 TAP-WIN32 device [Ethernet 2] opened: \.Global{4DD19686-B673-493E-99DB-23F3D1AF7239}.tap
Fri Sep 12 13:04:08 2014 TAP-Windows Driver Version 9.21
Fri Sep 12 13:04:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.178.112/255.255.255.0 on interface {4DD19686-B673-493E-99DB-23F3D1AF7239} [DHCP-serv: 192.168.178.0, lease-time: 31536000]
Fri Sep 12 13:04:08 2014 Successful ARP Flush on interface [25] {4DD19686-B673-493E-99DB-23F3D1AF7239}
Fri Sep 12 13:04:13 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 86.103.178.165 MASK 255.255.255.255 192.168.42.129
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 192.168.42.129 MASK 255.255.255.255 192.168.42.129 IF 24
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 Initialization Sequence Completed
Fri Sep 12 13:04:13 2014 MANAGEMENT: >STATE:1410519853,CONNECTED,SUCCESS,192.168.178.112,86.103.178.165
Edit 5:
The new server log.
Fri Sep 12 17:15:07 2014 MULTI: multi_create_instance called
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Re-using SSL/TLS context
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 LZO compression initialized
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 TLS: Initial packet from [AF_INET]109.47.193.65:62284, sid=c07bdc21 48d01394
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/ema$
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddres$
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 [j0chns] Peer Connection Initiated with [AF_INET]109.47.193.65:62284
Fri Sep 12 17:15:09 2014 j0chns/109.47.193.65:62284 MULTI_sva: pool returned IPv4=192.168.178.111, IPv6=bccd:800:8ced:200:14c2:700:$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 send_push_reply(): safe_cap=960
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/109.47.193.65:62284
Fri Sep 12 17:18:14 2014 MULTI: multi_create_instance called
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Re-using SSL/TLS context
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 LZO compression initialized
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 TLS: Initial packet from [AF_INET]86.103.178.165:57350, sid=25abeaaa 58473451
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/em$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddre$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 [j0chns] Peer Connection Initiated with [AF_INET]86.103.178.165:57350
Fri Sep 12 17:18:14 2014 j0chns/86.103.178.165:57350 MULTI_sva: pool returned IPv4=192.168.178.112, IPv6=bccd:800:8ced:200:14c2:700$
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 send_push_reply(): safe_cap=960
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gatewa$
Fri Sep 12 17:18:18 2014 j0chns/86.103.178.165:57350 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/86.103.178.165:57350
And another edit:
I increased the verbose level from 3 to 9 and got new information:
Sat Sep 13 17:36:11 2014 us=76111 TLS State Error: No TLS state for client [AF_INET]86.103.202.242:55140, opcode=6
Sat Sep 13 17:36:11 2014 us=76308 GET INST BY REAL: 86.103.202.242:55140 [failed]
Maybe this can help!?
networking vpn openvpn
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
The VPN server (Linux) is behind a router. I want to connect from an external network to my VPN server and access devices in the server’s local network (and the server itself).
The local network’s address range is 192.168.178.0/24
I forwarded some ports to my VPN server, too: 1194, 80, 21, 443, 1723
!!I deleted previous information because body limit was reached!!
EDIT 4: Complete list of current settings:
This is my server config:
port 1194
proto udp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/VPNServer.crt
key /etc/openvpn/easy-rsa/keys/VPNServer.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 192.168.178.1"
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 3
My client config looks like this.
port 1194
client
dev tap
proto udp
remote mydyndns
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
My interface configuration for the server looks like this:
auto lo
iface lo inet loopback
allow-hotplug eth0
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
And my rc.local
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
And my sysctl net.ipv4.ip_forward output is net.ipv4.ip_forward = 1
My client log output is as followed:
Fri Sep 12 13:03:58 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 7 2014
Fri Sep 12 13:03:58 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
Enter Management Password:
Fri Sep 12 13:03:58 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:58 2014 Need hold release from management interface, waiting...
Fri Sep 12 13:03:59 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'state on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'log all on'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold off'
Fri Sep 12 13:03:59 2014 MANAGEMENT: CMD 'hold release'
Fri Sep 12 13:03:59 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Sep 12 13:03:59 2014 MANAGEMENT: >STATE:1410519839,RESOLVE,,,
Fri Sep 12 13:04:00 2014 UDPv4 link local: [undef]
Fri Sep 12 13:04:00 2014 UDPv4 link remote: [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,WAIT,,,
Fri Sep 12 13:04:00 2014 MANAGEMENT: >STATE:1410519840,AUTH,,,
Fri Sep 12 13:04:00 2014 TLS: Initial packet from [AF_INET]86.103.178.165:1194, sid=bebc894c 68e04336
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=1, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:02 2014 VERIFY OK: nsCertType=SERVER
Fri Sep 12 13:04:02 2014 VERIFY OK: depth=0, C=DE, ST=SH, L=Kiel, OU=changeme, CN=j0chn.spdns.de, name=changeme, emailAddress=matthias_j_fischer@hotmail.de
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 13:04:05 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 13:04:05 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 13:04:05 2014 [j0chn.spdns.de] Peer Connection Initiated with [AF_INET]86.103.178.165:1194
Fri Sep 12 13:04:06 2014 MANAGEMENT: >STATE:1410519846,GET_CONFIG,,,
Fri Sep 12 13:04:08 2014 SENT CONTROL [j0chn.spdns.de]: 'PUSH_REQUEST' (status=1)
Fri Sep 12 13:04:08 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 192.168.178.1,route-gateway 192.168.178.1,ping 10,ping-restart 120,ifconfig 192.168.178.112 255.255.255.0'
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: route-related options modified
Fri Sep 12 13:04:08 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 12 13:04:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Sep 12 13:04:08 2014 MANAGEMENT: >STATE:1410519848,ASSIGN_IP,,192.168.178.112,
Fri Sep 12 13:04:08 2014 open_tun, tt->ipv6=0
Fri Sep 12 13:04:08 2014 TAP-WIN32 device [Ethernet 2] opened: \.Global{4DD19686-B673-493E-99DB-23F3D1AF7239}.tap
Fri Sep 12 13:04:08 2014 TAP-Windows Driver Version 9.21
Fri Sep 12 13:04:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.178.112/255.255.255.0 on interface {4DD19686-B673-493E-99DB-23F3D1AF7239} [DHCP-serv: 192.168.178.0, lease-time: 31536000]
Fri Sep 12 13:04:08 2014 Successful ARP Flush on interface [25] {4DD19686-B673-493E-99DB-23F3D1AF7239}
Fri Sep 12 13:04:13 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 86.103.178.165 MASK 255.255.255.255 192.168.42.129
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 192.168.42.129 MASK 255.255.255.255 192.168.42.129 IF 24
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 C:WINDOWSsystem32route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.178.1
Fri Sep 12 13:04:13 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Fri Sep 12 13:04:13 2014 Route addition via IPAPI succeeded [adaptive]
Fri Sep 12 13:04:13 2014 Initialization Sequence Completed
Fri Sep 12 13:04:13 2014 MANAGEMENT: >STATE:1410519853,CONNECTED,SUCCESS,192.168.178.112,86.103.178.165
Edit 5:
The new server log.
Fri Sep 12 17:15:07 2014 MULTI: multi_create_instance called
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Re-using SSL/TLS context
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 LZO compression initialized
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:15:07 2014 109.47.193.65:62284 TLS: Initial packet from [AF_INET]109.47.193.65:62284, sid=c07bdc21 48d01394
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/ema$
Fri Sep 12 17:15:08 2014 109.47.193.65:62284 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddres$
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:15:09 2014 109.47.193.65:62284 [j0chns] Peer Connection Initiated with [AF_INET]109.47.193.65:62284
Fri Sep 12 17:15:09 2014 j0chns/109.47.193.65:62284 MULTI_sva: pool returned IPv4=192.168.178.111, IPv6=bccd:800:8ced:200:14c2:700:$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 send_push_reply(): safe_cap=960
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gateway$
Fri Sep 12 17:15:11 2014 j0chns/109.47.193.65:62284 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/109.47.193.65:62284
Fri Sep 12 17:18:14 2014 MULTI: multi_create_instance called
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Re-using SSL/TLS context
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 LZO compression initialized
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Local Options hash (VER=V4): 'f7df56b8'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Expected Remote Options hash (VER=V4): 'd79ca330'
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 TLS: Initial packet from [AF_INET]86.103.178.165:57350, sid=25abeaaa 58473451
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=1, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chn.spdns.de/name=changeme/em$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 VERIFY OK: depth=0, /C=DE/ST=SH/L=Kiel/OU=changeme/CN=j0chns/name=changeme/emailAddre$
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 12 17:18:14 2014 86.103.178.165:57350 [j0chns] Peer Connection Initiated with [AF_INET]86.103.178.165:57350
Fri Sep 12 17:18:14 2014 j0chns/86.103.178.165:57350 MULTI_sva: pool returned IPv4=192.168.178.112, IPv6=bccd:800:8ced:200:14c2:700$
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 PUSH: Received control message: 'PUSH_REQUEST'
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 send_push_reply(): safe_cap=960
Fri Sep 12 17:18:17 2014 j0chns/86.103.178.165:57350 SENT CONTROL [j0chns]: 'PUSH_REPLY,route-gateway 192.168.178.1,redirect-gatewa$
Fri Sep 12 17:18:18 2014 j0chns/86.103.178.165:57350 MULTI: Learn: 00:ff:4d:d1:96:86 -> j0chns/86.103.178.165:57350
And another edit:
I increased the verbose level from 3 to 9 and got new information:
Sat Sep 13 17:36:11 2014 us=76111 TLS State Error: No TLS state for client [AF_INET]86.103.202.242:55140, opcode=6
Sat Sep 13 17:36:11 2014 us=76308 GET INST BY REAL: 86.103.202.242:55140 [failed]
Maybe this can help!?
networking vpn openvpn
networking vpn openvpn
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
edited Sep 13 '14 at 16:10
j0chn
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
asked Sep 9 '14 at 19:27
j0chnj0chn
10616
10616
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output ofsysctl net.ipv4.ip_forward; which Linux distribution you’re using
– Daniel B
Sep 9 '14 at 19:54
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03
|
show 3 more comments
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output ofsysctl net.ipv4.ip_forward; which Linux distribution you’re using
– Daniel B
Sep 9 '14 at 19:54
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output of
sysctl net.ipv4.ip_forward; which Linux distribution you’re using– Daniel B
Sep 9 '14 at 19:54
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output of
sysctl net.ipv4.ip_forward; which Linux distribution you’re using– Daniel B
Sep 9 '14 at 19:54
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03
|
show 3 more comments
1 Answer
1
active
oldest
votes
0
Your client file is missing both the IP address of the remote server, and the indication of the port on which to contact the server itself. In other words, you are missing:
port 1194
remote IP.ADDRESS.OF.SERVER
Also, I do not understand why you are using the subnet 10.8.0.0/24 for your clients. You have already chosen a tap interface for a bridged OpenVPN (good choice, makes access to all pcs on the LAN much easier at no extra cost), so there is no reason to use a distinct subnet. Your server file should contain the statements
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.1"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DNS 208.67.222.222"
The first statement instructs the server to draw IP addresses for remote clients in the pool 192.168.178.(111-120). Just make sure the DHCP server on your LAN is not trying to use these addresses itself, in which case you will have to choose a different pool for the OpenVPN pool. The other statements are obvious.
Lastly, there should be no need to define separate routes, apart from the above statements.
EDIT:
you need to change iptables and make a bridge on the server.
Change your /etc/netorking/interfaces file to look like this:
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Reboot the server for this to take effect. Check that the server is correctly connected to the internet. Then change the iptables rules as follows:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat –A POSTROUTING -o br0 -j MASQUERADE
Start the OpenVPN server, and add the tap0 interface to the bridge,
sudo brctl addif br0 tap0
Now try connecting from the client.
EDIT 2:
This iptables rule
iptables -t nat -A POSTROUTING -j MASQUERADE
should be
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Also, please use tap0 instead of tap in the server conf file. Reboot and let me know, pls.
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
|
show 3 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f809423%2fcannot-access-network-connected-to-openvpn-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
Your client file is missing both the IP address of the remote server, and the indication of the port on which to contact the server itself. In other words, you are missing:
port 1194
remote IP.ADDRESS.OF.SERVER
Also, I do not understand why you are using the subnet 10.8.0.0/24 for your clients. You have already chosen a tap interface for a bridged OpenVPN (good choice, makes access to all pcs on the LAN much easier at no extra cost), so there is no reason to use a distinct subnet. Your server file should contain the statements
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.1"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DNS 208.67.222.222"
The first statement instructs the server to draw IP addresses for remote clients in the pool 192.168.178.(111-120). Just make sure the DHCP server on your LAN is not trying to use these addresses itself, in which case you will have to choose a different pool for the OpenVPN pool. The other statements are obvious.
Lastly, there should be no need to define separate routes, apart from the above statements.
EDIT:
you need to change iptables and make a bridge on the server.
Change your /etc/netorking/interfaces file to look like this:
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Reboot the server for this to take effect. Check that the server is correctly connected to the internet. Then change the iptables rules as follows:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat –A POSTROUTING -o br0 -j MASQUERADE
Start the OpenVPN server, and add the tap0 interface to the bridge,
sudo brctl addif br0 tap0
Now try connecting from the client.
EDIT 2:
This iptables rule
iptables -t nat -A POSTROUTING -j MASQUERADE
should be
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Also, please use tap0 instead of tap in the server conf file. Reboot and let me know, pls.
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
|
show 3 more comments
0
Your client file is missing both the IP address of the remote server, and the indication of the port on which to contact the server itself. In other words, you are missing:
port 1194
remote IP.ADDRESS.OF.SERVER
Also, I do not understand why you are using the subnet 10.8.0.0/24 for your clients. You have already chosen a tap interface for a bridged OpenVPN (good choice, makes access to all pcs on the LAN much easier at no extra cost), so there is no reason to use a distinct subnet. Your server file should contain the statements
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.1"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DNS 208.67.222.222"
The first statement instructs the server to draw IP addresses for remote clients in the pool 192.168.178.(111-120). Just make sure the DHCP server on your LAN is not trying to use these addresses itself, in which case you will have to choose a different pool for the OpenVPN pool. The other statements are obvious.
Lastly, there should be no need to define separate routes, apart from the above statements.
EDIT:
you need to change iptables and make a bridge on the server.
Change your /etc/netorking/interfaces file to look like this:
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Reboot the server for this to take effect. Check that the server is correctly connected to the internet. Then change the iptables rules as follows:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat –A POSTROUTING -o br0 -j MASQUERADE
Start the OpenVPN server, and add the tap0 interface to the bridge,
sudo brctl addif br0 tap0
Now try connecting from the client.
EDIT 2:
This iptables rule
iptables -t nat -A POSTROUTING -j MASQUERADE
should be
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Also, please use tap0 instead of tap in the server conf file. Reboot and let me know, pls.
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
|
show 3 more comments
0
0
0
Your client file is missing both the IP address of the remote server, and the indication of the port on which to contact the server itself. In other words, you are missing:
port 1194
remote IP.ADDRESS.OF.SERVER
Also, I do not understand why you are using the subnet 10.8.0.0/24 for your clients. You have already chosen a tap interface for a bridged OpenVPN (good choice, makes access to all pcs on the LAN much easier at no extra cost), so there is no reason to use a distinct subnet. Your server file should contain the statements
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.1"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DNS 208.67.222.222"
The first statement instructs the server to draw IP addresses for remote clients in the pool 192.168.178.(111-120). Just make sure the DHCP server on your LAN is not trying to use these addresses itself, in which case you will have to choose a different pool for the OpenVPN pool. The other statements are obvious.
Lastly, there should be no need to define separate routes, apart from the above statements.
EDIT:
you need to change iptables and make a bridge on the server.
Change your /etc/netorking/interfaces file to look like this:
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Reboot the server for this to take effect. Check that the server is correctly connected to the internet. Then change the iptables rules as follows:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat –A POSTROUTING -o br0 -j MASQUERADE
Start the OpenVPN server, and add the tap0 interface to the bridge,
sudo brctl addif br0 tap0
Now try connecting from the client.
EDIT 2:
This iptables rule
iptables -t nat -A POSTROUTING -j MASQUERADE
should be
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Also, please use tap0 instead of tap in the server conf file. Reboot and let me know, pls.
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
Your client file is missing both the IP address of the remote server, and the indication of the port on which to contact the server itself. In other words, you are missing:
port 1194
remote IP.ADDRESS.OF.SERVER
Also, I do not understand why you are using the subnet 10.8.0.0/24 for your clients. You have already chosen a tap interface for a bridged OpenVPN (good choice, makes access to all pcs on the LAN much easier at no extra cost), so there is no reason to use a distinct subnet. Your server file should contain the statements
server-bridge 192.168.178.1 255.255.255.0 192.168.178.111 192.168.178.120
push "route-gateway 192.168.178.1"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DNS 208.67.222.222"
The first statement instructs the server to draw IP addresses for remote clients in the pool 192.168.178.(111-120). Just make sure the DHCP server on your LAN is not trying to use these addresses itself, in which case you will have to choose a different pool for the OpenVPN pool. The other statements are obvious.
Lastly, there should be no need to define separate routes, apart from the above statements.
EDIT:
you need to change iptables and make a bridge on the server.
Change your /etc/netorking/interfaces file to look like this:
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.178.123
netmask 255.255.255.0
gateway 192.168.178.1
bridge_ports eth0
dns-nameservers 192.168.178.1
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Reboot the server for this to take effect. Check that the server is correctly connected to the internet. Then change the iptables rules as follows:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat –A POSTROUTING -o br0 -j MASQUERADE
Start the OpenVPN server, and add the tap0 interface to the bridge,
sudo brctl addif br0 tap0
Now try connecting from the client.
EDIT 2:
This iptables rule
iptables -t nat -A POSTROUTING -j MASQUERADE
should be
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Also, please use tap0 instead of tap in the server conf file. Reboot and let me know, pls.
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
edited Sep 12 '14 at 13:26
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
answered Sep 10 '14 at 14:19
MariusMatutiaeMariusMatutiae
38.5k953100
38.5k953100
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
|
show 3 more comments
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
Thanks for your help. But it still does not work. The log is in my 2nd edit.
– j0chn
Sep 10 '14 at 16:10
1
1
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
And where did he say he wants to redirect the internet? ;)
– Daniel B
Sep 10 '14 at 16:58
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
Is there any special setting I have to do on client side?
– j0chn
Sep 12 '14 at 5:19
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
@j0chn Do you have other iptables rule, besides the above?
– MariusMatutiae
Sep 12 '14 at 6:08
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
No, I don't have any other rules. But I changed my SD Card now and have to reinstall my Raspberry. I will redo all configurations told above and will tell you if it works then.
– j0chn
Sep 12 '14 at 9:52
|
show 3 more comments
draft saved
draft discarded
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f809423%2fcannot-access-network-connected-to-openvpn-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I rewrote your post, please check if all the facts are accurate. Please also add the following information: Output of
sysctl net.ipv4.ip_forward; which Linux distribution you’re using– Daniel B
Sep 9 '14 at 19:54
Oh yeah, and static route you added to your router is pointless because IPTables is configured to reject these packets. ;) I just noticed I forgot to ask about the now second-to-last paragraph: Can you please describe in greater detail how the client behaves? Can it still access the internet? Can it ping 192.168.178.123 when VPN-connected? Does the VPN log contain a success message about adding the route?
– Daniel B
Sep 9 '14 at 21:36
In 2nd edit I post my log after setting up openvpn with MariusMatutiaes suggestion.
– j0chn
Sep 10 '14 at 16:11
Well, you made some progress: the last line of your log says: MANAGEMENT: >STATE:1410365314,CONNECTED,SUCCESS,192.168.178.111,86.103.189.21, so the client thinks everything is fine. Have you modified the iptables rules on the server, to reflect the change of subnet, from 10.8.0.0 to 192.168.178.111?
– MariusMatutiae
Sep 10 '14 at 17:51
Please see my EDIT
– MariusMatutiae
Sep 10 '14 at 18:03