Hey Lonnie,

I've always just chosen TCP since I've found it easier in general to get
around possible NAT issues - especially in more heavily fortified networks
like hotels. My OpenVPN implementation is more for remote client
connections (laptops, tablets, phones, etc.) then a direct Server-to-Server
non-NAT'd implementation (though I use it for that too). I imagine in those
cases, UDP would be a better transport choice since there would be less
overhead and little to gain from TCP. Definitely a valid point - so no
disagreement there :p.

Regarding the other stuff, I didn't know offhand if the persist variables
were default or not, I've always just included them anyway.

I actually erred in pasting that MTU setting. That's what I had in my
config, which I just copy/pasted in my earlier email, but I only had that
in there because I was messing around with the settings and using it to
test something a few months ago. I forgot to change it back (though it
never caused any issues). But you (and Darrick) are correct that it's
mostly unnecessary and could actually cause a problem in and of itself.
Sorry about that.

-James


On Fri, Mar 30, 2012 at 3:22 PM, Lonnie Abelbeck
<li...@lonnie.abelbeck.com>wrote:

> Hi James and Tom,
>
> First, I can't say I ever disagreed with James, but I guess there is
> always a first time. :-)
>
> I'd use UDP as the transport Protocol, not TCP.  TCP over TCP can lead to
> jitter problems.  So unless there is some upstream restrictions, I'd
> suggest using Protocol: UDP
>
> No need to define...
> --
> persist-key
> persist-tun
> --
> since they are set by default.
>
> I'm not sure about setting link-mtu 1560, I'd leave that out.
>
> Tom, if your goal is to connect box A, B, C ... local subnets with each
> other's subnets, and each box has a static IP address, I'd suggest using
> "IPsec Peers" VPN type using a strong Preshared Key.  Use the web
> interface, use your *existing* local subnets and define the associations
> via the public IP address of the boxes.  Each tunnel/association on one box
> is the mirror of the tunnel/association on the other box.  If you have 4
> boxes, you would define 3 tunnel/associations on each box.  The routes will
> be automatically created. Use the default options as a start, keep them all
> the same for all the boxes.  Of course try to just get two talking at
> first.  Use a Local-Host of either 0.0.0.0 or it's external IP address.
>
> My 2 cents.
>
> Lonnie
>
>
> On Mar 30, 2012, at 11:13 AM, James Babiak wrote:
>
> > Well, since the server is bricked, it sounds like you won't be able to
> do anything until Monday.
> >
> > But once you get access back to it, if you want to proceed through the
> GUI, you can try using the settings I pasted earlier- under OpenVPN Server
> configuration.
> >
> > In summary:
> > (Tunnel Options)
> > Protocol: TCP (This is preferable to UDP)
> > Port: 1194 (The default, but could be changed if you want to - just make
> sure it's the same on clients too)
> > Compression: Yes (Optional, but suggested)
> > Cipher: AES-128-CBC (You can set this to whatever you want, but make
> sure it's all consistent. The higher the encryption, the more taxing it
> will be).
> > Device: tun0 (What the interface will be created for this tunnel on the
> server)
> > Raw Commands: ifconfig-pool-linear
> >
> > (Server Mode)
> > Network: ***This is the network you want to be running over the TUNNEL.
> Make sure you chose something not being used by any other network
> interface. This might have been what caused the bricking earlier, if you
> set it the same as the WAN interface. It should be in the format of X.X.X.X
> Y.Y.Y.Y, with X as the network address and Y as the subnet mask (ie:
> 172.21.0.0 255.255.255.0)***
> > Push: This is where you will put in any options you want pushed to the
> remote clients. If you want to route two networks behind the server,
> specify them here. for example:
> >
> > route 172.20.0.0 255.255.255.0
> > route 172.30.0.0 255.255.255.0
> > dhcp-option domain abc.com
> > dhcp-option DNS 172.20.0.1
> >
> > The above should be self explanatory, but you are basically pushing the
> routes to those networks down, as well as the dhcp options. Customize as
> necessary.
> >
> > The route commands above will handle routing traffic FROM clients TO
> networks behind the server. If you need to support routing traffic FROM
> networks behind the server TO networks behind the client, you will need to
> add the following lines as well:
> >
> > client-to-client
> > client-config-dir /mnt/kd/openvpn/ccd
> >
> > You will then need to make the client-config-dir directory, and add
> per-client files (using the client name specified below) in that directory,
> with the networks that those clients have. Such as this:
> >
> > ccd # cat client1
> > iroute 192.168.10.0 255.255.255.0
> >
> > Again, that part is only necessary if you need that functionality.
> >
> > Save all of that, and then make sure to generate a server certificate
> and key.
> >
> > Once that is done, you can generate client certs/keys, and setup the
> client side configuration. You can use those certs/keys on a computer to
> test out openvpn connectivity first, just to make sure the settings are all
> correct. This way, if you run into problems on the client side, you know
> the problem is with the client side.
> >
> > The client side settings should mimic the server settings. The "Device"
> option can be whatever you want to use on the client though, it doesn't
> need to match. My raw commands are:
> >
> > link-mtu 1560
> > persist-key
> > persist-tun
> >
> > Remote server is the hostname/IP of the VPN server. Remote network
> should be the network you chose on the Server side above.
> >
> > You will need to upload (through the GUI) the client CA/Cert/Key you
> created for each client under the server side client generator. These need
> to be unique for each client.
> >
> > On the Server Network Configuration GUI page, you will need to go to the
> Firewall Configuration and enable OpenVPN access to whatever LAN interfaces
> you need to allow them to access.
> >
> > Good luck, and let us know if you run into any problems.
> >
> > -James
> >
> > On Fri, Mar 30, 2012 at 11:37 AM, Tom Chadwin <
> nnpait.servi...@googlemail.com> wrote:
> > > Are you trying to just create an encrypted tunnel between the two
> Astlinux
> > boxes for inter-server communication, or are you trying to route traffic
> > across it as well? Are there certain networks you do/don't want to route
> > traffic across?
> >
> > Connect two (well, four) subnets. We have a head office and three
> satellite
> > offices, so this solution would allow clients at the remote sites to
> access
> > central services and allow the central site to back up to the remote
> sites.
> >
> > > I have set this up in the past, and it is fairly simple and
> > straightforward. It's actually easier in some ways to do it manually (ie:
> > not through the GUI). It's been a while since I did it though, so I don't
> > remember the precise "step-by-step" instructions.
> >
> > This is what I need - step-by-step.
> >
> > > I thought there was a How-To guide on the docs.astlinux.com site, but
> I
> > couldn't find it when I just briefly looked.
> >
> > Ditto. I've found an old thread on this list, but it is far from an
> idiot's
> > guide. Given my performance so far, an idiot's guide is plainly what I
> need.
> >
> > > How did you brick the server? That shouldn't have happened.
> >
> > I wish I knew. At the server end, I created cert/key and saved some
> initial
> > (largely default) settings. Hit save, and the box disappeared. I will
> have
> > to hook up a serial cable on Monday when I am back in the office.
> >
> > Tom
> >
> >
> > On Fri, Mar 30, 2012 at 10:18 AM, Tom Chadwin
> > <nnpait.servi...@googlemail.com> wrote:
> > Hello all
> >
> > Would it be too much to ask for someone to give the full steps, from
> start
> > to finish, to set up a VPN between two Astlinux boxes? I'd prefer
> OpenVPN. I
> > need to know what to do (with no shorthand) on both server and client
> ends.
> > While I have some knowledge of VPN (IPSEC, L2TP, and OpenVPN), it's very
> > amateur, and gleaned from GUI front ends to systems.
> >
> > I've had a go at starting to config the server end with no prior
> knowledge,
> > and have bricked a remote box in the process. Hence this request.
> >
> > Thanks
> >
> > Tom
> >
> >
> >
> ----------------------------------------------------------------------------
> > --
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
> > _______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> > pay...@krisk.org.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
> > _______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
> >
> >
> ------------------------------------------------------------------------------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> >
> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to 
pay...@krisk.org.

Reply via email to