Hi Alexis, On 18/06/15 12:58, Alexis Huxley wrote: > Hi Jan, > >> 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. > Okay. I'll start googling example scripts :-) Thanks! > > Alexis > > PS Regarding this: > >>> 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 >> server-side LAN does not need to know anything about tunnel IPs (in >> theory you can do without IP address on the tunnel interfaces). > According to the documentation the server-side LAN *does* need to know > about the VPN addresses. Look at point (2) below: > >>>> [heading] Including multiple machines on the server side >>>> when using a routed VPN (dev tun) >>>> >>>> Once the VPN is operational in a point-to-point capacity >>>> between client and server, it may be desirable to expand >>>> the scope of the VPN so that clients can reach multiple >>>> machines on the server network, rather than only the server >>>> machine itself. >>>> >>>> For the purpose of this example, we will assume that the >>>> server-side LAN uses a subnet of 10.66.0.0/24 and the VPN >>>> IP address pool uses 10.8.0.0/24 as cited in the server >>>> directive in the OpenVPN server configuration file. >>>> >>>> First, you must advertise the 10.66.0.0/24 subnet to <---- (1) >>>> VPN clients as being accessible through the >>>> VPN. This can easily be done with the following server-side >>>> config file directive: >>>> >>>> push "route 10.66.0.0 255.255.255.0" >>>> >>>> Next, you must set up a route on the server-side LAN <---- (2) >>>> gateway to route the VPN client subnet >>>> (10.8.0.0/24) to the OpenVPN server (this is only necessary >>>> if the OpenVPN server and the LAN gateway are different >>>> machines). > Maybe I didn't make myself very clear. Here's my setup, showing > server-side network, client-side network, server-side-host #1, #2, > VPN server, VPN client, client-side-host #1, #2, as well as server-side > and client-side internet gateways: > > (SSN) (CSN) > | | > SSIGW -+ +-- CSIGW > SSH1 --+ +-- CSH1 > SSH2 --+ +-- CSH2 > +-- VPNS -- VPNC --+ > | | > | | > > If VPNC was a *dedicated* VPN gateway for the CSN network, and was > itself never the endpoint of any (non-OpenVPN) traffic then I would > agree with you that none of them need to know the details of the > tunnel. But the problem comes when the VPN client (or the VPN server) > is the endpoint. > > Here's a tcpdump of SSH1 pinging VPNC, as seen by VPNS: > > fideua# tcpdump -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > Thu Jun 18 11:19:38 2015 MULTI: Learn: 192.168.0.11 -> > client1/79.78.209.164:57457 > 11:19:38.743608 IP 192.168.1.18 > 192.168.0.11: ICMP echo request, id > 9975, seq 1, length 64 > 11:19:38.809778 IP 192.168.0.11 > 192.168.1.18: ICMP echo reply, id > 9975, seq 1, length 64 > 11:19:39.745707 IP 192.168.1.18 > 192.168.0.11: ICMP echo request, id > 9975, seq 2, length 64 > 11:19:39.817378 IP 192.168.0.11 > 192.168.1.18: ICMP echo reply, id > 9975, seq 2, length 64 > > Note how the ping request's source IP address is routable according > to the recipient's routing table, that's because of point (1) in the > HOWTO, so the VPN client will be able to reply and we see that. > > But what about the other way round? Here's a tcpdump of VPNC pinging > SSH1, as seen by VPNS: > > fideua# tcpdump -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 11:24:28.723054 IP 10.239.67.6 > 192.168.1.18: ICMP echo request, id > 4578, seq 1, length 64 > 11:24:29.730462 IP 10.239.67.6 > 192.168.1.18: ICMP echo request, id > 4578, seq 2, length 64 > > Note how the source IP address is *not* routable according to the > recipient's routing table, and indeed, we see no reply seen because > SSH1 routes the reply over SSIGW! Here's a tcpdump of the same ping as > seen from SSH1: > > chifferi# tcpdump -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 11:25:22.148641 IP 10.239.67.6 > 192.168.1.18: ICMP echo request, id > 4578, seq 54, length 64 > 11:25:22.148676 IP 192.168.1.18 > 10.239.67.6: ICMP echo reply, id 4578, > seq 54, length 64 > 11:25:23.153169 IP 10.239.67.6 > 192.168.1.18: ICMP echo request, id > 4578, seq 55, length 64 > 11:25:23.153203 IP 192.168.1.18 > 10.239.67.6: ICMP echo reply, id 4578, > seq 55, length 64 > > Without point (2) from the HOWTO, the reply is routed via SSIGW, not > over the VPN. I.e.: > > The server-side LAN *does* need to know about the IP address than the > VPN client has on its end of the VPN tunnel: *not* because server-side > LAN hosts can't connect to the VPN client, but because they can't > *reply* to the VPN client when the VPN client has sent packets which are > marked as coming from the IP address that the VPN client has on its end > of the tunnel, not the IP address that the VPN client has on *its* LAN. > > But as mentioned earlier: > >>> I have deliberately not told the server-side LAN about >>> the tunnel's IP addresses. > and with SNAT I can nicely work around that, which results in: > > chifferi# tcpdump -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 11:27:19.738136 IP 192.168.0.11 > 192.168.1.18: ICMP echo request, id > 4585, seq 10, length 64 > 11:27:19.738170 IP 192.168.1.18 > 192.168.0.11: ICMP echo reply, id > 4585, seq 10, length 64 > 11:27:20.738504 IP 192.168.0.11 > 192.168.1.18: ICMP echo request, id > 4585, seq 11, length 64 > 11:27:20.738540 IP 192.168.1.18 > 192.168.0.11: ICMP echo reply, id > 4585, seq 11, length 64 > > (Compare the ping request's source address with the previous one; *now* > the reply will be routed over the VPN.) > ah, you've hit one of my examples of the OpenVPN cookbook: what if all clients can be reached except the VPN endpoints themselves ... SNATting is one way to work around this - you could also use a client-side "up" script to set up the SNAT rule (if the client is running some form of Linux/BSD : you'd then SNAT all traffic entering the tunnel . That way, the server does not need to know the client side IP. Also, you could use server-side NATting to rewrite all traffic coming out of the tunnel with a VPN IP address, e.g. iptables -t nat -I POSTROUTING -i tun+ -o eth0 -j MASQUERADE
HTH, JJK ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
