If you really want to make public each vpn client get a public ip, i'd do something in the lines of:
first nat your public ip's to something in your vpn range, keeping in mind that each vpn client only has a /30 subnet.
secondly create /etc/openvpn/ccd/clientA
this file contains a line that pushes a ip config to clientA
ifconfig-push 10.9.0.1 10.9.0.2
That will force clientA to always get
10.9.0.1, and making it possible for you to nat the ip's
On Nov 7, 2007 4:26 PM, Cirroc <cirroc@xxxxxxxxx
I've been running into the wall with an OpenVPN installation, and was
hoping someone might have experience or ideas on how to figure out the
best way to proceed.
I've been hitting my head against the wall on this for a while, but
perhaps someone more experienced with OpenVPN can make this a bit easier.
We're trying to support a legacy application, originally written in the
mid 1990s. The Application is designed to talk directly peer to peer- It
connects to the other machines directly.
We're working on replacing the legacy system, but until we do, it's the
world we're stuck with, and we're trying to make it work at all.
Essentially, we need any arbitrary machine to be able to have a public
IP on the real internet, so both users WITH the vpn or WITHOUT the VPN
can see them.
Our first attempt to fix this involved using OpenVPN to put them all on
one virtual LAN. Each person who installed our test OpenVPN client was
given a 10.8.0.X address, and could connect to all the other machines.
This functioned well, and we were excited, but we'd like to go one step
The problem is that currently, people who don't have the VPN client
installed can't connect to those who do.. We'd like to set up OpenVPN to
hand out publicly routable IP addresses, such that the outside world can
then contact each user running the VPN client.
We've rented a virtual server for testing, that has a series of IP
addresses in the form of venet0, 1, etc, as shown below.
venet0:0 Link encap:UNSPEC HWaddr
inet addr:XX.XX.XX.XXX1 P-t-P:XX.XX.XX.XXXX
venet0:1 Link encap:UNSPEC HWaddr
inet addr:XX.XX.XX.XXX2 P-t-P:XX.XX.XX.XXXX Bcast:XX.XX.XX.XXXX
venet0:2 Link encap:UNSPEC HWaddr
inet addr:XX.XX.XX.XXX3 P-t-P:XX.XX.XX.XXXX Bcast:XX.XX.XX.XXXX
venet0:3 Link encap:UNSPEC HWaddr
inet addr:XX.XX.XX.XXX4 P-t-P:XX.XX.XX.XXXX Bcast:XX.XX.XX.XXXX
We'd love to have someone work with us to help set this up.
An example of how this might be used:
user A isn't behind a firewall.
user B is behind a Linksys NAT device, with the ports forwarded
user C is behind a Linksys NAT device, without the ports forwarded.
user D is behind a different Linksys NAT device, without the ports
Currently, users A and B can connect to one another all they want. The
program works, just like it did in the mid 90s. No firewalls get in the
If one of them tries to connect to user C, their connection is blocked
when the program tries to do the P2P connection to them.
If B and C try to connect, it doesn't work at all.
Instead, I've currently set up a test VPN, so that they get a 10.8.0.X
address.. User C and D install this VPN and can connect to each other,
since they are behind the LAN, but user B and A can't connect to either
of them, since their IP isn't public.
If we gave user C and D a public IP when they install the VPN, they can
connect to A or B easily, but still talk with each other (C and D).
Does that make sense?
We're working on cleaning up this mess by re-writing and refactoring,
but until it's set up, we need a way to make it work. There have been
guides to setting up the port forwarding for years, but that's too
complex for most of the users.
With a VPN package, I can have them all share a key, so it's just a
point and click install. I'm not worried about the security of it, since
all you can do through the VPN is use the ports which we're leaving open
for the program.
Essentially, since all the traffic passes through the server, I can use
iptables to restict the traffic to only the few known-good ports that
the application needs.
I'd love any help or thoughts in setting this up.. It feels so close,
yet so frustratingly far away.
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Openvpn-users mailing list
Life is ten percent what happens to you and ninety percent how you respond to it.
+27 12 990 4272
+27 72 620 0070
Linux User #452990
Linux Machine #360914