[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: Les Mikesell <lesmikesell@xxxxxxxxx>
  • Date: Sat, 21 Jul 2007 16:38:22 -0500

Johannes Schindelin wrote:

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

I don't think you can generally say that one thing is more likely to 
work that another.  Anything that gets through a firewall to an 
address/port that isn't is supposed to already be providing a service is 
a mistake on the firewall admin's part.

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

Then something is still wrong with your setup.  The PTP addresses 
assigned to the tunnel interface should be able to access each other.

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

Yes, only.  IP packets always get to their destinations and back by 
means of routing.  VPNs just provide something that looks like a 
directly connected interface between two things that otherwise wouldn't 
be connected.  Bridging is an inefficient way to avoid some routing 
issues, masquerading is better in the places it works, and making the 
whole network aware of the addresses through the VPN is the more general 

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

I'm not arguing with the concept, I just don't think that all firewall 
admins are likely to make the same mistake that yours did.  I'd consider 
the most likely approach to be to find the person that configures the 
firewall and ask him to open a specific UDP port for you, at least on 
the side that has the fixed address and has to receive the first packet. 
  The other side may be able to get by with a firewall that permits 
outbound packets with a timeout for the matching reply if you use the 
keepalive option.

   Les Mikesell

Openvpn-users mailing list