Routing issues between networks behind openvpn routers

marvosa

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/24

From 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.0

CLIENT

ifconfig 10.0.1.2 10.0.1.1
route 10.0.0.0 255.255.255.0

Also 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

mailman

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

marvosa

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.

kejianshi

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

marvosa

Just to clarify my first post, those missing lines need to be added to your config… not added via command line after connection.

mailman

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.0

new server config:

proto udp
port 444
dev tun0

ifconfig 10.0.1.1 10.0.1.2
route 10.0.11.0 255.255.255.0

ca /etc/openvpn/ca.crt
cert /etc/openvpn/private/picard.goetzinger.cc.crt
key /etc/openvpn/private/picard.goetzinger.cc.key
dh /etc/openvpn/dh2048.pem

server 10.0.1.0 255.255.255.0

keepalive 10 120
comp-lzo

user openvpn
group openvpn
daemon openvpn

persist-key
persist-tun

tls-auth /etc/openvpn/private/ta.key 0
cipher AES-256-CBC

push "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.2"
client-to-client

status /var/log/openvpn-status.log

marvosa

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.

mailman

Sure, tunnel status has been fine, since initial setup.

Firewall rules at OpenBSD are

pass in
pass out

Firewall rules at the pfsense are

Proto TCP
Source *
Port *
Destination *
Port *
Gateway *
Queue None

Routing 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 lo0

Routing 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 lo0

Thank you!

marvosa

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.

mailman

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 lo0

but I still have no connection to 10.0.0.0/24; though pinging 10.0.1.6 works