Tux beats windows
Site Informations
SITE ADMINISTRATOR:
Gillen Daniel
VISITORS:
Properly securing VisualOnline's LuxFiber internet access

I finally got my LuxFiber connection!

Time to update my home equipment to reflect the new situation. In this blog entry, I will show you how I reconfigured / expanded my network after the technician left :)

First things first, what is LuxFiber?

Well, in April 2010, Luxembourg's government launched its national strategy for ultra high-speed networks. This includes providing access to optical fiber connections in the entire territory by 2020.

And this week, it was my turn. The following configurations are currently sold by ISPs:

- 30 Mbits down / 10 Mbits up (available over fiber and copper)
- 100 Mbits down / 50 Mbits up (available over fiber and copper)
- 200 Mbits down / 100 Mbits up (available only over fiber)
- 1000 Mbits down / 500 Mbits up (available only over fiber)

And guess what, I went for the last option :)

So, how does it work technically?

In my case, it's real FOTH (Fiber Optic To Home). A technician came and installed a media converter (Fiber to Ethernet) and attached an also provided AVM Fritz!Box 7490 to it. The Fritz!Box does PPPoE for the Internet connection and also provides POTS and ISDN connections for my telephones.

The Fritz!Box receives a dynamic IPv4 and IPv6 address from the ISP. A DHCP server serves local clients with a local IPv4 (NATed) and a globally valid IPv6 address.

Sounds great! What would you change in that setup?

Great, sure!

First, I like keeping my local PCs local. They shouldn't be accessible directly from the Internet.

Second, I don't trust the partly closed source crapware installed on those Fritz!Boxes. Never ever should such a box be the only defense line between me and the Internet.

Third, I don't trust the partly closed source crapware installed on those Fritz!Boxes..... I think you got that point now ;-)

Time for changes: The plan

My first step was calling my ISP and asking for more details on the PPPoE connection. And here is already why I have chosen VisualOnline as ISP. If you call them, you don't end up in a call center with a person having no clue. The friendly guy at the other end told me that they use PPPoE over VLAN ID 35. Username and password would be the ones I had gotten in my welcome letter. He also told me that the telephony part uses SIP/RTP and that the server is tel.lu. Username and password of that would also be on my welcome letter. Now that's a competent answer!

A plan started to gell in my mind. I would connect my firewall directly to the media converter and do the PPPoE stuff on my own.

In order to keep my internal PCs internal, I would use IPv4 and IPv6 NATing.

And while getting rid of that Fritz!Box would be nice, I decided against that idea for now. It's convenient to use it solely as VOIP client as I still have ISDN phones at home and I can connect them directly to it. It will be replaced by some sort of Asterisk server in the near future :) But to make sure that evil box can't hurt me, it would have to be in a DMZ behind the firewall but separated from my internal network.

In the end, I came up with the following network structure. The untrusted Fritz!Box has been transferred to a closely monitored DMZ without the possibility to connect to any internal PCs.

Time for changes: The prerequisites

In my opinion, there is only one OS to choose when you need a stable and secure network device (like a firewall / router / webserver) and that is OpenBSD. Installation was quick and hassle free as always. The configuration was mostly easy, except for that SIP/RTP client behind a NAT which took me some time to get it to work. VOIP hates NAT!

There are only two things you have to watch out for:

- Using IPv6 auto-configured interfaces and non auto-configured interfaces is broken since OpenBSD version 5.6. A patch exists in -current and will be available in version 5.9. So you will have to install a current snapshot to get the following configuration to work.

- Remember that PPPoE works over VLAN? Well, our ISPs infrastructure seems sort of broken in regard to the usage of the IEEE 802.1p class of service field. The only allowed value is 0 and OpenBSD will set this always to 3. The exact phrase on the OpenBSD mailinglist when I hit that problem first was "talk to the ISP and tell them they're on drugs". The only solution to this currently is applying the following minor diff to the OpenBSD kernel:

Index: sys/net/if_vlan.c
===================================================================
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.142
diff -u -p -r1.142 if_vlan.c
--- sys/net/if_vlan.c   13 Sep 2015 10:02:36 -0000      1.142
+++ sys/net/if_vlan.c   20 Sep 2015 17:23:20 -0000
@@ -272,8 +272,7 @@ vlan_start(struct ifnet *ifp)
                 */
                } else if ((p->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
                    (ifv->ifv_type == ETHERTYPE_VLAN)) {
-                       m->m_pkthdr.ether_vtag = ifv->ifv_tag +
-                           (prio << EVL_PRIO_BITS);
+                       m->m_pkthdr.ether_vtag = ifv->ifv_tag;
                        m->m_flags |= M_VLANTAG;
                } else {
                        struct ether_vlan_header evh;
@@ -281,8 +280,7 @@ vlan_start(struct ifnet *ifp)
                        m_copydata(m, 0, ETHER_HDR_LEN, (caddr_t)&evh);
                        evh.evl_proto = evh.evl_encap_proto;
                        evh.evl_encap_proto = htons(ifv->ifv_type);
-                       evh.evl_tag = htons(ifv->ifv_tag +
-                           (prio << EVL_PRIO_BITS));
+                       evh.evl_tag = htons(ifv->ifv_tag);
                        m_adj(m, ETHER_HDR_LEN);
                        M_PREPEND(m, sizeof(evh), M_DONTWAIT);
                        if (m == NULL) {

Time for changes: Network configuration

Hassle free as always on OpenBSD. Here are my 5 /etc/hostname.if files:

/etc/hostname.em0 (DMZ interface)

inet 192.168.1.1 255.255.255.0

/etc/hostname.em1 (Connected to the media converter)

up

/etc/hostname.em3 (Internal network)

inet 192.168.0.1 255.255.255.0
inet6 fd00::192:168:0:1/112

/etc/hostname.vlan35

vlan 35 vlandev em1 up

/etc/hostname.pppoe0

!/sbin/ifconfig em0 up
!/sbin/ifconfig vlan35 up
inet 0.0.0.0 255.255.255.255 NONE \
        pppoedev vlan35 \
        authproto pap \
        authname "username@vo.lu" \
        authkey "password"
dest 0.0.0.1
inet6 autoconf
!/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
!/sbin/route add ::/0 -ifp pppoe0 fe80::

Time for changes: VOIP configuration

As told above, VOIP hates NAT, so I installed the siproxd SIP/RTP proxy on the firewall. The only two changes I had to make to the sample config file are:

if_inbound  = em1
hosts_allow_reg = 192.168.1.0/24

Time for changes: Firewall configuration

And here is a sample firewall ruleset for my scenario. Unfortunately, I have to open some ports for SIP/RTP to work. The tel.lu VOIP server uses multiple IPs so I was only able to tighten those ports loosely to their current IP range. Further inspection is needed to tighten this even more. Or another call to my ISP maybe?

/etc/pf.conf

# OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# Macros
#
#   Interfaces
#
#     External interface (Connected to the internet)
if_ext="pppoe0"
#     DMZ interface
if_dmz="em0"
#     Internal interface
if_int="em3"
#     Interfaces to skip firewalling on
skip_if="{ lo tun bridge em1 vlan35 }"

#
#   Networks
#
#     tel.lu VOIP servers
net_tellu="85.93.219.0/24"

#
#   Servers
#
#     PBX
ip_pbx="192.168.1.2"

#
#   Other stuff
#
#     Allowed ICMPv6 types
icmp6_types="{ 1, 2, 133, 134, 135, 136 }"

#
# Pf options
#
#   Gather stats from $if_ext
set loginterface $if_ext
#   Blocked packets should be silently dropped
set block-policy drop
#   No firewalling on $skip_if interfaces
set skip on $skip_if
#   Keep states for a very long time
set optimization conservative

#
# Match rules
#
#   Packet normalisation
match in all scrub (no-df random-id reassemble tcp)
match on $if_ext scrub (max-mss 1440)
#   Nat
match out on $if_ext from $if_int:network to any nat-to ($if_ext)

#
# Filter rules
#
#   By default, block everything in and pass everything out
#
block in log
pass out quick

#
#   $if_ext inbound / outbound
#

# Allow some ICMP messages
pass in quick on $if_ext inet proto icmp icmp-type 3 code 4

# Allow some ICMPv6 messages ($icmp6_types, Time Exceeded, Parameter Problem)
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type $icmp6_types
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type 3 code 0
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type 3 code 1
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type 4 code 0
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type 4 code 1
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext), ff02::1/16 } icmp6-type 4 code 2

# Allow SIP
pass in on $if_ext inet proto udp from $net_tellu to ($if_ext) port 5060

# Allow RTP
pass in on $if_ext inet proto udp from $net_tellu to ($if_ext) port 7070:7089

#
#   $if_dmz inbound / outbound
#

# Explicitly block broadcasts
block in log quick on $if_int inet from { 192.168.1.0 192.168.1.255 255.255.255.255 }

# Pass NAT traffic (_ONLY_ ipv4)
pass in on $if_dmz inet from $if_dmz:network to { !($if_int) !($if_dmz) !(egress) }

# Allow SIP from PBX
pass in on $if_dmz inet proto udp from $ip_pbx to ($if_dmz) port 5060

#
#   $if_int inbound / outbound
#

# Explicitly block broadcasts
block in log quick on $if_int inet from { 192.168.0.0 192.168.0.255 255.255.255.255 }

# Allow ICMP and ICMPv6
pass in quick on $if_int inet proto icmp
pass in quick on $if_int inet6 proto icmp6

# Pass NAT traffic in
pass in on $if_int from $if_int:network to { !($if_int) !($if_dmz) !(egress) }

# Allow SSH
pass in on $if_int proto tcp from $if_int:network to ($if_int) port 22

Conclusion

Well, I'm happy with this setup for now. As written above, I will replace the Fritz!Box in the near future with some open source solution but for now, everything works as expected and I think it's now a lot securer than it was before :)

Btw, if you wonder what my connection can handle, send me your IP and I'll send you some packets back ;) No, seriously, I was unable to test with any online speed test. They all seem to just not handle so much traffic right now. Some even stopped right at 100MBits! Fortunately, I have access to a server that has a 10GBit connection. Using multiple up and down streams, I was able to reach 857MBits down and 483MBits up. I think that's quite ok for my Internet access at home :-p

Have fun!