Routing issues between networks behind openvpn routers
-
Which side is server and which side is the client?
I do not see a route to 10.0.11.0/24 on the OVPN-GW side… that's likely your issue
Post the config files from both sides (e.g. server1.conf and client1.conf)
-
Hi,
sorry I forgot some information. OVPN-GW is the server and pfsense the client.
Adding the according route on the server fails with:
route add -net 10.0.11.0/24 10.0.1.10
route: writing to routing socket: Network is unreachable
add net 10.0.11.0/24: gateway 10.0.1.10: Network is unreachableThis will probably be caused by the server not being able reach the clients, as also "ping 10.0.1.10" times out. 10.0.1.10 is the client IP shown by pfsense. So I can assume this behavior is not supposed to be okay? Any ideas on this?
Thank you!
Best regards
====== server.conf ======
proto udp
port 444
dev tun0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/private/cert.cc.crt
key /etc/openvpn/private/key.key
dh /etc/openvpn/dh2048.pemserver 10.0.1.0 255.255.255.0
keepalive 10 120
comp-lzo
user openvpn
group openvpn
daemon openvpn
persist-key
persist-tuntls-auth /etc/openvpn/private/ta.key 0
cipher AES-256-CBCpush "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.2"
client-to-clientstatus /var/log/openvpn-status.log
====== client config ======
client
dev tun
proto udp
remote server 444
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3 -
Information I see (let me know if any of this is not correct:
Tunnel Network - 10.0.1.0/24
LAN1 - 10.0.0.0/24
LAN2 - 10.0.11.0/24From the above info, it looks like the following is missing:
SERVER
–--------
ifconfig 10.0.1.1 10.0.1.2
route 10.0.11.0 255.255.255.0CLIENT
ifconfig 10.0.1.2 10.0.1.1
route 10.0.0.0 255.255.255.0Also that client config... are you sure you pulled that from a PFsense box? Because if you enter the relevant info into the client section of OpenVPN... it should look similar to this:
dev ovpnc2
dev-type tun
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 WAN_IP_OF_LAN2
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote WAN_IP_OF_LAN1 1194
ifconfig 10.0.1.2 10.0.1.1
route 10.0.0.0 255.255.255.0
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
tls-auth /var/etc/openvpn/client2.tls-auth 1 -
Hey,
sorry for the delay. Didn't have any access to the system until now ….
I tried adding the routes as you suggested, but had no luck :(
And sorry for the wrong config-file; seem to have taken the wrong one ...
dev ovpnc1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.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 x.x.29.203
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote SERVER_DNS 444
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
comp-lzo
tls-auth /etc/tls.auth 1 -
You are still missing info. After you've entered everything, your config should look identical to mine with the excepttion of the WAN IP's.
-
Marvosa - This is related but unrelated…
Ubuntu doesn't route to LANs the way it should automatically the way windows does when its a client to a pfsense TUN openvpn.
This little line you mentioned earlier totally fixed a looooonnnnnnggggggg standing issue of ubuntu to make it route to LANs.
In the client file on ubuntu, near bottom placed:
route 10.0.0.0 255.255.255.0 (substituted my LAN Subnet)I haven't ever seen a good fix for this anywhere, but this is so simple. Why didn't I do earlier (pfsense needs a facepalm icon) :-[
So, you are a genius. Thank you much for the accidental unrelated help :)
keywords added for web searches:
ubuntu linux mint pfsense openvpn can't access LAN TUN client
-
Just to clarify my first post, those missing lines need to be added to your config… not added via command line after connection.
-
Yeah sure, but as I told previously I still can't get any connection …
new pfsense config
dev ovpnc1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.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 x.x.29.203
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote HOST 444
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
comp-lzo
tls-auth /etc/tls.auth 1
ifconfig 10.0.1.2 10.0.1.1
route 10.0.0.0 255.255.255.0new server config:
proto udp
port 444
dev tun0ifconfig 10.0.1.1 10.0.1.2
route 10.0.11.0 255.255.255.0ca /etc/openvpn/ca.crt
cert /etc/openvpn/private/picard.goetzinger.cc.crt
key /etc/openvpn/private/picard.goetzinger.cc.key
dh /etc/openvpn/dh2048.pemserver 10.0.1.0 255.255.255.0
keepalive 10 120
comp-lzouser openvpn
group openvpn
daemon openvpnpersist-key
persist-tuntls-auth /etc/openvpn/private/ta.key 0
cipher AES-256-CBCpush "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.2"
client-to-clientstatus /var/log/openvpn-status.log
-
Client-side looks right, although it looks like you added the lines manually to the advanced section instead of letting the system generate it ("should" work either way).
Is the tunnel established? If so, probably looking at firewall rules.
Post the firewall rule from the OpenVPN tab on PFsense.
Posting routing tables from both firewalls might help as well.
-
Sure, tunnel status has been fine, since initial setup.
Firewall rules at OpenBSD are
pass in
pass outFirewall rules at the pfsense are
Proto TCP
Source *
Port *
Destination *
Port *
Gateway *
Queue NoneRouting table at pfsense:
IPv4
Destination Gateway Flags Refs Use Mtu Netif Expire
default 85.126.x.x UGS 0 4386 1500 em1
10.0.0.0/24 10.0.1.1 UGS 0 24 1500 ovpnc1
10.0.1.0/24 10.0.1.5 UGS 0 1699 1500 ovpnc1
10.0.1.5 link#10 UH 0 0 1500 ovpnc1
10.0.1.6 link#10 UHS 0 0 16384 lo0
10.0.10.0/24 link#3 U 0 0 1500 em2
10.0.10.11 link#3 UHS 0 0 16384 lo0
10.0.11.0/24 link#1 U 0 4693 1500 em0
10.0.11.11 link#1 UHS 0 0 16384 lo0
85.126.x.x/29 link#2 U 0 1709 1500 em1
85.126.x.x link#2 UHS 0 0 16384 lo0
127.0.0.1 link#7 UH 0 26 16384 lo0Routing table at OpenBSD:
Destination Gateway Flags Refs Use Mtu Prio Iface
default static.1.6.9.5.cli UGS 12 889109 - 8 em0
static.0.6.9.5.cli link#1 UC 1 0 - 4 em0
static.1.6.9.5.cli 78:fe:3d:47:19:0f UHLc 2 0 - 4 em0
picard localhost UGHS 0 0 33196 8 lo0
10.0.0/24 link#2 UC 1 0 - 4 em1
planck 08:00:27:45:c7:c1 UHLc 2 606332 - 4 em1
10.0.1/24 10.0.1.2 UGS 0 285890 - 8 tun0
10.0.1.2 10.0.1.1 UH 2 0 - 4 tun0
10.0.11/24 10.0.1.2 UGS 0 0 - 8 tun0
85-126-x-x.work static.1.6.9.5.cli UGHD 2 888959 - L 56 em0
loopback localhost UGRS 0 0 33196 8 lo0
localhost localhost UH 7 145056 33196 L 4 lo0
BASE-ADDRESS.MCAST localhost URS 0 0 33196 8 lo0Thank you!
-
Something's fishy… It looks like PFsense is trying to route 10.0.0.0/24 through 10.0.1.1 (which should be other end of the tunnel), but the system thinks the other end of the tunnel is 10.0.1.5. Do you have any manual routes added?
I would start by removing any manually added routes, then:
Client side:
-
remove the ifconfig and route lines from the advanced section and enter the appropriate information into the Tunnel Settings section of the GUI and let PFsense generate those lines
-
Reboot PFsense
Server side:
-
even know the server-side looks ok, I would place the ifconfig line underneath the server line
-
place the route statement down by the push lines
-
I'm also wondering on the server side if you need to change "dev tun0" to just "dev tun" (I believe you would only use that if you have multiple connections and want to bind each connection to a separate interface)
After that I would turn on logging of your firewall rules on the openvpn interface on both sides and verify that you're not getting blocks.
-
-
Okay, logging is turned on and everything is passed.
logs:
pass Oct 6 14:47:32 LAN 10.0.11.107 10.0.0.2 ICMP
the routes look way better now on the pfsense:
IPv4
Destination Gateway Flags Refs Use Mtu Netif Expire
default 85.126.29.201 UGS 0 38 1500 em1
10.0.0.0/24 10.0.1.5 UGS 0 36 1500 ovpnc1
10.0.1.0/24 10.0.1.5 UGS 0 0 1500 ovpnc1
10.0.1.5 link#10 UH 0 0 1500 ovpnc1
10.0.1.6 link#10 UHS 0 0 16384 lo0
10.0.10.0/24 link#3 U 0 0 1500 em2
10.0.10.11 link#3 UHS 0 0 16384 lo0
10.0.11.0/24 link#1 U 0 3994 1500 em0
10.0.11.11 link#1 UHS 0 0 16384 lo0
85.126.29.200/29 link#2 U 0 174 1500 em1
85.126.29.203 link#2 UHS 0 0 16384 lo0
127.0.0.1 link#7 UH 0 33 16384 lo0but I still have no connection to 10.0.0.0/24; though pinging 10.0.1.6 works