Forums

Resolved
0 votes
As was mentioned last year we are planning to update our existing network setup in a remote office and replace an aging firewall appliance,an aging ClearOS and a Windows file server with a single ClearOS. There is currently an OpenVPN failover tunnel.

Attached are two images showing current setup and a tested, but not installed, configuration.

The new ClearOS is passed its routes via OSPF from the WAN router and in the event those routes disappear traffic is routed over the OpenVPN tunnel.

I will post up a detailed how-to in the near future.
Attachments:
Wednesday, April 26 2017, 11:03 AM
Share this post:
Responses (3)
  • Accepted Answer

    Monday, May 01 2017, 08:07 AM - #Permalink
    Resolved
    0 votes
    As promised attached are the instructions on how to use a ClearOS with dynamic routing and also with a failover OpenVPN tunnel in the event the WAN link goes down.

    Current Configuration
    Details
    LAN PCs
    10.10.8.0/22
    Default Gateway 10.10.11.1

    Firewall Appliance
    10.10.11.1/22
    192.168.255.210/29
    Static route 10.0.0.0/8 via 192.168.255.208
    Public IP

    WAN Router
    192.168.255.208/29
    Default Gateway 192.168.255.209
    10.0.0.0/8 routes via OSPF

    ClearOS
    eth1	10.10.11.4/22	VLAN 100
    eth1 192.168.255.209/29 VLAN 370
    eth2 Public IP

    OpenVPN
    Tunnel to HO for 10.0.0.0/8

    New Configuration
    Details
    LAN PCs
    10.10.8.0/22
    Default Gateway 10.10.11.1

    WAN Router
    192.168.255.208/29
    Default Gateway 192.168.255.209
    10.0.0.0/8 routes via OSPF

    ClearOS
    eth1	10.10.11.1 and 10.10.11.4/22
    eth2 192.168.255.209/29
    eth3 Public IP

    10.0.0.0/8 routes via OSPF from WAN router
    Low priority static route for 10.0.0.0/8 via OpenVPN

    OpenVPN
    Tunnel to HO for 10.0.0.0/8

    Configure ClearOS for Dynamic Routing
    Site-A: 10.10.8.0/22 LAN
    Site-B: 192.168.10/25 WAN LAN
    192.168.255.208/29 WAN Stub


    This documentation has been lifted from:
    Turn CentOS Box Into OSPF Router using Quagga

    Install Quagga on ClearOS
    We start the process by installing Quagga using yum.
    yum install quagga

    On ClearOS 6 it is:
    yum --enablerepo=clearos-centos install quagga

    On ClearOS 7, SELinux prevents /usr/sbin/zebra from writing to its configuration directory by default. This SELinux policy interferes with the setup procedure we are going to describe, so we want to disable this policy. For that, enable the 'zebra_write_config' boolean as follows.
    setsebool -P zebra_write_config 1

    Without this change, we will see the following error when attempting to save Zebra configuration from inside Quagga's command shell.
    Can't open configuration file /etc/quagga/zebra.conf.OS1Uu5.

    Configuring Zebra
    We start by creating a Zebra configuration file, and launching Zebra daemon.
    cp /usr/share/doc/quagga-0.99.15/zebra.conf.sample /etc/quagga/zebra.conf
    chown quagga:quagga /etc/quagga/zebra.conf
    service zebra start
    chkconfig zebra on

    Launch vtysh command shell:
    vtysh

    The prompt will be changed to:
    frm-srv-fw1# 

    which indicates that you are inside vtysh shell.
    Configure the log file for Zebra and specify log file location, then exit the mode:
    configure terminal
    log file /var/log/quagga/quagga.log
    exit

    Save configuration permanently:
    write 

    Next, we identify available interfaces
    Check with web GUI which interface is which, ClearOS v7 uses new format names. enp0S25, enp7s4 and ens2 in the test system.
    Configure WAN interface parameters:
    configure terminal
    interface enp7s4
    ip address 192.168.255.210/29
    description to-WAN
    no shutdown

    Configure LAN parameters:
    interface enp0S25
    ip address 10.10.11.4/22
    description to-LAN
    no shutdown

    Save configuration permanently, and quit interface configuration mode.
    do write
    exit
    exit

    Quit vtysh shell to come back to Linux shell.
    exit 

    Next, enable IP forwarding so that traffic can be forwarded between eth0 and eth1 interfaces.
    echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
    sysctl -p /etc/sysctl.conf

    Note that once Zebra daemon has started, any change made with vtysh's command line interface takes effect immediately. There is no need to restart Zebra daemon after configuration change.

    Check that /etc/quagga/zebra.conf contains the following
    ZEBRA.CONF
    interface enp0S25
    description to-LAN
    ip address 10.10.11.4/22
    ipv6 nd suppress-ra
    !
    interface enp7s4
    description to-WAN
    ip address 192.168.255.210/29
    ipv6 nd suppress-ra
    !
    !Static Route
    ip route 10.10.4.0/22 192.168.255.15 200

    The route is for the remote site via the OpenVPN address, weighted higher than the OSPF value.

    Phase 2: Configuring OSPF
    We start by creating an OSPF configuration file, and starting the OSPF daemon:
    cp /usr/share/doc/quagga-0.99.15/ospfd.conf.sample /etc/quagga/ospfd.conf
    chown quagga /etc/quagga/ospfd.conf
    service ospfd start
    chkconfig ospfd on

    Now launch vtysh shell to continue with OSPF configuration:
    vtysh 

    Enter router configuration mode:
    configure terminal
    router ospf

    Optionally, set the router-id manually:
    router-id 192.168.255.210

    Add the networks that will participate in OSPF, check with WAN router the relevant area numbers:
    network 10.10.8.0/22 area 99
    network 192.168.255.208/29 area 99

    Save configuration permanently:
    do write 


    The OSPF neighbours should come up now. As long as ospfd is running, any OSPF related configuration change made via vtysh shell takes effect immediately without having to restart ospfd.
    Check that /etc/quagga/ospfd.conf contains the following
    OSPFD.CONF
    router ospf
    ospf router-id 192.168.255.210
    network 10.10.8.0/22 area 99
    network 192.168.255.208/29 area 99
    redistribute static


    Verification
    Test with ping
    You should be able at this point to ping both subnets from each other.
    Check routing tables
    Necessary routes should be present in both kernel and Quagga routing tables.
    [root@frm-srv-fw1 ~]# ip route
    192.168.255.15 dev tun-dca proto kernel scope link src 192.168.255.16
    192.168.255.208/29 dev eth2 proto kernel scope link src 192.168.255.210
    192.168.153.0/24 dev eth0 proto kernel scope link src 192.168.153.80
    192.168.10.0/24 via 192.168.255.209 dev eth2 proto zebra metric 20
    10.10.4.0/22 via 192.168.255.209 dev eth2 proto zebra metric 30
    10.10.8.0/22 dev eth1 proto kernel scope link src 10.10.11.4
    default via 192.168.153.254 dev eth0

    # vtysh
    frm-srv-fw1# 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 via 192.168.153.254, eth0
    O>* 10.10.4.0/22 [110/30] via 192.168.255.209, eth2, 1d03h21m
    S 10.10.4.0/22 [200/0] via 192.168.255.15, tun-dca
    O 10.10.8.0/22 [110/10] is directly connected, eth1, 1d06h46m
    C>* 10.10.8.0/22 is directly connected, eth1
    C>* 127.0.0.0/8 is directly connected, lo
    O>* 192.168.10.0/24 [110/20] via 192.168.255.209, eth2, 1d03h29m
    C>* 192.168.153.0/24 is directly connected, eth0
    C>* 192.168.255.15/32 is directly connected, tun-dca
    O 192.168.255.208/29 [110/10] is directly connected, eth2, 1d06h46m
    C>* 192.168.255.208/29 is directly connected, eth2


    OpenVPN Configuration
    Do not include any remote destinations in the .conf file for the tunnel, this is handled by zebra.conf.
    Remote conf
    #Bind to external IP address
    remote 192.168.153.181
    #create a tunnel
    dev-type tun
    #name the tunnel
    dev tun-dca
    #UDP as protocol
    proto udp
    #use distinct port
    port 7265
    # ip addresses for the tunnel
    # ifconfig (local_end_ip) (remote_end_ip)
    # DCA to COL
    ifconfig 192.168.255.16 192.168.255.15
    #key used to secure tunnel
    secret /etc/openvpn/keys/dca-col.key
    #enable compression
    comp-lzo
    #location of log file
    log-append /var/log/openvpndca.log
    #restart tunnel in the event of line failures
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    #reduce security of openvpn
    user nobody
    group nobody
    #run in background
    daemon
    # Amend for remote network
    # Using Dynamic and OpenVPN
    # Nothing needed here


    HO VPN conf

    #create a tunnel
    dev-type tun
    #name the tunnel
    dev tun-dca
    #dev tun
    #UDP as protocol
    proto udp
    #use distinct port
    port 7265
    # ip addresses for the tunnel
    # ifconfig (local_end_ip) (remote_end_ip)
    # COL to DCA
    ifconfig 192.168.255.15 192.168.255.16
    #key used to secure tunnel
    secret /etc/openvpn/keys/dca-col.key
    #enable compression
    comp-lzo
    #location of log file
    log-append /var/log/openvpndca.log
    #restart tunnel in the event of line failures
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    #reduce security of openvpn
    user nobody
    group nobody
    #run in background
    daemon
    # Amend for remote network
    route 10.10.8.0 255.255.252.0 default 50
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 01 2017, 07:49 AM - #Permalink
    Resolved
    0 votes
    As promised attached are the instructions on how to use a ClearOS with dynamic routing and also with a failover OpenVPN tunnel in the event the WAN link goes down.

    Unfortunately there's too much to post as a thread, so I've attached as a PDF.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 01 2017, 07:30 AM - #Permalink
    Resolved
    0 votes
    As promised attached are the instructions on how to use a ClearOS with dynamic routing and also with a failover OpenVPN tunnel in the event the WAN link goes down.

    Unfortunately there's too much to post as a thread, so I've attached as a PDF.
    The reply is currently minimized Show
Your Reply