Sometimes it is easy to be unintentionally ambiguous. I shall clarify a couple things below...
On 8/19/13, Zenaan Harkness <z...@freedbms.net> wrote: > On 8/19/13, Gregory Nowak <g...@gregn.net> wrote: >> On Sun, Aug 18, 2013 at 04:29:16PM -0600, Bob Proulx wrote: >>> Your vpn will be connected to the public address. It will establish a >>> private address for the encrypted traffic. >> >> Yes, except that it's a public address I'm actually after. More below. >> >> I wrote: >>> > I want to have the ability to connect to the VPS, and give a client >>> > (gnu/linux, or windows) a static IP address through the VPS. >> >> Maybe I should have been more explicit. I want to have the ability to >> connect to the VPS, and give a client (gnu/linux, or windows) a >> publicly routable static IP address through the VPS from the /29 >> subnet. > > The key I think is the word "routable" which you use. > > After a successful VPN setup, your VPS becomes analogous to your home > internet modem router - the router has a public address dedicated to > _all_ of your home computers/phones/etc. > > Your home router can only "assign" its public ip (through its ppp > link) As in, the 'modem/router' gets its 'public ip address' through ppp (often times, not always). > to an internal box by setting up port forwarding or a DMZ host. > Port forwarding eg for 80, 443 etc, or DMZ host where _all_ external > ports are mapped to one particular internal IP address. The 'modem/router' forwards some ports (port forwarding) or all ports (forwarding to DMZ-host) by some filewall rules in the modem/router, to the chosen internal client/laptop/DMZ-host (behind the modem/router, or in your case, the client end of your VPN connection to your VPS which runs the server end of your VPN (OpenVPN does this admirably). > It sounds like you want the (laptop) client end of your VPN to be the > DMZ host for a particular VPS /29 external address. > > Set up OpenVPN: > OpenVPN will still have two endpoint addresses for each client, and > one for the server. Hopelessly sloppy wording sorry. Let me try again: The OpenVPN VPN will still have two endpoint addresses (at least): one each for: the VPN-client (laptop), and the VPN-server (the VPS) Additional (eg laptop) clients would each get their own address as well but that does not sound like what you need right now. OpenVPN has a mode of operation where there is a mini (two-address?) subnet for each client (and server??) which was necessary in the early tun-driver days before full tap-driver subnet support became available in the code (kernel driver and equivalent on other operating systems, and in OpenVPN code of course). I'm might not have my history exactly right sorry. These days though, unless you must support really old OpenVPN clients, just go with the OpenVPN standard flat subnet mode (one address for server, one address for each client). (Side note: this client to server VPN link is analogous to a PPP link, but uses OpenVPN not pppd) > Eg 10.1.1.1/24 for the server, eg 10.1.1.2 for the > VPN (laptop) client. > > Choose a /29 address on your VPS to dedicate to the VPN (laptop) client. > Configure the VPS kernel firewall rules to 1:1 map all public ports on > this chosen /29 address, to the VPN (laptop) client address eg to > 10.1.1.2. > > Does this sound like what you want? > >>> The "through the VPS" words confuse me. A vpn client will have a >>> private address on the client assigned to it. It will use it to >>> connect to the private address on the server. Is that "through the >>> VPS"? It is "to the VPS" certainly. >> >> The scenario I proposed above requires the laptop to connect to the >> VPS to get the static public address. Any traffic the laptop >> sends/receives with that address will be routed through the VPS. So, >> the connection is both to, as well as through the VPS > > The VPN (laptop) client has address (in this example) 10.1.1.2. This > address is the address that the (laptop) client uses as its "publicly > routable" address. You can call it its DMZ address, since random > connection attempts (from the public) will appear on 10.1.1.2. > > Because it is DMZ, you need to be confident to set up firewall rules > to protect the VPN (laptop) client. > > Consider forwarding just those ports you want of course - eg a > bittorrent port, SSH, HTTP, HTTPS etc. Since you are configuring VPS > firewall rules for either forwarding or DMZ, shouldn't be much > difference either way. So there is no misunderstanding: either way, the forwarding of specific ports, or of all ports, on the /29 public address, happens on the VPS. You are forwarding the ports (some or all) from the /29, to (in this example) 10.1.1.2. Then your laptop-VPN-client with high aspirations of being a clandestine server, would eg serve up HTTP by listening on 10.1.1.2:80, and the public would access this clandestine laptop server at chosen.public.address.on.vps:80 > Note in either scenario, PPP is not needed as part of the VPN setup. > It is taken as given that both the VPN (laptop) client, and the VPS, > are connected already to public internet in some form (via modem > (PPP/PoE etc), wireless, etc). > > The VPN part just needs openVPN to be configured correctly. > If eg your VPN (laptop) client is egregiously firewalled and eg can > only access (public) port HTTP 80, then simply setup openVPN to listen > on a VPS address that has port 80 unused/available. > If the VPN (laptop) client internet firewalling is even more > egregious, use eg httptunnel > >>> What is ppp doing for you? >>> >>> I am used to ppp driving the modem, dialing the phone, setting up >>> addresses, adding routing information to the kernel route tables, and >>> cleaning all up after hanging up the phone. Sure. But doesn't >>> openvpn do all of that function for you? Using the network components >>> with no phone of course. What is openvpn not doing that you would >>> have ppp do? >> >> Ppp is the transport over which the packets flow. It can be >> encapsulated in other transports direct serial to serial, ssh, l2tp >> ... Ppp forms a /32 subnet between the client/server. This subnet has >> a local and remote address on both ends. In the scenario I'm >> proposing, the local address on the server is a private one, and the >> remote is public. On the client side, the local address is public, and >> the remote is private. This is something openvpn seems to be unable to >> do as far as I can tell. > > Hopefully the above explanations make it clear for you now? > > OpenVPN is exactly what you want, I believe, when combined with > appropriate DMZ (or port forwarding) firewall rules on your VPS. > > Regards > Zenaan > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSSJOuwQT3OCf26KKAKA0uGn=XkVr8W4wp=ldio3hh0...@mail.gmail.com
