[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] Success story (and some small complaints about the HOWTO)

  • Subject: Re: [Openvpn-users] Success story (and some small complaints about the HOWTO)
  • From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
  • Date: Sat, 21 Jul 2007 22:03:45 +0100 (BST)


On Sat, 21 Jul 2007, Les Mikesell wrote:

> Johannes Schindelin wrote:
> > - on the server side, set up the forwarding rules (as root):
> > 
> > 	$ echo 1 > /proc/sys/net/ipv4/ip_forward
> >         $ iptables -A INPUT -i tun0 -j ACCEPT
> >         $ iptables -A FORWARD -i tun0 -j ACCEPT
> >         $ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > 
> >   If you do not know what this is all about, it might be a good idea to 
> >   google for it first.  (Yeah, I know this is lame, but I am just 
> >   outlining what a HOWTO should contain from my POV.)
> Note that OpenVPN itself is cross platform and those particular commands 
> are Linux specific.

That is what I mentioned in the text you did not quote.  Both sides are 
supposed to be Linux boxes.

> >   If the OpenVPN connection does not work, these settings are most likely 
> >   wrong or incomplete.
> > 
> > - Set up the server configuration on a port that your restricted box can 
> >   connect to (such as 80 (HTTP), or 443 (HTTPS)):
> > 
> > 	cat > server.conf << EOF
> > 	proto tcp-server
> You probably only want to use TCP here in cases where that is all you 
> can get through some other firewall.

If you want to get it running, it is much better to try TCP first.  You 
can always try (pretty quickly) if UDP works, too.  But UDP is blocked 
just too often.

> > 	port 443
> And you wouldn't be able to do that on a box running a web server with 
> https.

Again, if you want to get started, to have a running VPN, it is better to 
try things that are more likely to succeed first.  I agree that it is 
suboptimal to take away the HTTPS port, but if that is the only port you 
can use (like in my case), what other options are there?

>  > It took me quite a while to realise that many parts were actually
>  > working, but I needed to _masquerade_ the client.  AFAICT this was not
>  > mentioned anywhere, and I felt like a complete moron that the
>  > QuickStart did not work for me.
> You should have realized the tunnel itself was working when you could 
> ping the endpoint address

Well, guess what: I could not.

> ... or connect to services on the server using that address.  Getting 
> anywhere else and back is a matter of routing.

Not only.  But the documentation suggests that.

> I agree that masquerading with the server's ethernet address is likely 
> to be the easiest way to handle routing, but you can't assume that it is 
> always the right approach - or that the server only has one ethernet - 
> or that it is running Linux.

See above.  I was only interested in Linux, and it was too hard to set up.

> > - IMHO it is wrong to start with UDP, since that is much more likely
> >   blocked than anything else.  That happened to me, too.
> UDP will often work through a firewall if the destination has a known 
> address and you use the keepalive option.  There's no particular reason 
> to expect any inbound TCP ports to be open to a host that isn't running 
> a service on those ports either.

Like I said.  UDP is often not an option.

For me, it was a really frustrating experience that _nothing_ worked as 
suggested.  Nothing.  I had to change many options until it finally 
worked.  IMHO it is a better approach (i.e. much less frustrating) to 
suggest something which is _more_ likely to work, and then tell people "ah 
yeah, if possible, try UDP, too, as it is faster".

It is always easier to start with a working setup that with a non-working 


Openvpn-users mailing list