Openvpn can't access LAN

ramous

Hi, I tried so many times to configure openvpn on PFsense 2.1.5 but I can't reach my goal :(
I can connect through openvpn, clients can ping each others but nothing else. My network is like that

client2 (windows 7)
196.203.x.x
lan-ip:192.168.8.50 |–---------------------|
vpn-ip: 10.1.10.10 | |
| INTERNET | PFSENSE
client3 (Debian 7) | | wan: 41.242.x.x
wan:41.225.x.x [ Lan-ip:172.16.10.253 - network 172.16.10/24
lan-ip:192.168.1.8 |–---------------------|
vpn-ip: 10.1.10.6

client2 <--- ping success--> client3
but no one can ping 10.1.10.1 or 172.16.10.253 or any host in 172.16.10.0/24

the rule in openvpn interface created with wizard accept any/any:
IPv4 * * * * * * none OpenVPN Client-to-Server wizard

[b]this is the config:

server–conf
dev ovpns1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 41.242.X.X
tls-server
server 10.1.10.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 100
push "route 172.16.10.0 255.255.255.0"
push "dhcp-option DOMAIN 8.8.8.8"
push "dhcp-option DNS 10.1.10.1"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
comp-lzo
push "redirect-gateway def1"

client2–conf
dev ovpnc2
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 41.242.X.X
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote 41.242.X.X 1194
ifconfig 10.1.10.2 10.1.10.1
route 172.16.10.0 255.255.255.0
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
comp-lzo
push "route 10.1.10.0 255.255.255.0"

client2-openvpn-csc
ifconfig-push 10.1.10.6 10.1.10.5
push "redirect-gateway def1"
push "route 10.1.10.0 255.255.255.0"

client3–config
dev ovpnc3
dev-type tun
tun-ipv6
dev-node /dev/tun3
writepid /var/run/openvpn_client3.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 41.242.X.X
tls-client
client
lport 0
management /var/etc/openvpn/client3.sock unix
remote 41.242.X.X 1194
ifconfig 10.1.10.2 10.1.10.1
route 172.16.10.0 255.255.255.0
ca /var/etc/openvpn/client3.ca
cert /var/etc/openvpn/client3.cert
key /var/etc/openvpn/client3.key
comp-lzo
push "route 10.1.10.0 255.255.255.0"

client3-openvpn-csc
ifconfig-push 10.1.10.10 10.1.10.9
push "redirect-gateway def1"
push "route 10.1.10.0 255.255.255.0"

divsys

The first thing I see as slightly off is the:

push "route 10.1.10.0 255.255.255.0"

Lines in both the client and CSC config files. I would expect that as a CSC option on the server. The server pushes a route command to the client upon making a good connection. Putting it in the client config implies that the client would attempt a "push route" to the server, which isn't what your looking for from your description. That said you do seem to have inter client comms (they can ping one another) so the net affect may be benign.

Comparing your config files to a number of mine, the client side seems way more verbose than I would expect. I usually use the client export package and let it auto-create the Win installs I need. Here's an example of a working Win7 client config:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 216.xxx.xxx.xxx 9445 udp
lport 0
verify-x509-name "astone-ovpn-rdwar-srv" name
pkcs12 pfs-udp-9445-greb-lnk-1.p12
tls-auth pfs-udp-9445-greb-lnk-1-tls.key 1
ns-cert-type server
comp-lzo

All the route commands are handled by the server side of things.

On your Win7 client have you tried a "route print" from a cmd window after connecting? This will show you what routes windows knows about after connecting. You can do it before and after to see the changes made by OpenVPN.

The other place to look is the OpenVPN Status and Log files. Under Win7 watch for "add route…" commands that fail. They're commonly caused by not running the client as Administrator.

The other thing to watch out for is that your device on the 172.16.10/24 will actually respond to pings from a different subnet. Firewalls, anti-virus, etc. can block ping messages in an otherwise perfectly proper setup.

Can either of the clients ping 172.16.253 (the pfSense box) but nothing else?

Normally, setting up a Roadwarrior style OpenVPN link is very easy. Personally I create the certificates manually using Cert Manager, create an OpenVPN server manually, then use the Export Wizard to create a client install package you can "Run as Administrator" on a Win7 machine.
That's just my $0.02 :)

ramous

Hello, thank you for your response, I did as you recommend but nothing changed, I still connect but I can't ping internal netwaork but now I disabled two clients through the pfsense web-gui and I don't know how, when I connect with openvon client from linux client or windows client, I can ping everything but i can't connect to my clients in the internal LAN with SHH or HTTP(s).

any wan can explain to me ???

From windows client:

^C
C:\Users\TUNISIANO>ping -t 10.1.10.1

Envoi d'une requête 'Ping' 10.1.10.1 avec 32 octets de données :
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 10.1.10.1 : octets=32 temps=172 ms TTL=64
Réponse de 10.1.10.1 : octets=32 temps=166 ms TTL=64
Réponse de 10.1.10.1 : octets=32 temps=168 ms TTL=64

Statistiques Ping pour 10.1.10.1:
Paquets : envoyés = 30, reçus = 3, perdus = 27 (perte 90%),
Durée approximative des boucles en millisecondes :
Minimum = 166ms, Maximum = 172ms, Moyenne = 168ms
Ctrl+C
^C
C:\Users\TUNISIANO>ping 172.16.10.250

Envoi d'une requête 'Ping' 172.16.10.250 avec 32 octets de données :
Réponse de 172.16.10.250 : octets=32 temps=176 ms TTL=63
Réponse de 172.16.10.250 : octets=32 temps=175 ms TTL=63
Réponse de 172.16.10.250 : octets=32 temps=167 ms TTL=63

Statistiques Ping pour 172.16.10.250:
Paquets : envoyés = 3, reçus = 3, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 167ms, Maximum = 176ms, Moyenne = 172ms
Ctrl+C
^C
C:\Users\TUNISIANO>

From Linux Client:

root@debian:~#
root@debian:~# ping 172.16.10.253
PING 172.16.10.253 (172.16.10.253) 56(84) bytes of data.
64 bytes from 172.16.10.253: icmp_req=1 ttl=64 time=175 ms
64 bytes from 172.16.10.253: icmp_req=2 ttl=64 time=175 ms
64 bytes from 172.16.10.253: icmp_req=3 ttl=64 time=178 ms
64 bytes from 172.16.10.253: icmp_req=4 ttl=64 time=167 ms
^C
–- 172.16.10.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 167.067/174.161/178.368/4.264 ms
root@debian:~# ssh 172.16.10.250

^C
root@debian:~#

divsys

Well, your last post shows:

From windows client:

….
C:\Users\TUNISIANO>ping 172.16.10.250

Envoi d'une requête 'Ping' 172.16.10.250 avec 32 octets de données :
Réponse de 172.16.10.250 : octets=32 temps=176 ms TTL=63
Réponse de 172.16.10.250 : octets=32 temps=175 ms TTL=63
Réponse de 172.16.10.250 : octets=32 temps=167 ms TTL=63

Statistiques Ping pour 172.16.10.250:
Paquets : envoyés = 3, reçus = 3, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 167ms, Maximum = 176ms, Moyenne = 172ms
....

From Linux Client:

root@debian:~#
root@debian:~# ping 172.16.10.253
PING 172.16.10.253 (172.16.10.253) 56(84) bytes of data.
64 bytes from 172.16.10.253: icmp_req=1 ttl=64 time=175 ms
64 bytes from 172.16.10.253: icmp_req=2 ttl=64 time=175 ms
64 bytes from 172.16.10.253: icmp_req=3 ttl=64 time=178 ms
64 bytes from 172.16.10.253: icmp_req=4 ttl=64 time=167 ms
^C
--- 172.16.10.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 167.067/174.161/178.368/4.264 ms
root@debian:~# ssh 172.16.10.250

root@debian:~#

Which leads me to believe the Windows client is connecting fine, it can ping 172.16.10.250 properly. It should be able to connect to anything available on the 172.16.10.x subnet

The Linux client can reach the router (172.16.10.253) but you don't try to ping 172.16.10.250, you try a ssh instead (which took too long so you aborted it?)

Make sure there's no firewall running on the Linux client and try a ping to 172.16.10.250 from the Linux machine. If the ping works, your OpenVPN setup is 99% correct. If the ping doesn't work, then I would create a new certificate and OpenVPN config just for the Linux client and try to connect again.

ramous

well, what I can't understand is; why it works only if I disable clients from pfsense gui !! and if I activate them I can just see my vpn clients.
in this exemple and I use the same configuration, agenthex and agentansi (disabled ) connect successfully and ping my internal network, but it's not the case for agentonsa which is connected but can ping only vpn clients.

I would like to share print screen, to show you better my problem, but when I attach files I receive " 500 Internal Server Error ".

OpenVPN: Client

Disabled Protocol Server Description

YES UDP 41.X.X.X:1194 agenthex
YES UDP 41.X.X.X:1194 agentansi
NO UDP 41.X.X.X:1194 agentonsa

:-\ :-\ :-\

marvosa

I apologize if this has already been explained… I just skimmed over the responses, but OP:

Can you elaborate on your situation and/or provide a new network map that shows what's actually happening here? Because your original network map suggests that you have a road warrior setup with two connected clients, but then your config files suggest that there are either 3 PFsense boxes connected via site-to-site or there's one PFsense box with 1 server and 2 client entries making outgoing connections. Please clarify your setup.
On your server config, it looks like you are providing a "DNS Default Domain", this should be the name of your domain not an IP. This all assumes you even have a domain on your LAN, if not, remove it.

ramous

thank you for your response;

I use client-to-site architecture, so I have just one pfsense box and more than 10 clients but as an example I wrote just 2.
the clients are from different cities.

Clients | Site

for the dhcp-option DOMAIN I have already removed it.

so the current server config is:

dev ovpns1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 41.X.X.X
tls-server
server 10.1.10.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 100
push "route 172.16.10.0 255.255.255.0"
push "dhcp-option DNS 10.1.10.1"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
comp-lzo
push "redirect-gateway def1"

windows client config:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 41.X.X.X 1194 udp
lport 0
verify-x509-name "www.onsa.ng" name
pkcs12 agentansi.p12
ns-cert-type server
comp-lzo
verb 5

Linux client config:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 41.X.X.X 1194 udp
lport 0
tls-remote www.onsa.ng
pkcs12 agenthex.p12
ns-cert-type server
comp-lzo

Something else; since I disabled all the clients they are no config files and certificates for them under /var/etc/openvpn in the pfsense box and it's the only way I found it to reach my LAN through the vpn tunnel.

I know there's something wrong in my configuration but I can't find the solution.

divsys

I think there's a basic misunderstanding here:

well, what I can't understand is; why it works only if I disable clients from pfsense gui !! and if I activate them I can just see my vpn clients.
in this exemple and I use the same configuration, agenthex and agentansi (disabled ) connect successfully and ping my internal network, but it's not the case for agentonsa which is connected but can ping only vpn clients.

I would like to share print screen, to show you better my problem, but when I attach files I receive " 500 Internal Server Error ".

OpenVPN: Client

Disabled Protocol Server Description

YES UDP 41.X.X.X:1194 agenthex
YES UDP 41.X.X.X:1194 agentansi
NO UDP 41.X.X.X:1194 agentonsa

The diagram you posted earlier shows a central pfSense box controlling LAN 172.16.10.0/24.
You also showed two different clients, one PC based and on Linux based, connecting to the pfSense box via OpenVPN.

In order to make this scenario work, you need only 3 pieces.

An OpenVPN SERVER running on the pfSense box
A Windows compatible OpenVPN client running on the Windows box.
A Linux compatible client running on the Linux box.

That's it.
There is no need for any OpenVPN client on the pfSense box.
The OpenVPN server on pfSense sits and watches on port 1194 for clients attempting to connect.
The clients on each machine try to connect to the server IP address on port 1194 to get a connection.

The reason it only works when you disable the other "clients" is 1) they're conflicting with the pfSense Server and trying to use the same port (1194) and 2) THEY'RE NOT NEEDED TO MAKE THIS WORK! (sorry for the rant :) )

Seriously, I think you've actually got this working, it's just simpler than you think.