Hi Alexis, On 17/06/15 17:41, Alexis Huxley wrote: > At > https://openvpn.net/index.php/open-source/documentation/howto.html#scope > it says: > >> Next, you must set up a route on the server-side LAN gateway to route > the VPN client subnet ... to the OpenVPN server ... > > I was (possibly wrongly) imagining that there should be a nicer way to > accomplish the intended result without having to tell the server-side > LAN about the *tunnel* IPs in order that hosts there can reply to the > client-side LAN: ideally, shouldn't server-side LAN hosts just need to > know that to reach the client-side LAN they need to go via the server's > interface on the server-side LAN? the 'client subnet' is not the same thing as a "tunnel IP" . The server-side LAN does not need to know anything about tunnel IPs (in theory you can do without IP address on the tunnel interfaces).
The server-side LAN *does* need to know the IP range of the client-side LAN (aka subnet) . > To make the next bit easier to explain, here are some numbers: > > server-side LAN: 192.168.1.0/24 > client-side LAN: 192.168.0.0/24 > VPN server 'server' line: server 10.239.67.0 255.255.255.0 > server VPN address: 10.239.67.1 > client VPN address: 10.239.67.6 > client LAN address: 192.168.0.11 > > My first step was just to ping in both directions: from the server-side > LAN all worked fine, from the client-side LAN everything is fine but > from the client itself it isn't. tcpdump told me why: the client sends > packets with the source address set to its end of the *tunnel* (i.e. > 10.239.67.6) and I have deliberately not told the server-side LAN about > the tunnel's IP addresses. > > To fix this, I did SNAT on the server: > > iptables -t nat -A POSTROUTING -s 10.239.67.6 -j SNAT > --to-source=192.168.0.11 > > and this worked; now packets on the client, arriving on the server, have > their source addresses changed from the client's tunnel NIC to the > client's LAN NIC, so, when a server-side LAN host receives the packet > then then it knows how to route its replies (because a route to the > client-side LAN was added to its routing table at boot time). > > If I had only one client then I could just put this iptables call - with > its hard-coded IP addresses - in the 'up' script, but I want more > clients, so I need to do something a bit more flexible. > > However, in the 'up' script's command line args and in its environment, > I don't see anything that tells the server what IP the *client* side of > the tunnel is. > > So now to my question: is there any way for the server to determine the > IP of the client's end of the tunnel? The env vars the 'up' script sees are: > > route_vpn_gateway=10.239.67.2 > daemon_log_redirect=0 > script_type=up > proto_1=udp > daemon=0 > route_network_1=192.168.0.0 > dev=tun0 > route_network_2=10.239.67.0 > remote_port_1=1194 > script_context=init > ifconfig_local=10.239.67.1 > verb=3 > local_port_1=1194 > link_mtu=1541 > route_gateway_1=10.239.67.2 > tun_mtu=1500 > route_gateway_2=10.239.67.2 > route_netmask_1=255.255.255.0 > route_netmask_2=255.255.255.0 > route_net_gateway=192.168.1.1 > ifconfig_remote=10.239.67.2 > daemon_pid=6240 > config=server.conf > PWD=/etc/openvpn > > Note that the 10.239.67.6 is not in that list. > > A pushed ifconfig *is* known within a client-connect script (says the > man page), but before I start writing one of those, I thought it made > sense to ask here for a simpler solution. Thanks! > only when a client connects will the client-side tunnel IP be known ; thus you'd need to write a client-connect script to get at it. However, as I explained above, you don't need it at all to achieve what you are outlining. HTH, JJK ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
