Our office connectivity is relatively simple and pretty standard for most offices, so I thought I would share our configuration and how we’ve set everything up. I thought a blog post outlining how we have things configured would be useful for others as well as documentation for ourselves.
I recently came by a EdgeRouter Lite from Ubiquiti Networks and we use one of these as our main office gateway/router. In the past we have just used a Linux box but the EdgeRouter is less power-hungry and easily fits into our data cabinets.
Before I get into the details of how we have this router configured, the list below outlines our key requirements from our network.
Three seperate networks:
- Our main office network used by staff workstations, VoIP phones etc…
- A public network for guests to use with both wired & wireless access
- An “access control” network which is used for our IP-connected access control system. Unfortunately, there’s no security on the actual access control devices so a seperate firewalled network is a must.
2 PPPoE BT-provided FTTC connections (from Zen Internet). One used for public traffic and the other used just for our VPN.
Ability to join our office network into our VPN — allowing us to connect to other networks (including our core networks in London).
Equipment used
The EdgeRouter Lite itself (here after referred to as the router).
BT provided VDSL modems.
We use two managed switches on the office which allow us to place any port in the office onto any VLAN we desire.
Our wifi uses the Ubiquiti Unifi access points which support multiple SSIDs on different VLANs with a variety of security options. We have two SSIDs one for staff (using WPA2 Enterprise) and one for guests (WPA2-PSK).
VDSL modems
The VSDL modems provided by BT allow you to simple connect to your ISP using PPPoE. Therefore, we placed each modem on its own dedicated VLAN which is only available to the router.
Router interfaces
In order to configure the router, I am using the CLI interface which I love. The web interface provided by Ubiquiti seems to only include 20% of the actual functionality.
To begin I’ve set up our router with an interface on each of our networks. At present, it is just plugged into a single trunk port on a switch with the main office network untagged and the other VLANs tagged.
interfaces {
ethernet eth0 {
address 10.0.2.1/24
description Office
vif 100 {
address 10.0.3.1/24
description Security
mtu 1500
}
vif 101 {
address 172.16.0.1/24
description Guests
mtu 1500
}
vif 201 {
description "PPPoE Linknet #1"
mtr 1500
}
vif 202 {
description "PPPoE Linknet #2"
mtu 1500
}
}
loopback lo {
}
}
In this configuration, you can see we have set up 5 networks. As there is only one connected physical interface, these virtual interfaces are all within the eth0 interface.
Of course, once you have made these changes, you will need to commit them on the router and any IP you were using for management may be removed.
PPPoe Configuration
Our PPPoE Configuration is pretty simple. The PPPoE configuration itself is placed on the vif for your PPPoE link network, as follows:
interfaces {
ethernet eth0 {
vif 201 {
description "PPPoE Linknet #1"
mtu 1500
pppoe 0 {
default-route auto
firewall {
out {
modify pppoe-out
}
}
mtu 1492
password *******
user-id username@isp
}
}
}
}
You will also notice the interface is set to use the pppoe-out firewall policy. This must also be created:
firewall {
modify pppoe-out {
rule 1 {
action modify
modify {
tcp-mss 1452
}
protocol tcp
tcp {
flags SYN
}
}
}
}
This policy is configured to modify the size of TCP packets so they work with PPPoE connections. Read more about this here.
This is then repeated for vif 202 but using pppoe 1 rather than 0 and with different credentials. The other difference is that default-route is set to none as we don’t want a default route for this connection.
In order to route our VPN traffic over the other PPPoE connection (pppoe1), we will create a static interface route which ensures the IP for our VPN will always go to that connection.
protocols {
static {
interface-route x.x.x.x/32 {
next-hop-interface pppoe1
}
}
}
Configuring NAT
Next up, you’ll need to configure a NAT so that your local subnets have access to the internet over these connections. The following NAT rule will ensure that all traffic destined for pppoe0 will be “natted” as appropriate.
service {
nat {
rule 5000 {
description pppoe0-nat
log disable
outbound-interface pppoe0
type masquerade
}
}
}
You should repeat these as rule 5001 for pppoe1 for the other connection (if you need it). In our case, we don’t actually need to NAT the traffic to our VPN as only our router will be connecting to it.
DHCP Server
Assuming you don’t want every user to manually configure their own IPs on your network, you’ll need to configure the DHCP server. We only need to dynamically allocate addresses for our office & guest networks.
service {
dhcp-server {
shared-network-name office {
subnet 10.0.2.0/24 {
default-router 10.0.2.1
dns-server 8.8.8.8
dns-server 141.1.1.1
domain-name poole.atech.io
start 10.0.2.10 {
stop 10.0.2.199
}
}
}
}
}
You should repeat the shared-network-name section for your public network and set it up to allocate addresses as appropriate. We just use a couple of public DNS servers as nameservers (Google and C&W in this case).
Mid-way testing
You can give all that a test now. Pop a computer onto one of your subnets and using ping and mtr to test you can access the sites you expect and that traffic is routed over the correct paths.
To look at the connected interfaces, just run show interfaces on your router’s CLI.
ubnt@gateway:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 10.0.2.1/24 u/u Office
eth0.100 10.0.3.1/24 u/u Security
eth0.101 172.16.0.1/24 u/u Guests
eth0.201 - u/u PPPoE Link #1
eth0.202 - u/u PPPoE Link #2
lo 127.0.0.1/8 u/u
::1/128
pppoe0 123.123.123.123 u/u
pppoe1 123.123.123.234 u/u
You can also take a look at your routing table with show ip route.
ubnt@gateway:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
K>* 0.0.0.0/0 is directly connected, pppoe0
C>* 10.0.3.0/24 is directly connected, eth0.100
C>* 62.3.84.21/32 is directly connected, pppoe1
C>* 62.3.84.25/32 is directly connected, pppoe0
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.0.0/24 is directly connected, eth0.101
S>* xxx.xxx.xxx.xxx/32 [1/0] is directly connected, pppoe1
The final route in the example output is the static route you provided for your VPN connection on pppoe1.
Setting up OpenVPN
This isn’t a blog post about the specifics of OpenVPN but I will explain where to put your configuration files and how to make the router connect to it.
I have placed my OpenVPN configuration files into /config/auth/ovpn* on the router. I have 4 files:
ovpn.conf- a standard OpenVPN client configuration fileovpn-ca.crt- the OpenVPN CA certificateovpn-client.crt- the OpenVPN client certificateovpn-client.key- the OpenVPN client private key
Once you have put these in place, you should tell the router you’ve done that with:
You can configure OpenVPN itself in the openvpn configuration above but as I already had configuration files, it was quicker to do this for me.
Once you have committed these changes, you should find that your VPN connects and your show interfaces includes a new interface for your VPN connection.
tap0 10.0.5.4/24 u/D
If your OpenVPN server also provides you with routes, you will find that show ip route includes these routes along with a “connected” route for your VPN client subnet.
K>* 10.0.0.0/16 via 10.0.5.1, tap0
C>* 10.0.5.0/24 is directly connected, tap0
K>* 185.22.208.0/22 via 10.0.5.1, tap0
Fixing the Guest Network
Unfortunately, at this point we have a bit an issue with our Guest network. While it can access most of the internet, it will not have access to anything which is routed over the VPN connection. This is because our core network routers know how to route 10.0.2.0/24 back to our office over the VPN but has no idea about the 172.16.0.0/24 network used for the guest network.
We don’t want our guests to access to our network over the VPN so we need to use policy based routed to route traffic different based on its source IP. Fortunately, this is pretty simple. Firstly, we need to create a new routing table for the public network which sends everything over pppoe0.
protocols {
static {
table 101 {
interface-route 0.0.0.0/0 {
next-hop-interface pppoe0
}
}
}
}
Next, we need to create a firewall policy to route traffic from 172.16.0.0/24 to this new routing table.
firewall {
modify public-traffic {
rule 10 {
modify {
table 101
}
source {
address 172.16.0.0/24
}
}
}
}
Finally, we need to set up our public interface on the router eth0 vif 101 to use this policy.
interfaces {
ethernet eth0 {
vif 101 {
in {
modify public-traffic
}
}
}
}
Securing the access control network
We don’t want anyone (except our access control server) accessing the access control network so we need to add a firewall policy for this.
firewall {
name security {
default-action drop
rule 1 {
action accept
description "Allow Management Server"
destination {
address 10.0.3.0/24
}
log disable
protocol all
source {
address xxx.xxx.xxx.xxx
}
}
}
}
As above, this policy needs to be applied to the security interface.
interfaces {
ethernet eth0 {
vif 100 {
out {
name security
}
}
}
}
Finishing up
That’s pretty much all there is to it. There are a couple of other bits which I haven’t documented like IPv6 tunnelling over our VPN and DHCP settings for the Unifi APs.
All in all, the EdgeRouter is a powerful bit of kit and I would recommend them for any office-based situation. The software itself seems to be based on Vyatta who have an excellent reputation for routing. I look forward to having a look at their more professional equipment in the future!