MY GOAL
To be able to directly access additional boxes behind my OpenVPN server from a remote client. The boxes may be either other servers, or desktop systems on the same network.
MY NETWORK TOPOLOGY
Server LAN network 192.168.112.0/24
VPN Server LAN IP 192.168.112.50
VPN Server IP 10.9.8.1
DNS/DHCP Server 192.168.112.51
Gateway/Firewall/Router 192.168.112.11
* Note that my network router is on a different box than my VPN Server *
Remote client network 192.168.123.0/24
VPN Client IP 10.9.8.x
I have a basic VPN connection established. I can connect from a remote (Windows) client to my OpenVPN Server (CentOS 6.7) without any issue. The client and server configs are posted below. I have not included the connection log from the client. Since I have an established connection I don’t expect that to be of any value in resolving this issue, but please let me know otherwise.
- CLIENT CONFIG
client
dev tun
proto udp
remote xxx.yy.190.20 1195
pull
nobind
persist-key
persist-tun
tls-client
ca "C:\\Program Files\\OpenVPN\\config\\yca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\JABdougfirhomeclient.crt"
key "C:\\Program Files\\OpenVPN\\config\\JABdougfirhomeclient.key"
ns-cert-type server
resolv-retry infinite
comp-lzo
route-method exe
route-delay 2
verb 4
- SERVER CONFIG
local 192.168.112.50
port 1195
proto udp
dev tun
tls-server
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/SequoiaVPNserver.crt
key /etc/openvpn/easy-rsa/2.0/keys/SequoiaVPNserver.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem
server 10.9.8.0 255.255.255.0
float
ifconfig-pool-persist /etc/openvpn/ipp.txt 120
push "route 192.168.112.0 255.255.255.0"
push "explicit-exit-notify 3"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 4
I have read through several how-to’s regarding accessing LAN resources behind the VPN server, including one by Mimiko, one by Krzee, and the simple description on the OpenVPN.net HowTo. From that information I have reviewed, I recognize that there are four different approaches to solving this issue.
- 1. Move the OpenVPN server to the LAN gateway.
Not feasible on my company network.
2. Add a static route for remote network to *every host’s* routing table.
Not a flexible or scalable solution that I would want to implement or maintain over the long term.
3. All packets from the remote network and tunnel itself are masqueraded to represent the OpenVPN host local IP, therefore all packets would be returned/routed back to that IP.
This has the disadvantage of obscuring the source of each VPN connection on my LAN, which may cause problems with future network diagnostics. Therefore I would like to avoid this approach.
4. Add route to the LAN default gateway.
The seems like the most efficient solution to what I believe to be a routing issue, and is the approach I would like to implement.
I have ipforwarding enabled on the VPN server (CentOS 6.7) box. I can access the VPN server at ...50, and I would like to access another server which is at ...53. Results from pinging the VPN server, and another server on the LAN behind the VPN server are shown below. Any box behind the VPN server returns a response of Destination Host Unreachable.
c:\>ping 192.168.112.50
Pinging 192.168.112.50 with 32 bytes of data:
Reply from 192.168.112.50: bytes=32 time=75ms TTL=64
c:\>ping 192.168.112.53
Pinging 192.168.112.53 with 32 bytes of data:
Reply from 10.9.8.1: Destination host unreachable.
Researching the destination host unreachable response led me to the following good description of how this message is generated via network protocols.
Source: https://technet.microsoft.com/en-us/lib ... 40095.aspx* This message indicates one of two problems: either the local system has no route to the desired destination, or a remote router reports that it has no route to the destination. The two problems can be distinguished by the form of the message. If the message is simply "Destination Host Unreachable," then there is no route from the local system, and the packets to be sent were never put on the wire. Use the Route utility to check the local routing table. If the message is "Reply From < IP address >: Destination Host Unreachable," then the routing problem occurred at a remote router, whose address is indicated by the "< IP address >" field. Use the appropriate utility or facility to check the IP routing table of the router assigned the IP address of < IP address >. *
Based on the ping response, and since *my LAN router is not the same box as the VPN server*, I had previously concluded that I needed to add a route on my LAN default gateway for the VPN network IP subnet pointing to the OpenVPN box (following approach #4 described above). I added a static route on my default gateway (a PfSense box) to redirect any VPN network traffic back to the VPN box, which I believe should send it back through the tunnel to the point of origin. However, this did not resolve my issue, so I must be mistaken about my routing somewhere, or there is something else that I have not considered.
CURRENT ROUTING AND FIREWALL INFO
The current routing table for the gateway/router (PfSense) box shows:
Code: Select all
[2.1.2-RELEASE][admin@pfgateway.mei.lan]/root(1): netstat -rn
Destination Gateway Flags Refs Use Netif Expire
default xxx.yy.190.17 UGS 1 663197177 bge0
10.9.8.0/24 192.168.112.50 UGS 0 0 rl0
xxx.yy.190.16/28 link#1 U 0 49927480 bge0
xxx.yy.190.18 link#1 UHS 0 0 lo0
xxx.yy.190.19 link#1 UHS 0 0 lo0 =>
xxx.yy.190.19/32 link#1 U 0 0 bge0
xxx.yy.190.20 link#1 UHS 0 0 lo0 =>
xxx.yy.190.20/32 link#1 U 0 0 bge0
xxx.yy.190.21 link#1 UHS 0 0 lo0 =>
xxx.yy.190.21/32 link#1 U 0 0 bge0
xxx.yy.190.22 link#1 UHS 0 0 lo0 =>
xxx.yy.190.22/32 link#1 U 0 0 bge0
127.0.0.1 link#6 UH 0 560 lo0
192.168.112.0/24 link#2 U 0 848109484 rl0
192.168.112.11 link#2 UHS 0 99857580 lo0Code: Select all
[root@sequoia ~]# ifconfig
eth0 Link encap:Ethernet HWaddr aa:bb:00:9D:B2:49
inet addr:192.168.112.50 Bcast:192.168.112.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe9d:b249/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:188054402 errors:0 dropped:0 overruns:0 frame:0
TX packets:169321935 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:36069946217 (33.5 GiB) TX bytes:47188246310 (43.9 GiB)
< snip lo >
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.9.8.1 P-t-P:10.9.8.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:9066254 errors:0 dropped:0 overruns:0 frame:0
TX packets:7591995 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1029571120 (981.8 MiB) TX bytes:1210868888 (1.1 GiB)
[root@192.168.112.50 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.9.8.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.112.0 * 255.255.255.0 U 0 0 0 eth0
10.9.8.0 10.9.8.2 255.255.255.0 UG 0 0 0 tun0
link-local * 255.255.0.0 U 1002 0 0 eth0
default pfgateway.mei.l 0.0.0.0 UG 0 0 0 eth0The next idea that I have considered is that the firewall on the VPN server box might be restricting the packets. Below are the firewall rules for the VPN server. The only possibility that I was thinking here was that I might need to add an accept rule for the 10.9.8.0/24 network in the forward chain. But I thought that by having ipforwarding turn on it wasn’t needed here, so I haven’t made any changes.
Code: Select all
[root@sequoia ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
289M 50G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
573 22456 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
1 60 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
124 6504 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
261K 38M ACCEPT all -- * * 192.168.112.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.9.8.0/24 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:1194
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:137
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:138
62 2988 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:139
267 14588 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445 state NEW
3276 177K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
65 3504 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:10000
47 1974 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:1195
117K 5194K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
108K 12M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 261M packets, 62G bytes)
pkts bytes target prot opt in out source destination
Jeff