[MLB-WIRELESS] possible vpn and public ip address allocation option
mw at freenet.net.au
mw at freenet.net.au
Tue Mar 16 09:39:18 EST 2010
> At the last couple of melbourne wireless meetings, there has been
> discussion of providing some public IP addresses, and also for providing
access to the melbourne
> wireless network from outside (linking unconnected nodes via the
> I have been looking at the router board, and it appears it would be ideal
> to implement much of both of these options with.
I agree - routerOS is an ideal VPN server. It can support EoIP tunnels plus
pptp, l2tp, openVPN and IPSec so there is a range of protocols that can be
chosen by the remote node.
> My suggestion is to use it's pptp server functionality. --With it's
> encryption turned off--.
> pptp is widely available, and simple, (and security hopefully isn't a
> issue here yet...)
> The router board has a simple to use ppp user manager, (and will also use
> radius, if
> available) You can create different profiles, and set up users as
If RADIUS is to be used, then probably pptp and/or l2tp would be the best
option since it is possible to hook up a radius server to the MW database so
that user/password can be syncronised and addressing can be dynamically
> So an internal user, can configure their router to dial out to the router
> board using pptp and it
> will give them a static public ip address based on their username.
If the client is a routerOS system, it can even be set up to use a
dial-on-demand VPN client that will pick up a connection to the VPN server
in the case that the wireless link fails. OSPF data can even be issued over
the VPN so that the entire MW network can have failover connectivity to the
> A single public IP address will be sufficient for many users, and this
> hands them out quite
> efficiently (being a /32 address), and saves a little routing space, as
> it's tunnelled.
Actually, there is no real need for a public IP address at the client - only
one public address for the VPN server is required. The VPN client interface
need only be a private address on the MW range (10.10.0.0/16)
> Larger groups of public addresses can be handled by routing them normally.
> (Nothing to do with the router board)
> An external user, can dial in to the router board using pptp. It would
> them a dynamic 10.10.x.x address (once again based on their username),
they would then
> have full access to the internal melbourne wireless network.
> There is some potential MTU issues, but the routerboard can be configured
> to adjust the tcp MSS, so it shouldn't be a major problem.
> The routerboard would be behind the main melbourne wireless internet
Actually, it would ideally present at least one interface to an internet
gateway - either direct to the border network, or via 1:1 nat via the
connected router. Any location would do, at any node, but obviously a node
with reasonable profile and connectivity would be best.
> Amount of infrastructure required (to get a basic system working): 1 *
> routerboard. pptp client required at users end.
I have already offered a donation of one routerBoard for this purpose.
There only needs to be some decision at the committee level as to which
model is preferred (choice of RB450G, RB750G, RB/483AH, or other)
> There may be some (hopefully minor) changes required on the main internet
> access router.
There should be no changes required at all.
> I have used the rb450g, and it's quite brisk, (I couldn't guess how many
> active users you could reasonably hang off it at once though)
RB/450G should comfortably handle a couple of hundred connections.
> You also get some basic per user usage information, (And presumably more
> radius is available)
We just need someone with some background using something like freeradius
server to integrate the current member database and we'd be away.
More information about the Melbwireless