Routing issues between networks behind openvpn routers

mailman · Sep 14, 2013, 4:34 PM

Hi all,

I am a bit struggling with my VPN setup. It looks something like:

LAN1: 10.0.0.0/24 ===> OVPN-GW <=== big bad internet ====> branch office router <=== LAN2: 10.0.11.0/24

OpenVPN-Gateway is running OpenBSD 5.2 and OpenVPN 2.2.2.
The branch office router is running pfsense 2.0.3-RELEASE (amd64)

IP-range for the clients on the VPN is 10.0.1.0/24 (tun).

My goal was to allow the users in LAN2 access to LAN1. OpenVPN configuration seems to be fine, as the connection is fine and pinging the OVPN-GW from the pfsense console is possible. The firewall on pfsense was temporary set to allow all traffic. Also on OpenBSD's pf "pass in" && "pass out" were temporary activated for testing purpose, but I had no luck accessing LAN1 from LAN2.

What also seemed a bit strange on this OpenVPN setup generally is that, pinging the server from the clients is successful, but not the other way round. Is this behavior correct? Ping from server to client fails.

Has anybody some hints on this, or maybe can give me some clue on how to debug this issue? To me it seems a lot of a routing issue.

Thank you!

Best regards

========= routing table OVPN-GW =========

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default x.x.6.1 UGS 6 149158 - 8 em0
x.x.6.0/27 link#1 UC 1 0 - 4 em0
x.x.6.1 78:fe:3d:47:19:0f UHLc 1 0 - 4 em0
x.x.6.24 127.0.0.1 UGHS 0 0 33196 8 lo0
10.0.0/24 link#2 UC 1 0 - 4 em1
10.0.0.2 08:00:27:45:c7:c1 UHLc 3 150838 - 4 em1
10.0.1/24 10.0.1.2 UGS 0 38419 - 8 tun0
10.0.1.2 10.0.1.1 UH 1 0 - 4 tun0
127/8 127.0.0.1 UGRS 0 0 33196 8 lo0
127.0.0.1 127.0.0.1 UH 2 31314 33196 L 4 lo0
224/4 127.0.0.1 URS 0 0 33196 8 lo0

========= routing table branch office router =========

IPv4
Destination Gateway Flags Refs Use Mtu Netif Expire
default x.x.29.201 UGS 0 2060 1500 em1
10.0.0.0/24 10.0.1.1 UGS 0 0 1500 ovpnc1
10.0.1.0/24 10.0.1.9 UGS 0 977 1500 ovpnc1
10.0.1.9 link#10 UH 0 0 1500 ovpnc1
10.0.1.10 link#10 UHS 0 0 16384 lo0
10.0.10.0/24 link#3 U 0 447 1500 em2
10.0.10.11 link#3 UHS 0 0 16384 lo0
10.0.11.0/24 link#1 U 0 2225 1500 em0
10.0.11.11 link#1 UHS 0 0 16384 lo0
x.x.29.200/29 link#2 U 0 987 1500 em1
x.x.29.203 link#2 UHS 0 0 16384 lo0
127.0.0.1 link#7 UH 0 13 16384 lo0

========= routing table computer in LAN2 =========

IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 10.0.11.11 10.0.11.101 266
10.0.11.0 255.255.255.0 Auf Verbindung 10.0.11.101 266
10.0.11.101 255.255.255.255 Auf Verbindung 10.0.11.101 266
10.0.11.255 255.255.255.255 Auf Verbindung 10.0.11.101 266
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 10.0.11.101 266
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 10.0.11.101 266

========= routing table computer in LAN1 =========

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

marvosa · Sep 15, 2013, 5:13 AM

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)

mailman · Sep 15, 2013, 12:37 PM

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 unreachable

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

====== 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

marvosa · Sep 16, 2013, 7:25 PM

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 · Sep 21, 2013, 4:43 PM

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 · Sep 21, 2013, 8:27 PM

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 · Sep 21, 2013, 5:48 PM

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 · Sep 21, 2013, 9:00 PM

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

mailman · Sep 22, 2013, 12:27 PM

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 · Sep 22, 2013, 10:52 PM

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 · Sep 29, 2013, 12:51 PM

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 · Oct 2, 2013, 2:48 AM

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 · Oct 6, 2013, 12:51 PM

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