Re: openvpn question

[Zenaan Harkness]

On 10/25/13, Gregory Nowak  wrote:
> This is an update to the thread originally started at:
> 
>
> To recap briefly though, I ended up using NAT to route a public
> address from my /29 subnet on my VPS to a private IP address
> assigned to my client by openvpn on the VPS.
...
> This worked well. However, the proxy arp discussion in the latter part
> of this thread stayed with me, and I wanted my gnu/linux clients to
> actually get a public address directly from my /29 on their tap
> interface without doing NAT. Bob Proulx indicated this was possible,
...
> The bottom line is that I have my
> VPS doing proxy arp for my openvpn clients, so my clients get a public
> address assigned directly without the need for doing NAT.

Great! Thank you so much for sharing this,
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/caosgnssns0nt_burrnfvwv1feavdbd_zye_0mt1jp5sphjn...@mail.gmail.com

Re: openvpn question

[Gregory Nowak]

Hi all.

This is an update to the thread originally started at:



I won't give a summary here, the above URL can give the full story. To
recap briefly though, I ended up using NAT to route a public address
from my /29 subnet on my VPS to a private IP address assigned to my
client by openvpn on the VPS. The result of this is that my client got
a 10.28.49.253 address from openvpn on my VPS, but the rest of the
internet saw traffic from that client as if it came from the public
address I was doing NAT from/to on my VPS.

This worked well. However, the proxy arp discussion in the latter part
of this thread stayed with me, and I wanted my gnu/linux clients to
actually get a public address directly from my /29 on their tap
interface without doing NAT. Bob Proulx indicated this was possible,
but nobody actually explained it in step-by-step detail. Since at the
time I saw proxy arp as being incompatible with openvpn (more below) I
ended up trying to figure out various ways to do this, even suggesting
proxying a tun device at one point.

So, I ended up doing some research on proxy arp to make sure I
understood the parts that I did correctly, and to understand the other
parts of it which weren't so clear. The bottom line is that I have my
VPS doing proxy arp for my openvpn clients, so my clients get a public
address assigned directly without the need for doing NAT. While this
probably won't be a step-by-step, I wanted to provide an overview of
how to do proxy arp with openvpn in case someone wanted to do the
same, and was searching the web to find out how.

The key is to use --server-bridge on the openvpn server, but you
actually aren't setting up a bridged interface. The below from the
openvpn man page initially threw me for a loop, and made me think at
first that proxy arp and openvpn wouldn't work together:

"--server-bridge gateway netmask pool-start-IP pool-end-IP

   --server-bridge ['nogw']

A helper directive similar to --server which is designed to sim-
  plify  the  configuration  of  OpenVPN's server mode in
  ethernet
  bridging configurations."

I only wanted to use a tun/tap device, not a bridge. So, the only way
I saw how to do what I wanted to do was to use the --server directive,
which requires letting opvnvpn have a full /24 subnet all to itself!
So, I decided at some point to just try using --server-bridge with a
tap device instead of a bridge, and it works!

The server-side openvpn config file I posted earlier in this thread
should work fine from what I recall. I'm fairly sure all I did there
is to replace the line:

"server 10.28.49.0 255.255.255.0"

with:

"server-bridge"

Now, I still wanted to have my clients get an address through
dhcp. However, using --server-bridge means I don't get to use
openvpn's dhcp server anymore. So, I installed the isc-dhcp-server
package. I configured dhcpd for my /29 subnet, but specified mac
addresses instead of an IP range. Like so:

"host myhost.example.com 
{
fixed-address client_public_address;
hardware ethernet mac_address;
}

Yes, you can apparently configure a subnet block without giving a
range. This means that only clients with a known mac address by the
dhcp server will be given their own address. Also, my VPS is on its
own VLAN, and my VPS provider assures me nobody could use my public
interface to get assigned an IP address from my /29 by my dhcp server,
even if I were to use the range directive. So, I feel that running a
dhcp server under these conditions is secure enough for me.

Ok, we're ready to start the dhcp server, except that it would be
listening on the public interface only, not on the tap0 device which
openvpn would create. Besides that, we also need to setup routing for
the tap 0 interface. So, we have to edit /etc/network/interfaces
file.

To create the tap0 device before openvpn is started, I added the
following line to the end of my iface eth0 stanza:

"pre-up openvpn --mktun --dev tap0"

without the quotation marks of course. Then in my interfaces file I
have:

"auto tap0
iface tap0 inet static
address vps_public_address
netmask 255.255.255.255
post-up route -A inet add -host client_public_address dev tap0
pre-down route -A inet del -host  client_public_address dev tap0"

Notice the /32 netmask. I could simply have assigned another IP
address from my /29 subnet to the tap0 device. However, given how
precious each IP address from a /29 is to me, I simply used the public
address already assigned to the VPS' eth0, but with a /32 subnet. That
way, I still get an address for tap0, dhcpd can listen on it for lease
requests, and the tap0 device is all set. Add more post-up and
pre-down lines for every new client you want to get a public address
from the /29. This tells the VPS to use tap0 to communicate with those
addresses, instead of trying to reach them over eth0, which wouldn't
work.

We're almost done, but we haven't yet enabled proxy ar

Re: openvpn question

[Gregory Nowak]

Ok. In case others besides Zenaan are interested, here is what I did
to get openvpn going, and to allow my laptop to get a public IP
address through openvpn from the /29 block of public addresses
allocated to me from my VPS provider. This setup works for my needs,
your mileage may vary as they say. Also, as Bob pointed out, there is
more than one way to do this, my way is by no means the only one, and
by no means probably the best way either. The way I did this was the most
obvious way for me to accomplish what I wanted to do from my point of
view, and I am satisfied with the result. My VPS is running debian
wheezy. My laptop is running windows 7 home premium with the latest
openvpn for windows installed from http://www.openvpn.net as of this
writing. I haven't tried this on a GNU/Linux client yet, but it should
all function the same way with a linux client as far as I know.

Ok, on the VPS I have the following configuration. In
/etc/sysctl.d/local.conf, I have:

net.ipv4.ip_forward = 1

In my /etc/network/interfaces, I have:

auto eth0:0
iface eth0:0 inet static
address laptop_public_ip
netmask 255.255.255.248

My firewall script is simply a bash script I wrote, which calls
iptables/ip6tables to do what they do. The relevant lines from that
script are:

# set policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
 
# input rules
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i eth0:0 -j ACCEPT

# forward rules
iptables -A FORWARD -s public_subnet/29 -j ACCEPT
iptables -A FORWARD -d public_subnet/29 -j ACCEPT
iptables -A FORWARD -s 10.28.49.0/24 -j ACCEPT
iptables -A FORWARD -d 10.28.49.0/24 -j ACCEPT

# pre/postrouting
iptables -t nat -A PREROUTING --destination laptop_public_ip -j DNAT
--to-destination 10.28.49.253
iptables -t nat -A POSTROUTING -o eth0 --source 10.28.49.253 -j SNAT 
--to-source laptop_public_ip
 
# rules for incoming connections to accept
# openvpn
iptables -A INPUT -i eth0 -p tcp --dport 1194 -j ACCEPT


A few notes on the above are in order. My default OUTPUT policy is to
let all outbound connections through. You may want to restrict certain
outbound connections, tcp 25 comes to mind. I also allow all traffic
into the client machine. If the client machine isn't fully under your
control, or you simply don't trust it for whatever reason, you may
want to block some inbound connections on the in my case eth0:0
alias. Speaking of aliases, I wasn't sure how iptables would play with
alias interfaces, but it seems to do nicely. I could have done the
same thing by restricting connections on the client's public
destination address in the INPUT chain, and by restricting them on the
public source address in the OUTPUT chain. Finally, someone will
probably point out that my way of opening tcp port 1194 in the above
example is a bit awkward. You're right. What I actually do is define a
custom input chain, have all input on eth0 jump to that chain, and
accept what I want to accept once it comes into that custom chain.

Ok, now for the actual openvpn config. I modeled my
/etc/openvpn/server.conf file on the sample server.conf.gz file that
comes in debian's openvpn package, and I assume with openvpn
itself. Explanations of all the below options are in the openvpn man
page of course:

# This file is for the server side  #
# of a many-clients <-> one-server  #
# OpenVPN configuration.#
port 1194
proto tcp-server
dev tap0
ca /etc/ssl/my/ca.crt
cert /etc/ssl/my/gregn.net.crt
key /etc/ssl/private/gregn.net.key
dh dh2048.pem
client-config-dir ccd
opt-verify
keepalive 10 120
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
mute 20
server 10.28.49.0 255.255.255.0


A couple of notes. I don't need to create the tap0 device, openvpn
does that when it first starts. Since openvpn is only configured now
with one instance, and since nothing else on my VPS uses tap0, it's
fine for me to use dev tap0. You can instead use dev tap, but you will
need to adjust your firewalling to possibly deal with dynamic tap
devices. Using tap+ instead of tap0 with iptables should work here.
I originally started using tun devices with openvpn, and that
works fine as well. For the dh option, you will want to generate your
own dh parameters as described in the openvpn man page. You will also
of course need your own ssl certificates, either signed by you, or by
a real certifying authority.

In /etc/openvpn/ccd/laptop_common_name file, I have the following:

ifconfig-push 10.28.49.253 255.255.255.0
push "redirect-gateway def1 bypass-dhcp bypass-dns"
push "dhcp-option DNS dns_ip_one
push "dhcp-option DNS dns_ip_two

 
This allows the laptop to always get a static address from openvpn,
which is mapped in the firewall rules above to the laptop's public
address. If  a client connects whose certificate's common name doesn't
match a file in /etc/openvpn/ccd, that client will get a dynamic
address 

Re: openvpn question

[Gregory Nowak]

On Sat, Aug 24, 2013 at 12:57:18PM +1000, Zenaan Harkness wrote:
> Yes please! BUT: probably sanitize (obfuscate) your public, and
> isp-provided, ip addresses, if there is any likelihood of the
> existence of your particular VPN being of interest to an adversary.

Of course. I'll probably do that in a day or two.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130824035850.gc6...@gregn.net

Re: openvpn question

[Gregory Nowak]

On Sat, Aug 24, 2013 at 12:48:26PM +1000, Zenaan Harkness wrote:
> Bob, your link http://shorewall.net/ProxyARP.htm is
> great! Easy to read.

Yes, I meant to mention that. It does a good job of providing a
general explanation of proxy ARP indeed.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130824035642.gb6...@gregn.net

Re: openvpn question

[Gregory Nowak]

On Sat, Aug 24, 2013 at 12:44:28PM +1000, Zenaan Harkness wrote:
> Whether or not using proxy arp, I recommend using tap device. I
> believe there is a little more overhead with tun (higher in the
> stack), _especially_ given you want to forward everything, ie DNAT and
> SNAT.  tun buys nothing but overhead, compared to tap.

I've thought of doing that earlier, but didn't see the point of
switching from the openvpn default, since I don't need to actually
transport ethernet frames. I'll do that though, and will see if I
notice any improvement. Thanks.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130824033749.ga6...@gregn.net

Re: openvpn question

[Zenaan Harkness]

On 8/24/13, Gregory Nowak  wrote:
> As I already said, everything is working. The problem is solved. If
> there is interest, I can paste the openvpn configs from server/client,
> and the interfaces file with relevant iptables rules from the server
> to show how I'm doing what I'm doing. Thanks again to everyone for
> your help.

Yes please! BUT: probably sanitize (obfuscate) your public, and
isp-provided, ip addresses, if there is any likelihood of the
existence of your particular VPN being of interest to an adversary.

Should be common sense, but good to point out anyway. Although we
don't _rely_ on security-through-obscurity, unnecessary
lack-of-obscurity ought be avoided.

On principle!
(I don't have to be doing anything wrong, to want my privacy!)

 :)

Working configs are a great place for others to at least begin from.

Great to hear you got it all working,
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/caosgnsrb8oslchkpsf7w1w9jypdenf4su3mr1b8zofobhya...@mail.gmail.com

Re: openvpn question

[Zenaan Harkness]

On 8/24/13, Zenaan Harkness  wrote:
> On 8/24/13, Bob Proulx  wrote:
>> Right.  Which does not have anything to do with the way proxy arp is
>> set up.
>>
>>> I thought this over again with my brain fresher in the afternoon than
>>> it was last night, and you are right, it would work in this situation
>>> as long as the tun device had a MAC address of course.
>>
>> Do not attempt to proxy arp the tunnel device.  That way leads to
>> madness.
>
> Whether or not using proxy arp, I recommend using tap device. I

proxy arp looks to do exactly what op wanted in original conception of
his problem. Bob, your link http://shorewall.net/ProxyARP.htm is
great! Easy to read.

Something new every day...


-- 
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/CAOsGNSQhMo6W76k_-cRReqZE8Qt2nrpv8Wbi4O0zPha5kb=m...@mail.gmail.com

Re: openvpn question

[Zenaan Harkness]

On 8/24/13, Bob Proulx  wrote:
> Gregory Nowak wrote:
>> Bob Proulx wrote:
>> > The device will still have an ethernet address whether you assigned
>> > one to it or not.  It is not necessary for you to assign one since one
>> > has already been assigned by default.  (From the vendor.  Or in the
>> > case of virtual hardware from the software that created the
>> > simulation.)
>>
>> Uhhm, no.
>
> Uhm... Yes.
>
>> # ifconfig tun0
>> tun0  Link encap:UNSPEC  HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>
> Silly bear!  That is the tun device.  Never tunnel the tun device.
>
>> The above is from the VPS, with the openvpn connection from the laptop
>> running. This is a tun device, which doesn't require a MAC address at
>> all to function as I understand it.
>
> Right.  Which does not have anything to do with the way proxy arp is
> set up.
>
>> I thought this over again with my brain fresher in the afternoon than
>> it was last night, and you are right, it would work in this situation
>> as long as the tun device had a MAC address of course.
>
> Do not attempt to proxy arp the tunnel device.  That way leads to madness.

Whether or not using proxy arp, I recommend using tap device. I
believe there is a little more overhead with tun (higher in the
stack), _especially_ given you want to forward everything, ie DNAT and
SNAT.  tun buys nothing but overhead, compared to tap.

Change dev tun to dev tap in openvpn config.

Not sure why tun device is still useful - perhaps just for legacy clients?


-- 
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/caosgnsqcnbem8ekxuk7wgihbirfqc39papbcqmmh-2+xpn8...@mail.gmail.com

Re: openvpn question

[Gregory Nowak]

On Fri, Aug 23, 2013 at 04:54:46PM -0600, Bob Proulx wrote:
> Uhm... Yes.
> 
> > # ifconfig tun0
> > tun0  Link encap:UNSPEC  HWaddr
> > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> 
> Silly bear!  That is the tun device.  Never tunnel the tun device.
> 
> > The above is from the VPS, with the openvpn connection from the laptop
> > running. This is a tun device, which doesn't require a MAC address at
> > all to function as I understand it.
> 
> Right.  Which does not have anything to do with the way proxy arp is
> set up.
> 
> > I thought this over again with my brain fresher in the afternoon than
> > it was last night, and you are right, it would work in this situation
> > as long as the tun device had a MAC address of course.
> 
> Do not attempt to proxy arp the tunnel device.  That way leads to madness.
> 
> I am going to stop here.  You are good to go.  I am so very short of
> time right now that I don't have more time to play.  Sorry.  You have
> found a perfectly fine way to proceed.  I am sorry I ever mentioned
> any alternative methods.

Ok, though I'll say I'm left scratching my head after reading your
reply. It's as if we're discussing two different things. Maybe we are
for all I know. Don't be sorry you mentioned alternative
methods. Maybe your way of doing something is better than mine, and I
mean this in a general sense. I'd personally rather have a choice than have
no choice. If you feel like elaborating on the above once you have more
time, then by all means please do so.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130824000420.ga6...@gregn.net

Re: openvpn question

[Bob Proulx]

Gregory Nowak wrote:
> Bob Proulx wrote:
> > The device will still have an ethernet address whether you assigned
> > one to it or not.  It is not necessary for you to assign one since one
> > has already been assigned by default.  (From the vendor.  Or in the
> > case of virtual hardware from the software that created the
> > simulation.)
> 
> Uhhm, no. 

Uhm... Yes.

> # ifconfig tun0
> tun0  Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

Silly bear!  That is the tun device.  Never tunnel the tun device.

> The above is from the VPS, with the openvpn connection from the laptop
> running. This is a tun device, which doesn't require a MAC address at
> all to function as I understand it.

Right.  Which does not have anything to do with the way proxy arp is
set up.

> I thought this over again with my brain fresher in the afternoon than
> it was last night, and you are right, it would work in this situation
> as long as the tun device had a MAC address of course.

Do not attempt to proxy arp the tunnel device.  That way leads to madness.

I am going to stop here.  You are good to go.  I am so very short of
time right now that I don't have more time to play.  Sorry.  You have
found a perfectly fine way to proceed.  I am sorry I ever mentioned
any alternative methods.

Bob


signature.asc
Description: Digital signature

Re: openvpn question

[Gregory Nowak]

On Fri, Aug 23, 2013 at 11:16:12AM -0600, Bob Proulx wrote:
> The device will still have an ethernet address whether you assigned
> one to it or not.  It is not necessary for you to assign one since one
> has already been assigned by default.  (From the vendor.  Or in the
> case of virtual hardware from the software that created the
> simulation.)

Uhhm, no. 

# ifconfig tun0
tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:10.28.49.1  P-t-P:10.28.49.1  Mask:255.255.255.0
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:68 errors:0 dropped:0 overruns:0 frame:0
  TX packets:449 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:6880 (6.7 KiB)  TX bytes:97290 (95.0 KiB)

The above is from the VPS, with the openvpn connection from the laptop
running. This is a tun device, which doesn't require a MAC address at
all to function as I understand it.

> Now it is my turn to say that this is a confusing topic but yes it
> really does work.  Since it is fully documented in the proxy arp
> reference above I won't describe it here and make mistakes doing so.
> But you will just have to trust that yes proxy arp does work just fine
> in that situation.

I thought this over again with my brain fresher in the afternoon than
it was last night, and you are right, it would work in this situation
as long as the tun device had a MAC address of course.

> 
> Meanwhile, if you understand the method that you used as you described
> then that is fine too.  It is better because you understand it.  Don't
> let me distract you.  I only mentioned proxy arp because it is one of
> the standard strategies.  But by no means is it the only one.

Thanks for doing so, it's appreciated.

> And I read here that you still don't say what services you are trying
> to enable!  Saying "didn't want the VPS to do any firewalling" doesn't
> mean anything.  That is okay though.  I take that to mean "gotta have
> my freedom, its all about freedom baby, room to breath".  :-)

I want all available services/ports/whatever. I'll deal with
restricting access on the laptop side, rather than on the VPS side.

> 
> But the reason I asked was because often I need a very specific set of
> services such as web or mail or ssh and setting up a dedicated
> connection just for those specific services is often easier and very
> robust.  Such as using a web proxy.  Such as using a tunneled port.
> Other possibilities.

Yes, I have thought of that, and am aware of doing things this
way. Thanks for pointing it out.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130823220511.gb10...@gregn.net

Re: openvpn question

[Gregory Nowak]

On Fri, Aug 23, 2013 at 12:36:58PM +, Bonno Bloksma wrote:
> I have been following this and I think it is getting clear what you are doing 
> but I have lost what the problem is we are trying to resolve.
> 
> If I understand it right your setup is something like:
> 
> VPS has network 1.2.3.0/24 (mask 255.255.255.0)

i Bonno. This is true for the private network used by openvpn. From
what you say below, it seems you are assuming this is the case for the
public network. Unfortunately, my public subnet is only a /29. Getting
a /24 (assuming I can in the first place) would be quite expensive! On
the one hand, having a public /24 means I would be wasting a lot of
IP addresses. This is particularly important given that we're close to
running out of them! On the other hand, having a public /24 means I
could subdivide that, and use a part of those addresses for
openvpn. In that case, the laptop could get a public address, and it
would just be a trivial routing issue at that point, problem solved.

> 
> Somehow you have made sure client always gets same 10.1.1.x number, for 
> instance 10.1.1.3

Yes. I have a directory with per client configuration files for
openvpn. I can use that to push a specific IP address to the laptop
using the common name from its certificate.

> 
> Via iptables you make sure any traffic coming in on the VPS server with 
> destination 1.2.3.3 is going to the VPN ip of the laptop
> And vice versa any traffic coming from the laptop vpn ip get sent out with 
> the source 1.2.3.3
> openvpn server iptables
> iptables -t nat -A PREROUTING -d 1.2.3.3 -j DNAT --to 10.1.1.3
> iptables -t nat -A POSTOUTING -s 10.1.1.3 -j SNAT --to 1.2.3.3
> 

Exactly.

> What is it that is not working? If you think we can solve the problem better 
> by supplying the real configs then please do so.
> 

As I already said, everything is working. The problem is solved. If
there is interest, I can paste the openvpn configs from server/client,
and the interfaces file with relevant iptables rules from the server
to show how I'm doing what I'm doing. Thanks again to everyone for
your help.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130823214417.ga10...@gregn.net

Re: openvpn question

[Bob Proulx]

Gregory Nowak wrote:
> In addition to this, I have iptables rules using the nat table,
> which take traffic which has the laptop's public address as
> destination, and do DNAT on it, changing the destination address to
> be the laptop's private address. I also have a rule doing the
> reverse. This rule takes packets with the laptop's private address
> as source, and does SNAT on them, changing the source address to be
> the laptop's public address, and sends them out eth0.

Okay.  This is much more clear.  And this does now make sense.  There
are many different ways to do things.  The end result of this is very
similar to the way the proxy arp strategy works although in a
different way.

> Again, I do have this functioning. So, whereas before I was writing
> this based on theory, I can assure you it does actually work in
> practice.

As I said if it made sense to you then keep going with it! :-)

> >   Proxy ARP
> >   http://shorewall.net/ProxyARP.htm
> 
> Ok, proxy arp as I understand it requires that network devices have a
> MAC address.

I hesitate to comment further since you have something working.  But
will anyway.

Yes, all network devices will have a MAC ethernet address.

> Since I didn't assign a MAC address to the tun0 device in
> the openvpn config, it wouldn't work.

The device will still have an ethernet address whether you assigned
one to it or not.  It is not necessary for you to assign one since one
has already been assigned by default.  (From the vendor.  Or in the
case of virtual hardware from the software that created the
simulation.)  And therefore proxy arp is still a viable strategy.
(And I like proxy arp better than bridging strategies that I sometimes
see people use to extend networks.  And I like your DNAT/SNAT
configuration that you described above better too.  Your strategy is
good.  Keep going with it.)

> The other part of this is that proxying arp just tells the rest of
> the network on what given interface a particular machine can be
> reached. I think Zenaan and I have established sufficiently in this
> thread that I can't simply give the laptop side a public address
> through openvpn directly, and expect it to just work. So that still
> leaves the laptop with using a private address to go through the
> openvpn gateway. So, I still need NAT, and that's how I have things
> working now.

Now it is my turn to say that this is a confusing topic but yes it
really does work.  Since it is fully documented in the proxy arp
reference above I won't describe it here and make mistakes doing so.
But you will just have to trust that yes proxy arp does work just fine
in that situation.

Meanwhile, if you understand the method that you used as you described
then that is fine too.  It is better because you understand it.  Don't
let me distract you.  I only mentioned proxy arp because it is one of
the standard strategies.  But by no means is it the only one.

> > I read back but didn't see anywhere that you said what services you
> > wanted.  "All" I suppose.
> 
> I did indicate that I didn't want the VPS to do any
> firewalling. Zenaan's response to this was that for it to work, the
> VPS will need to do firewalling. This is correct of course. Perhaps
> if I would have stated I don't want the VPS to do any port blocking
> for the laptop's public address, it would have been more clear.

And I read here that you still don't say what services you are trying
to enable!  Saying "didn't want the VPS to do any firewalling" doesn't
mean anything.  That is okay though.  I take that to mean "gotta have
my freedom, its all about freedom baby, room to breath".  :-)

But the reason I asked was because often I need a very specific set of
services such as web or mail or ssh and setting up a dedicated
connection just for those specific services is often easier and very
robust.  Such as using a web proxy.  Such as using a tunneled port.
Other possibilities.

In any case, glad to see that you have things well in hand and have
something working for you that you are happy with.  Good deal.

Bob


signature.asc
Description: Digital signature

RE: openvpn question

[Bonno Bloksma]

Hi Gregory,

> Gregory Nowak wrote:
>>> The public address assigned to the laptop would actually be 
>>> configured on the VPS,
>> 
>> Hmm...  No.  Sorry.  Doesn't make sense.  The public address assigned 
>> to the laptop would probably be yet another private address behind a 
>> NAT somewhere.
>
> Ok, some confusion here it seems. Both you and I are right in that the 
> laptop's
> public address is assigned to the VPS, and is also in reality yet another
> private address behind a NAT somewhere like you said. I'll explain below,
> since I do in fact have this going as I mentioned in my latest post to
> the VPS crashing thread.

I have been following this and I think it is getting clear what you are doing 
but I have lost what the problem is we are trying to resolve.

If I understand it right your setup is something like:

VPS has network 1.2.3.0/24 (mask 255.255.255.0)
Uplink ip 1.2.3.1
VPS public ip 1.2.3.2
Laptop wants to use 1.2.3.3

dns vps
vps.company.org A 1.2.3.2

vps interfaces file
iface eth0
 address 1.2.3.2
 netmask 255.255.255.0
 gateway 1.2.3.1

iface eth0:0
  address 1.2.3.3
  netmask 255.255.255.0


openvpn server config
port 1194
proto udp
dev tun
server 10.1.1.0/24 255.255.255.0
etc.

openvpn client config
client
dev tun
proto udp
remote vps.company.org 1194
etc.

Somehow you have made sure client always gets same 10.1.1.x number, for 
instance 10.1.1.3

Via iptables you make sure any traffic coming in on the VPS server with 
destination 1.2.3.3 is going to the VPN ip of the laptop
And vice versa any traffic coming from the laptop vpn ip get sent out with the 
source 1.2.3.3
openvpn server iptables
iptables -t nat -A PREROUTING -d 1.2.3.3 -j DNAT --to 10.1.1.3
iptables -t nat -A POSTOUTING -s 10.1.1.3 -j SNAT --to 1.2.3.3

What is it that is not working? If you think we can solve the problem better by 
supplying the real configs then please do so.

Bonno Bloksma


--
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/89d1798a7351d040b4e74e0a043c69d7594e7...@einexch-01.tio.nl

Re: openvpn question

[Gregory Nowak]

On Thu, Aug 22, 2013 at 04:16:13PM -0600, Bob Proulx wrote:
> Gregory Nowak wrote:
> > The public address assigned to the laptop would actualy be
> > configured on the VPS,
> 
> Hmm...  No.  Sorry.  Doesn't make sense.  The public address assigned
> to the laptop would probably be yet another private address behind a
> NAT somewhere.

Ok, some confusion here it seems. Both you and I are right in that the
laptop's public address is assigned to the VPS, and is also in reality
yet another private address behind a NAT somewhere like you said. I'll
explain below, since I do in fact have this going as I mentioned in my
latest post to the VPS crashing thread.

I wrote> 
> > and the VPS would be doing NAT between the private address of the
> > laptop, and the public address assigned to the laptop, but
> > configured on the VPS itself.
> 
> If you understand this then please keep going.  But the description
> doesn't make sense to me.

I read carefully what I wrote above, and I can't think of a way to
make it any clearer. Let me explain how I have this going. On the VPS,
eth0:0 is configured with the laptop's public address. Just to be
clear, the public address here is the one machines on the internet
send traffic to, and the one which traffic from the laptop is coming
from as far as the rest of the internet is concerned. In addition to
this, I have iptables rules using the nat table, which take traffic
which has the laptop's public address as destination, and do DNAT on
it, changing the destination address to be the laptop's private
address. I also have a rule doing the reverse. This rule takes
packets with the laptop's private address as source, and does SNAT on
them, changing the source address to be the laptop's public address,
and sends them out eth0. Again, I do have this functioning. So,
whereas before I was writing this based on theory, I can assure you it
does actually work in practice.

I wrote
> 
> > In a nutshell, the laptop would have a private address assigned to
> > it, but all traffic to and from the laptop would actually be using
> > the public address assigned to it, which itself would be configured
> > on the VPS.
> 
> One of the often hit traps is that people often think, start up DHCP
> on the mobile client.  Then start up the VPN.  Then change the
> routing so that 100% of all traffic goes through the VPN.  Sounds
> great.  Except that it can't work.  The mobile device needs to
> transport the VPN traffic over the non-VPN routed network.  And the
> mobile client needs to have DHCP available which will periodically
> need to interact with the local dhcp server and renew its leases.

Correct. The notion of routing all traffic through the VPN is a
misnomer. It seems you're taking what I said to literally.

> 
>   Routing all client traffic (including web-traffic) through the VPN
>   http://openvpn.net/index.php/open-source/documentation/howto.html#redirect
> 
> I would consider setting up proxy arp on the server.  Set it up to
> proxy for the IP address but do not configure it to own the IP
> address.  Here is a reference.
> 
>   Proxy ARP
>   http://shorewall.net/ProxyARP.htm
> 

Ok, proxy arp as I understand it requires that network devices have a
MAC address. Since I didn't assign a MAC address to the tun0 device in
the openvpn config, it wouldn't work. Yes, I could assign the tun
device a MAC address if I wanted to, I know. The other part of this is
that proxying arp just tells the rest of the network on what given
interface a particular machine can be reached. I
think Zenaan and I have established sufficiently in this thread that I
can't simply give the laptop side a public address through openvpn
directly, and expect it to just work. So that still leaves the laptop
with using a private address to go through the openvpn gateway. So, I
still need NAT, and that's how I have things working now.

> I read back but didn't see anywhere that you said what services you
> wanted.  "All" I suppose.

I did indicate that I didn't want the VPS to do any
firewalling. Zenaan's response to this was that for it to work, the
VPS will need to do firewalling. This is correct of course. Perhaps if I would 
have stated I
don't want the VPS to do any port blocking for the laptop's public
address, it would have been more clear.

Hope this makes more sense now.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130823033322.ga10...@gregn.net

Re: openvpn question

[Bob Proulx]

Gregory Nowak wrote:
> Yes. So from all this, what I said still stands. The laptop would get
> a private address from the VPN.

Yes.

> The public address assigned to the laptop would actualy be
> configured on the VPS,

Hmm...  No.  Sorry.  Doesn't make sense.  The public address assigned
to the laptop would probably be yet another private address behind a
NAT somewhere.

> and the VPS would be doing NAT between the private address of the
> laptop, and the public address assigned to the laptop, but
> configured on the VPS itself.

If you understand this then please keep going.  But the description
doesn't make sense to me.

> In a nutshell, the laptop would have a private address assigned to
> it, but all traffic to and from the laptop would actually be using
> the public address assigned to it, which itself would be configured
> on the VPS.

One of the often hit traps is that people often think, start up DHCP
on the mobile client.  Then start up the VPN.  Then change the
routing so that 100% of all traffic goes through the VPN.  Sounds
great.  Except that it can't work.  The mobile device needs to
transport the VPN traffic over the non-VPN routed network.  And the
mobile client needs to have DHCP available which will periodically
need to interact with the local dhcp server and renew its leases.

  Routing all client traffic (including web-traffic) through the VPN
  http://openvpn.net/index.php/open-source/documentation/howto.html#redirect

I would consider setting up proxy arp on the server.  Set it up to
proxy for the IP address but do not configure it to own the IP
address.  Here is a reference.

  Proxy ARP
  http://shorewall.net/ProxyARP.htm

I read back but didn't see anywhere that you said what services you
wanted.  "All" I suppose.  But if it were just one or two such as a
web service then I would simply proxy that one service.  For example
on the server you could set up Apache with a proxy configuration and
have it use the private vpn address of the mobile client.

# Transparently proxy the pages.
ProxyRequests Off
RewriteEngine On

Order deny,allow
Allow from all

ProxyPass/foo http://10.20.30.40/foo
ProxyPassReverse /foo http://10.20.30.40/foo

Then the world knows about your server.  Your server knows about your
vpn address of your mobile client.  Your server passes web data back
and forth between.  Works well.  I use this all of the time.  (But not
to my mobile devices.  To other servers behind the main server.  But
it is the same thing.)

Bob


signature.asc
Description: Digital signature

Re: openvpn question

[Gregory Nowak]

On Mon, Aug 19, 2013 at 06:27:58PM +1000, Zenaan Harkness wrote:
> Read again this part of the OpenVPN man page which you pasted:
> "the proper usage of --ifconfig is to use  two private
> IP addresses which are not a member of any existing
> subnet which is in use"
> 
> Notice "two private IP addresses", eg 10.1.1.1 and 10.1.1.2.
> Also, it should say elsewhere in the openvpn manpage, that
> these IPs ought be in the same subnet.
> 
> Use of a public IP address here is bound to cause problems, both
> networking, and security problems.

I agree.

> 
> man pppd however (looking at it now) says near the top "The pppd
> daemon works ... to negotiate Internet Protocol (IP) addresses for
> each end of the link".
> 
> The key is, each end has a separate IP.

Yes. So from all this, what I said still stands. The laptop would get
a private address from the VPN. The public address assigned to the
laptop would actualy be configured on the VPS, and the VPS would be
doing NAT between the private address of the laptop, and the public
address assigned to the laptop, but configured on the VPS itself. In a
nutshell, the laptop would have a private address assigned to it, but
all traffic to and from the laptop would actually be using the public
address assigned to it, which itself would be configured on the VPS.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130819225804.ga10...@gregn.net

Re: openvpn question

[Zenaan Harkness]

On 8/19/13, Gregory Nowak  wrote:
> On Mon, Aug 19, 2013 at 01:07:06PM +1000, Zenaan Harkness wrote:
> I wrote:
>> > actually want is to give one ip address out of that /29 to the
>> > laptop. The laptop is an endpoint in itself. It doesn't have any other
>>
>> You need to question yourself, imagine an isolated network of three
>> computers:
>> A <-> B <-> C
>>
>> Lets say A is your isolated "public" computer wanting to access C,
>> your "clandestine" routed laptop.
>>
>> So B has a "public" ip address block, let's say a /29 subnet :)
>>
>> In your thinking, using any technology you choose whatsoever, how
>> would you "assign" one of B's IP addresses to C?
>
> I would put a route in B's routing table to C's interface to B. To
> make this more concrete, on B I would:
> route -A inet add -host public_addr_assigned_to_C iface_connected_to_C

But public_addr_assigned_to_C is already configured on B, it is
assigned to an iface on C.

So if you tried to ping public_addr_assigned_to_C (while in a shell on
B), to see if the iface is up, would that ping packet then have to go
to both the local public_addr_assigned_to_C, as well as be routed
across to C?

And on C, which iface are you going to configure, to listen for
incoming packets to "public_addr_assigned_to_C"?

Think of the problem this way: C runs a webserver on port 80.
It is listening on a particular ip.address:80 for incoming packets.

On which iface is the webserver (on C) supposed to open up
server-listening port 80?

And if that iface is supposed to be configured with
public_addr_assigned_to_C, can you see a problem with having
public_addr_assigned_to_C configured on both that iface on C,
as well as an iface on B?

> I think you might be taking what I said too literally and maybe that's
> why we aren't on the same page. I didn't mean that the laptop would
> literally be an endpoint onto itself.

I don't know what you mean by this sorry.

> The only way that would happen
> is if I disconnected the laptop from any ethernet/wifi networks. I
> only meant to say that the laptop wouldn't be routing to any machines
> attached to it through a second interface (it wouldn't act as a router).

Of course.
I was drawing an analogy with home modem/router, and B.
In this analogy, C is simply one home computer, NATing
through the "modem/router" B.
And you want some reverse NAT, basically, either specific ports, all
all ports on the "modem/router" "public" ip address, ie
public_addr_assigned_to_C.

Some confusion may arise because you say "ip _assigned_ to C", which
is generic terminology - but that ip address is most certainly
"assigned" (by the sound of it, as an address 'alias') to B's public
facing iface.

Your problem is, you can't simultaneously 'assign' the same ip
address, to two iface's, and expect to get no routing problems,
somewhere.

Regarding "public" IPs:

One IP -> one iface.
OR:
One iface -> one or more IPs.

But you can't have one IP -> multiple ifaces.
Will likely cause problems.

>> Well, the VPS needs its own firewalling.
>> Part of that can be routing of packets hitting your "chosen public ip
>> address which really goes to the clandestine server".
>
> Yes, I agree.
>
>> > There wouldn't be any port forwarding or NAT going on
>>
>> Here is perhaps your misunderstanding.
>>
>> VPS has a public IP address, which "looks like" a web server say. In
>> reality this web server is a clandestine server behind a restrictive
>> firewalling regime, which however is able also to connect to the VPS.
>>
>> A connection, means 2 endpoints, each of which needs it's own address
>> (eg MAC address, IP address, or whatever happens with PPP I don't
>> know).
>>
>> So in my diagram above, A of course has a unique public (possibly
>> NATed) ip address, and connects to B, your VPS, which has this
>> specially chosen-by-you IP special-address.
>>
>> And all requests that hit this special-address on B, need to somehow
>> get to machine C. Machine C has its own address, but B cannot
>> ordinarily access C - this is the reason you are using a VPN in the
>> first place.
>>
>> So instead, C connects into B, and a virtual (private-encrypted)
>> network is set up, with TWO ip addresses, for VPS server B, and laptop
>> clandestine machine C.
>
> I agree. Let me [paste the part of the openvpn man page where I see the
> problem. Maybe I'm misunderstanding something:
>
> "--ifconfig l rn
>   Set  TUN/TAP  adapter  parameters.   l  is the IP
>   address of the
>   local VPN endpoint.  For TUN devices, rn is the  IP
>   address  of the remote VPN endpoint.  For TAP devices,
>   rn is the subnet mask
>   of the virtual ethernet segment which is being created
>   or  con
>   nected to.
>
>   For TUN devices, which facilitate virtual point-to-point
>   IP con
>   nections, the proper usage of --ifconfig is to use  two
>   private
>   I

Re: openvpn question

[Gregory Nowak]

On Mon, Aug 19, 2013 at 01:07:06PM +1000, Zenaan Harkness wrote:
I wrote:
> > actually want is to give one ip address out of that /29 to the
> > laptop. The laptop is an endpoint in itself. It doesn't have any other
> 
> You need to question yourself, imagine an isolated network of three computers:
> A <-> B <-> C
> 
> Lets say A is your isolated "public" computer wanting to access C,
> your "clandestine" routed laptop.
> 
> So B has a "public" ip address block, let's say a /29 subnet :)
> 
> In your thinking, using any technology you choose whatsoever, how
> would you "assign" one of B's IP addresses to C?

I would put a route in B's routing table to C's interface to B. To
make this more concrete, on B I would:
route -A inet add -host public_addr_assigned_to_C iface_connected_to_C
I think you might be taking what I said too literally and maybe that's
why we aren't on the same page. I didn't mean that the laptop would
literally be an endpoint onto itself. The only way that would happen
is if I disconnected the laptop from any ethernet/wifi networks. I
only meant to say that the laptop wouldn't be routing to any machines
attached to it through a second interface (it wouldn't act as a router).

> Well, the VPS needs its own firewalling.
> Part of that can be routing of packets hitting your "chosen public ip
> address which really goes to the clandestine server".

Yes, I agree.

> 
> > There wouldn't be any port forwarding or NAT going on
> 
> Here is perhaps your misunderstanding.
> 
> VPS has a public IP address, which "looks like" a web server say. In
> reality this web server is a clandestine server behind a restrictive
> firewalling regime, which however is able also to connect to the VPS.
> 
> A connection, means 2 endpoints, each of which needs it's own address
> (eg MAC address, IP address, or whatever happens with PPP I don't
> know).
> 
> So in my diagram above, A of course has a unique public (possibly
> NATed) ip address, and connects to B, your VPS, which has this
> specially chosen-by-you IP special-address.
> 
> And all requests that hit this special-address on B, need to somehow
> get to machine C. Machine C has its own address, but B cannot
> ordinarily access C - this is the reason you are using a VPN in the
> first place.
> 
> So instead, C connects into B, and a virtual (private-encrypted)
> network is set up, with TWO ip addresses, for VPS server B, and laptop
> clandestine machine C.

I agree. Let me [paste the part of the openvpn man page where I see the
problem. Maybe I'm misunderstanding something:

"--ifconfig l rn
  Set  TUN/TAP  adapter  parameters.   l  is the IP
  address of the
  local VPN endpoint.  For TUN devices, rn is the  IP
  address  of the remote VPN endpoint.  For TAP devices,
  rn is the subnet mask
  of the virtual ethernet segment which is being created
  or  con
  nected to.

  For TUN devices, which facilitate virtual point-to-point
  IP con
  nections, the proper usage of --ifconfig is to use  two
  private
  IP addresses which are not a member of any existing
  subnet which
  is in use.  The IP addresses may be consecutive and
  should  have
  their  order  reversed  on  the  remote  peer.  After
  the VPN is
  established, by pinging rn, you will be pinging across
  the VPN."

So, because I want a point-to-point connection, I have to use two
private addresses that are on the same subnet. That means I have to
assign the laptop a private address, not a public one. For me to map
data from the private address to the public one means doing NAT. By
doing NAT, laptop would have a private address on its end of the VPN,
but any connections laptop made to the internet would look like they
came from the public address assigned to it. That means doing NAT.

> You need to set up firewalling on VPS B, to route all packets to (eg) 
> 10.1.1.2.
> 
> Yes, this is forwarding. Yes this implies a type of NAT for packets
> coming back out of C, over the VPN, through B, back out to the
> "public" Internet (to A).
> 
> But how else do you expect to do this?
> 

Like I showed above. I think we both agree the VPS would need to serve
as a router. My question still stands. If I have to assign private
addresses that aren't part of the same subnet, then the laptop can't
have a public address. I could of course have a statement like:

--config 10.0.0.1 public_addr

in the server config file on the VPS. If I do that though, I see no
way to tell openvpn that the subnet here is /32.

> This is unclear. But the public IP address of course needs to be
> public - it has to appear on the public internet. Your VPS, to make
> use of it, will need to "host" that IP address of course.

Right. On the VPS I would setup routing as I showed above. On the
laptop I would 

Re: openvpn question

[Zenaan Harkness]

On 8/19/13, Gregory Nowak  wrote:
> On Mon, Aug 19, 2013 at 10:26:14AM +1000, Zenaan Harkness wrote:
>> The key I think is the word "routable" which you use.
>
> Yes, exactly.
>
>> 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) 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.
>>
>> It sounds like you want the (laptop) client end of your VPN to be the
>> DMZ host for a particular VPS /29 external address.
>
> Close. The caveat is that the /29 is assigned to the VPS. That means
> that the VPS, network, and broadcast are all on that /29. So, what I

Of course. I understand this.

> actually want is to give one ip address out of that /29 to the
> laptop. The laptop is an endpoint in itself. It doesn't have any other

You need to question yourself, imagine an isolated network of three computers:
A <-> B <-> C

Lets say A is your isolated "public" computer wanting to access C,
your "clandestine" routed laptop.

So B has a "public" ip address block, let's say a /29 subnet :)

In your thinking, using any technology you choose whatsoever, how
would you "assign" one of B's IP addresses to C?

> machines sitting behind it. So yes, in a sense, the laptop is in the
> DMZ, since any firewalling for that single public IP would be done on
> the laptop.

Well, the VPS needs its own firewalling.
Part of that can be routing of packets hitting your "chosen public ip
address which really goes to the clandestine server".

> There wouldn't be any port forwarding or NAT going on

Here is perhaps your misunderstanding.

VPS has a public IP address, which "looks like" a web server say. In
reality this web server is a clandestine server behind a restrictive
firewalling regime, which however is able also to connect to the VPS.

A connection, means 2 endpoints, each of which needs it's own address
(eg MAC address, IP address, or whatever happens with PPP I don't
know).

So in my diagram above, A of course has a unique public (possibly
NATed) ip address, and connects to B, your VPS, which has this
specially chosen-by-you IP special-address.

And all requests that hit this special-address on B, need to somehow
get to machine C. Machine C has its own address, but B cannot
ordinarily access C - this is the reason you are using a VPN in the
first place.

So instead, C connects into B, and a virtual (private-encrypted)
network is set up, with TWO ip addresses, for VPS server B, and laptop
clandestine machine C.

> here. The laptop would have it's own routable public IP address as if
> I had connected it to a modem, and dialed a dial--up provider. My VPS
> would in a sense be an ISP as far as the laptop is concerned.

That's called a "DMZ host".

You need to set up firewalling on VPS B, to route all packets to (eg) 10.1.1.2.

Yes, this is forwarding. Yes this implies a type of NAT for packets
coming back out of C, over the VPN, through B, back out to the
"public" Internet (to A).

But how else do you expect to do this?

>> Set up OpenVPN:
>> OpenVPN will still have two endpoint addresses for each client, and
>> one for the server. 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?
>
> Yes! I was stuck in thinking of things how pppd does them, and it
> didn't occur to me I can map a private address onto a public one. I was
> hoping I could avoid using NAT here, which I know I wouldn't need to
> do if things worked out how I originally planed. But what you propose
> would do the job as well I think. Would
> something like this work on the VPS side?
>
> iptables -t nat -A POSTROUTING --source public_addr -j SNAT
> --to-source 10.0.0.2
> iptables -t nat -A PREROUTING --destination 10.0.0.2 -J DNAT
> --to-destination public_addr

You'll need some diy or help elsewhere sorry.

> Then of course assign the public address I want the laptop to get to
> eth0:0 on the VPS.

This is unclear. But the public IP address of course needs to be
public - it has to appear on the public internet. Your VPS, to make
use of it, will need to "host" that IP address of course.

Good luck
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/caosgnsswthksqmi1boqcqwdnmyzo00vjavdycomif6uyzlh...@mail.gmail.com

Re: openvpn question

[Gregory Nowak]

On Mon, Aug 19, 2013 at 10:26:14AM +1000, Zenaan Harkness wrote:
> The key I think is the word "routable" which you use.

Yes, exactly.

> 
> 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) 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.
> 
> It sounds like you want the (laptop) client end of your VPN to be the
> DMZ host for a particular VPS /29 external address.

Close. The caveat is that the /29 is assigned to the VPS. That means
that the VPS, network, and broadcast are all on that /29. So, what I
actually want is to give one ip address out of that /29 to the
laptop. The laptop is an endpoint in itself. It doesn't have any other
machines sitting behind it. So yes, in a sense, the laptop is in the
DMZ, since any firewalling for that single public IP would be done on
the laptop. There wouldn't be any port forwarding or NAT going on
here. The laptop would have it's own routable public IP address as if
I had connected it to a modem, and dialed a dial--up provider. My VPS
would in a sense be an ISP as far as the laptop is concerned.

> 
> Set up OpenVPN:
> OpenVPN will still have two endpoint addresses for each client, and
> one for the server. 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?

Yes! I was stuck in thinking of things how pppd does them, and it
didn't occur to me I can map a private address onto a public one. I was
hoping I could avoid using NAT here, which I know I wouldn't need to
do if things worked out how I originally planed. But what you propose
would do the job as well I think. Would
something like this work on the VPS side?

iptables -t nat -A POSTROUTING --source public_addr -j SNAT
--to-source 10.0.0.2
iptables -t nat -A PREROUTING --destination 10.0.0.2 -J DNAT
--to-destination public_addr

Then of course assign the public address I want the laptop to get to
eth0:0 on 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.

Yes.

> 
> 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.

I actually want to do firewalling on the laptop. I don't want to
control what goes in/out the laptop on the VPS side.

> 
> Note in either scenario, PPP is not needed as part of the VPN setup.

No, not if I'm doing NAT which I hadn't thought of like I said.

> 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).

Yes.

> 
> 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

Good point. I was planning to simply run openvpn on tcp 1194. I
already have apache running on the VPS, so using port 80 would mean
using yet another address from my /29 for openvpn. That's not
something I want to do though. I believe openvpn has a http proxy
pass-through mode or something like that, where it listens to port 80,
but forwards http traffic somewhere else. I'll have to take a look at that.

> Hopefully the above explanations make it clear for you now?

Yes! I hadn't thought of using NAT as a possibility. Thanks!

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130819020200.ga17...@gregn.net

Re: openvpn question

[Zenaan Harkness]

Sometimes it is easy to be unintentionally ambiguous.
I shall clarify a couple things below...

On 8/19/13, Zenaan Harkness  wrote:
> On 8/19/13, Gregory Nowak  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 g

Re: openvpn question

[Zenaan Harkness]

On 8/19/13, Gregory Nowak  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) 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.

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. 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.

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/caosgnsrqgx67mvno942dr_nr08us00677_u4k9ghrc4dt2s...@mail.gmail.com

Re: openvpn question

[Gregory Nowak]

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. So, for example let's say I'm somewhere with my laptop, and am
connecting from somewhere to the internet. This somewhere would likely
be using dynamic public addresses, and I may want to have my machine
reachable directly over the internet from this somewhere location. If
the dynamic address I'm assigned while connecting from somewhere is
10.0.0.1, I want to be able to connect to the VPS from somewhere, and
get it to assign my laptop a 192.168.1.2 address from that /29 subnet,
which in reality is a publicly routable static IP address. One could
say I'm turning the VPN concept on its head somewhat, though the
scenario I'm describing is still a VPN, but having one endpoint which
is publicly routable. I hope that makes more sense.

> 
> 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

> 
> It seems to me that you want private addresses.  Otherwise how will
> you have a vpn?  If you have public addresses then the communication
> will be public.  If you want private communication then the addresses
> must need be private addresses.

In the typical VPN scenario this is correct. What I actually want is
endpoints where each endpoint has public and private addresses. The
client connects to the server (public). Using ppp would mean that the
client/server would have a private subnet to exchange packets locally
(private). One end of the ppp connection on the laptop would be a
public static IP address (public). I'm not sure how else to explain
this. If someone who understands what I'm talking about can do a
better job of explaining it, then please jump in by all means.

> 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.

Greg


> -- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130818234041.gb14...@gregn.net

Re: openvpn question

[Bob Proulx]

Gregory Nowak wrote:
> Since attempting to establish an ipsec connection is one of the two
> things so far that crashes my VPS (earlier thread on this
> list),

Ouch!

> I've been looking at other alternatives for possible
> workarounds. Let me backup, and describe what I want to do.

> I have a publicly routable /29 subnet with my VPS.

Your vpn will be connected to the public address.  It will establish a
private address for the encrypted traffic.

> 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.

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.

> My original plan to do this was to use ipsec/l2tp, which I know how
> to set up, and I've seen this type of setup in action.

I have used ipsec previously and found the key exchange part on port
udp 500 to be the weak part and a very large amount of trouble.  This
is why I prefer openvpn better.  I have no experience with l2tp.

> It seemed after doing some research that openvpn should be able to do
> this.

Seems reasonable to me.  I use it for my mobile devices.  I use it
between several fixed sites to create VPNs between them.

> After installing openvpn and reading up on it though, I keep running
> into the limitation that server/client must communicate over an
> unused subnet, and both have addresses on that subnet.

That would be the _private_ of the virtual private network. :-)

> Is there something I'm missing here, or won't openvpn in fact do
> what I'm after?

I read through this message and your previous one about the crashing
problems in detail but I wasn't able to discern what you are trying to
say.  Sorry.  I am sure they are clear to you.  The difficulty is
mine.

It seems to me that you want private addresses.  Otherwise how will
you have a vpn?  If you have public addresses then the communication
will be public.  If you want private communication then the addresses
must need be private addresses.

The other ways of using encryption such as https use public addresses
but it is the protocol that is encrypted.  An https:// connection will
use a public address.  But it starts a TLS connection when it
connects.  But if you want http:// to be private then it must do so
over an encrypted private network connection.  This creates the
fundamental difference between the strategies.  Using a vpn means that
all of the unencrypted communication protocols are encrypted by the
transport.  (And redundantly any encrypted protocols will also be
encrypted by the underlying transport making them encrypted twice.)

Please say a few more words describing what you are trying to
accomplish.

> If the answer is no, I suppose I can use openvpn to establish an
> openvpn connection using private addresses, and then do pptp/ppp
> over that connection. Kludgey, but should work in theory. I don't
> trust pptp/ppp by itself over the open net. I know there are other
> options here, like ppp over ssh, but windows is the show stopper
> here as far as I know. Any ideas? Thanks in advance.

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?

Bob


signature.asc
Description: Digital signature

openvpn question

[Gregory Nowak]

Hi all.

Since attempting to establish an ipsec connection is one of the two
things so far that crashes my VPS (earlier thread on this
list), I've been looking at other alternatives for possible workarounds. Let me 
backup, and
describe what I want to do. I have a publicly routable /29 subnet
with my VPS. 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. My original plan to do this was to use ipsec/l2tp, which I know
how to set up, and I've seen this type of setup in action.

It seemed after doing some research that openvpn should be able to do
this. After installing openvpn and reading up on it though, I keep
running into the limitation that server/client must communicate over
an unused subnet, and both have addresses on that subnet. Is there
something I'm missing here, or won't openvpn in fact do what I'm
after? If the answer is no, I suppose I can use openvpn to establish
an openvpn connection using private addresses, and then do pptp/ppp
over that connection. Kludgey, but should work in theory. I don't trust
pptp/ppp by itself over the open net. I know there are other options
here, like ppp over ssh, but windows is the show stopper here as far
as I know. Any ideas? Thanks in advance.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
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/20130818221000.ga14...@gregn.net