I have a configuration that probably should be listed in the
examples/FAQ - but I'm not seeing what I need.
OpenVPN server is running on a host in the corporate LAN. Using
TUN/Routed mode. VPN server has a LAN IP of 192.168.0.2 and a VPN IP of
10.0.0.1. This server also provides DNS & DHCP services for LAN.
LAN corporate router has IP of 192.168.0.1 and is the default gateway
for all LAN devices including the OpenVPN server.
Client, who's client LAN IP should (correct?) be irrelevant, connects
with remote VPN IP of 10.0.0.2.
My goal is to have the client able to access *all* hosts on the
corporate server side. Bi-directional access is also desirable.
The TL;DR version: with the VPN server running inside the LAN and on a
different host than the LAN gateway - is NAT required on the VPN
server? Or is NAT only required on the gateway - the rest is done with
*proper* routing configuration (and please confirm what that means!).
If my below config looks correct...then I probably will start digging
into the firewall settings of the VPN client.
** Server config exerpt:
server 10.0.0.0 255.255.255.0
local 192.168.0.2
proto udp
dev tun
topology subnet
client-config-dir /etc/openvpn/server/ccd
client-to-client
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.2"
server# ip route
default via 192.168.0.1 dev enp2s0 proto static
10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev enp2s0 proto kernel scope link src 192.168.0.2
** Gateway routing
/ip route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.11.1 1
3 A S 10.0.0.0/24 192.168.0.1 192.168.0.2 1
6 ADC 192.168.0.0/24 192.168.0.1 bLAN 0
10 ADC 192.168.11.0/24 192.168.11.10 bInternet 0
** Client config
client
dev tun
proto udp
# Make sure VPN is way down the list as a default route - only want VPN
use for VPN resources
route 0.0.0.0 0.0.0.0 10.0.0.1 200
>route print
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.5.1 192.168.5.6 25
0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.2 200
10.0.0.0 255.255.255.0 On-link 10.0.0.2 291
10.0.07.2 255.255.255.255 On-link 10.0.0.2 291
10.0.0.255 255.255.255.255 On-link 10.0.0.2 291
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.0.0 255.255.255.0 10.0.0.1 10.0.0.2 35
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.0.0.2 291
255.255.255.255 255.255.255.255 On-link 192.168.5.6 281
===========================================================================
**
I do have complete control of both the gateway and server - so I can
configure them optimally. My question is - what is optimal? At this
time the server has no NAT or other iptables processes running. The
gateway does - and I can tweak as needed. The gateway obviously has a
DNAT rule to allow the clients to reach the server. My question is:
what else is required?
My obviously incorrect understanding - client from Internet connects to
server (this works). Client requests resources from 192.168.0.2. Client
knows to reach 192.168.0.0/24 it should contact 10.0.0.1 via 10.0.0.2.
So the request goes off...VPN server receives it, and if it's a request
directly for the server the reply is easy. If the request is for the
gateway - the server forwards the request to the gateway at 192.168.0.1
(without NAT). My understanding of the abstract packet format is:
"The guy at 10.0.0.2 wants 192.168.0.1. I'm 192.168.0.2 and just passing
the message on - so you reply to me and I'll tell him"
The gateway in turn responds to the server which forwards back to the
client. So far so good.
The problem arises when reaching other LAN clients - let's pick
192.168.0.30. No NAT, one interface, simple routing table:
# ip route
default via 192.168.0.1 dev enp1s0 proto dhcp src 192.168.0.32 metric 100
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.32
192.168.0.1 dev enp1s0 proto dhcp scope link src 192.168.0.32 metric 100
When pinging 192.168.0.32 from 10.0.0.2, I will see one or more "request
timed out"...but at some point I will start seeing replies. At that
time the VPN client can access the LAN host. After a period of
inactivity - the "request timed out" condition will re-occur. So I'm
assuming something (whether VPN server, gateway, or LAN host) is
"learning" how to communicate.
For the reverse, 192.168.0.32 can ping 10.0.0.1 - although I will at
times see:
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.546 ms
From 192.168.0.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.2)
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.515 ms
but later
~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.194 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.225 ms
attempting to reach 10.0.0.2 never succeeds.
Again my abstract view of the conversation:
"The guy at 10.0.0.2 wants 192.168.0.30. I'm 192.168.0.2 and just
passing the message on - so you reply to me and I'll tell him."
192.168.0.2 knows how to reach .30 (same network) so they should
communicate directly. 192.168.0.30 knows how to respond to .2 so it
should do so without involving the gateway at .1. Obviously this doesn't
quite work in reality.
"I'm 192.168.0.30 and trying to reach 10.0.0.2. I've been told
192.168.0.1 knows all and sees all - how do I get there?" 192.168.0.1
knows to reach 10.0.0.2 it's via 192.168.0.2 - so the message should be
forwarded there. Again, I'm missing something.
I presently have the following NAT rules on the gateway:
1 ;;; Hairpin NAT for LAN & VPN
chain=srcnat action=src-nat to-addresses=192.168.0.1
src-address=192.168.0.0/24
dst-address=192.168.0.0/24 log=no log-prefix=""
3 ;;; Hairpin NAT public IP redirect to VPN host
chain=dstnat action=dst-nat to-addresses=192.168.0.2
dst-address=my.public.ip.here
in-interface=bLAN log=no log-prefix=""
10 ;;; OpenVPN
chain=dstnat action=dst-nat to-addresses=192.168.0.2
to-ports=myport protocol=udp
in-interface=bInternet dst-port=myport log=no log-prefix=""
The gateway can ping the VPN server via both the LAN IP and the VPN IP
but cannot ping the VPN client.
The formatting of the various tables above should provide a hint as to
the OS's involved if it matters.
--
Daniel
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
