0

I am not sure exactly where the issue is here. I'm fairly sure that this is some NAT or iptables issue on the OpenVPN server but am lacking the networking know-how to fix the issue. The crux of the issue is that my OpenVPN server cannot ping or connect to open ports on my Windows Client. However, the Windows Client can connect to the OpenVPN server. I realize that there are some very similar questions out there but I was not able to figure out my issue with their answers.

Server config:

port 1194
proto tcp
dev tun
ca ca.crt
key server.key
cert server.crt
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.0.150"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Server ifconfig:

[root@openvpn ~]# /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:09:ED:FC
          inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: ::a00:27ff:fe09:edfc/64 Scope:Global
          inet6 addr: fe80::a00:27ff:fe09:edfc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:199562 errors:0 dropped:0 overruns:0 frame:0
          TX packets:173845 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:105179115 (100.3 MiB)  TX bytes:96774220 (92.2 MiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:5E:CB:11
          inet addr:10.0.3.15  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe5e:cb11/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1416 (1.3 KiB)

eth2      Link encap:Ethernet  HWaddr 08:00:27:9F:84:44
          inet addr:192.168.56.200  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe9f:8444/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:523 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:53923 (52.6 KiB)  TX bytes:3546 (3.4 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:878 errors:0 dropped:0 overruns:0 frame:0
          TX packets:878 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:135186 (132.0 KiB)  TX bytes:135186 (132.0 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:36245 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42614 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:4584112 (4.3 MiB)  TX bytes:22527697 (21.4 MiB)

Server iptables:

*nat
:PREROUTING ACCEPT [1647:106875]
:POSTROUTING ACCEPT [66:4385]
:OUTPUT ACCEPT [66:4385]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [162:13810]
:FORWARD ACCEPT [986:57824]
:OUTPUT ACCEPT [27147:18531930]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 1194 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -i eth0 -o tun0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -i tun0 -o eth0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -i tun0 -o eth0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT

Server routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.1        255.255.255.0   UG    0      0        0 tun0
10.0.3.0        *               255.255.255.0   U     0      0        0 eth1
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.56.0    *               255.255.255.0   U     0      0        0 eth2
link-local      *               255.255.0.0     U     1002   0        0 eth0
link-local      *               255.255.0.0     U     1003   0        0 eth1
link-local      *               255.255.0.0     U     1004   0        0 eth2
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Client config:

client
dev tun
proto tcp
remote <MY_IP> <M_PORT>
resolv-retry infinite
remote-cert-tls server
nobind
persist-key
persist-tun
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
....
-----END PRIVATE KEY-----
</key>
4
  • Once the tunnel is up, can the Windows client ping the OpenVPN server over the tunnel and get a response back? If so, then the tunnel's working both ways and it's probably a firewall problem, likely Windows's firewall.
    – DerfK
    Dec 18, 2014 at 23:19
  • Try turning the windows 7 firewall off or windows 8. Remember to turn it back on after you've re-run your server-to-client connectivity tests. Dec 19, 2014 at 0:30
  • Thanks I will turn off the firewall on the windows client ( it is windows 8) but I think I already tried this earlier with no joy. I will reply back when I have tried it and gotten results
    – Kons
    Dec 19, 2014 at 1:23
  • thanks ! Turning off the firewall on the windows client fixed the issue. What type of rule do I need to make so that connectivity can be maintained while keep the client secure with the firewall?
    – Kons
    Dec 20, 2014 at 2:22

0

You must log in to answer this question.

Browse other questions tagged .