Centos Comms PC for Home

After some pontification on how I want to setup the network in my new house, I’ve decided I need to have a dedicated comms PC in order to manage the various new and existing VPN connections between existing networks.

I’ve successfully been using Centos 7 for development at work, so have decided to use this OS for the new comms PC.

The comms PC has three proposed functions:

  • Act as an internet gateway for traffic on my private wireless/wired network (192.168.11.0).
  • Act as a gateway for traffic going to the existing subnets at the old house (192.168.0.0 & 192.168.1.0).
  • Act as a server for encrypted traffic from clients dialling-in

 

Within the bigger picture, the new network will also need to serve a wifi network for the other tenants on the 192.168.10.0 subnet, which needs to be kept reasonably secure and separate from the VPN data on the 192.168.11.0 subnet.

Part 1: setting-up the comms PC to act as a NAT gateway between the two networks.

For this I’m using a wireless card to access the tenants wifi (192.168.10.0) and an integrated ethernet NIC to connect to the Switch/Wireless Access Point for my private network (192.168.11.0). The first set of instructions which proved vaguely helpful were here

This was helpful with setting up the network port configuration, Gateway configuration, DNS configuration, and DHCP server setup. Further explanation of the dhcpd service is here.

ifcfg-enp2s0-2

HWADDR=F4:CE:46:04:7F:CF
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=192.168.11.254
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV4_DNS_PRIORITY=100
IPV6INIT=no
NAME=enp2s0
UUID=3bbaec33-4a8f-4899-b916-37e2ed9d9716
DEVICE=enp2s0
ONBOOT=no
ZONE=internal

ifcfg-my wifi ssid

HWADDR=7C:8B:CA:12:E4:C5
ESSID=my wifi ssid
MODE=Managed
KEY_MGMT=WPA-PSK
SECURITYMODE=open
MAC_ADDRESS_RANDOMIZATION=default
TYPE=Wireless
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
IPADDR=192.168.10.250
BROADCAST=192.168.10.255
NETMASK=255.255.255.0
NETWORK=192.168.10.0
GATEWAY=192.168.10.1
DNS1=8.8.8.8
DNS2=8.8.4.4
ONBOOT=yes
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=my wifi ssid
UUID=ed58ce63-1e07-41f2-99ff-e92178939810
USERCTL=no
PREFIX=24
ZONE=external

/etc/dhcp/dhcpd.conf

option domain-name-servers 8.8.8.8, 8.8.4.4;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style interim;
authoritative;
subnet 192.168.11.0 netmask 255.255.255.0 {
range 192.168.11.10 192.168.11.90;
option broadcast-address 192.168.11.255;
option routers 192.168.11.254;
}

Unfortunately the instructions are slightly outdated, as CENTOS 7 uses the firewalld service, not iptables for firewalling the interfaces.

Redbranch.net have an article here, explaining pretty much what I needed to do to configure firewalld.

Static routing then needed a bit of work at this point. “sudo route -n” revealed that there were two default gateway routes, one for each interface, however the wired interface does not have access to the internet. Further, the metric of the wired interface was giving priority to internet traffic via this (dead) route – I assume its some kind of default in CENTOS to give wired adapters a higher metric than wireless adapters (makes sense under usual circumstances). More info about static routing here.

sudo route del -net 0.0.0.0 gw 192.168.10.1 netmask 0.0.0.0 dev enp2s0

Annoyingly, at around this point the PC hung, and needed a reboot. This uncovered further issues:

  • dhcpd may not be set to automatically start on reboot – guide here to adjust that.
  • Changes to static routes are not persistent. I had to generate the following to make the changes persist:

/etc/sysconfig/network-scripts/route-wlp3s0

default 192.168.10.1 dev wlp3s0

Once these were resolved, I was able to identify the following issues with my configuration.

  • The internally facing interface (192.168.11.254) must not have a gateway address in its /etc/sysconfig/network-scripts/ifcfg-NIC file.
  • The DHCP server config,  /etc/dhcp/dhcpd.conf must list the internal network interface IP (192.168.11.254) as the network gateway (Something somewhere made me think the tenants WiFi gateway (192.168.10.1) should be used).

At this point I could now access the internet on the basement desktop PC, and the basement IP phone should now be able to register.

Part 2: Establishing PPTP connectivity back to the existing network.

Why PPTP?

Good question! I’m choosing to use this compromised protocol because the main router (Provided by ISP Talktalk) on the existing network does not allow forwarding of all the needed TCP ports in order to use L2TP. This is very frustrating, as the comms PC I’m building otherwise wouldn’t need to have the L2TP server (mentioned later) if the main network could host one.

The guide found here pretty much covers everything. To my shock at the end of the guide the following GUI on my windows server indicated that the PPTP route was open.

 

Ok, so now the new virtual interface ppp0 is connected I’m going to need to do some more static routing stuff. Interface ppp9 has IP 192.168.0.41 and the remote server has virtual IP 192.168.0.50. The remote (main) network has subnets in the 192.168.0.0 and 192.168.1.0 ranges)

route add-net 192.168.0.0 gw 192.168.0.50 netmask 255.255.255.0 dev ppp0

route add-net 192.168.1.0 gw 192.168.0.50 netmask 255.255.255.0 dev ppp0

However, these changes will not persist if I reboot. This is where the ip-up and ip-up.local files come in.

 

/etc/ppp

#!/bin/bash
# This file should not be modified -- make local changes to
# /etc/ppp/ip-up.local instead

PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH

LOGDEVICE=$6
REALDEVICE=$1

[ -f /etc/sysconfig/network-scripts/ifcfg-${LOGDEVICE} ] && /etc/sysconfig/network-scripts/ifup-post --realdevice ${REALDEVICE} ifcfg-${LOGDEVICE}

/etc/ppp/ip-up.ipv6to4 ${LOGDEVICE}

[ -x /etc/ppp/ip-up.local ] && /etc/ppp/ip-up.local "$@"

exit 0

/etc/ppp/ip-up.local

#!/bin/bash
case "$5" in
192.168.0.50)
/sbin/route add -net 192.168.0.0/24 gw 192.168.0.41
/sbin/route add -net 192.168.1.0/24 gw 192.168.0.41
;;
esac
exit 0

ip-up is run after each call to pppd, ip-up in turn then calls ip-up.local which should contain the local variables. ip-up.local uses the case syntax in order to establish which routes to add based upon the parameters which are handed to it from the ip-up script.

At this point I decided that an icon on my desktop may be handy for establishing the vpn connection manually. A desktop object starts the following script in persistent mode.

/var/Auto-FE_PPTP.sh persist

#!/bin/bash
modprobe nf_conntrack_pptp
IFACE=$(/sbin/ip a show wlp3s0 up)
PPP9=$(/sbin/ip a show ppp9 up 2>&1)
ROUTE=$(ping -c 2 -w 2 HOST_PPTP_SERVER)
case $PPP9 in
*'UP'*)
echo -e "Virtual Interface \e[31mBusy\e[0m"
if [[ $1 == "persist" ]]; then
read -p "Press enter to continue"
fi
exit 1
;;
*'does not exist.'*)
echo -e "Virtual interface \e[32mready!\e[0m"
;;
*)
echo -e "Virtual interface \e[31mfault\e[0m"
if [[ $1 == "persist" ]]; then
read -p "Press enter to continue"
fi
exit 1
esac

if [[ $IFACE == *"192.168.10.250/24"* ]]; then
echo -e "Outbound interface \e[32mready!\e[0m"
else
echo -e "\e[31mNo Connection....\e[0m Trying again in 5 Seconds"
sleep 5
exec "/var/Auto-FE_PPTP.sh"
fi

case $ROUTE in
*"2 received,"*)
echo -e "Path to host \e[32mready!\e[0m"
;;
*)
echo -e "Path to host \e[31mfault\e[0m"
if [[ $1 == "persist" ]]; then
read -p "Press enter to continue"
else
echo -e "\e[31mNo Connection....\e[0m Trying again in 5 Seconds"
sleep 5
exec "/var/Auto-FE_PPTP.sh"
fi
exit 1
esac

echo "Starting VPN connection to HOST"
$(sudo /sbin/pppd call FE_PPTP)
unset PPP9
PPP9=$(/sbin/ip a show ppp9 up 2>&1)
declare -i TIMEOUT

while [[ $PPP9 != *"192.168.0.41"* && $TIMEOUT < 5 ]]; do
printf "connecting...\n"
sleep 2
let "TIMEOUT++"
unset PPP9
PPP9=$(/sbin/ip a show ppp9 up)
done

if [[ $PPP9 == *"192.168.0.41"* ]]; then
echo -e "\e[32mconnected!\e[0m"
else
echo -e "Timeout error occurred"
fi

if [[ $1 == "persist" ]]; then
read -p "Press enter to continue"
fi

exit 0

The Auto-FE_PPTP.sh script now needs to be run at startup. the following guide explains how to do that here.

 

Strongswan stops talking to RW Client #1 when RW Client #2 connects

I’ve only realised this one when i was using my laptop, then tried to connect to the same resource from my mobile phone.

Symptoms

Road warrior client #1 cannot access any information down the VPN tunnel after road warrior client #2 connects. Road warrior client #2 may be able to communicate OK.

Cause

A rogue statement in ipsec.conf is applying the wrong subnet filter to road warrior connections. This can be confirmed by running “strongswan status”.

[root@PC ~]# strongswan status
Security Associations (2 up, 0 connecting):
rw-eap[48]: ESTABLISHED 106 seconds ago, 192.nnn.nnn.nnn[3.samelms.co.uk]...46.233.nnn.nnn[My_Laptop]
rw-eap{198}: INSTALLED, TUNNEL, reqid 37, ESP in UDP SPIs:
rw-eap{198}: 0.0.0.0/0 === 192.168.6.0/24
rw-eap[47]: ESTABLISHED 4 minutes ago, 192.nnn.nnn.nnn[3.samelms.co.uk]...85.255.nnn.nnn[My_Mobile]
rw-eap{197}: INSTALLED, TUNNEL, reqid 37, ESP in UDP SPIs:
rw-eap{197}: 0.0.0.0/0 === 192.168.6.0/24

See the 192.168.6.0/24 represents a whole subnet behind the client. This is wrong, it should be my.ip.v4.address/32

Resolution

Hash the following statement from ipsec.conf

rightsubnet=192.168.6.0/24

And restart strongswan. Strongswan Status should now look something like

[root@PC ~]# strongswan status
Security Associations (2 up, 0 connecting):
rw-eap[3]: ESTABLISHED 103 seconds ago, 192.nnn.nnn.nnn[3.samelms.co.uk]…85.255.nnn.nnn[My_Mobile]
rw-eap{3}: INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs:
rw-eap{3}: 0.0.0.0/0 === 192.168.6.11/32
rw-eap[2]: ESTABLISHED 2 minutes ago, 192.nnn.nnn.nnn[3.samelms.co.uk]…46.233.nnn.nnn[My_Laptop]
rw-eap{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs:
rw-eap{2}: 0.0.0.0/0 === 192.168.6.12/32

This can be confirmed by accessing resources on the host network from each of the road warriors simultaneously.

FreePBX settings for Draytel

Its taken a few hours work, but the below settings seem to work for incoming calls on Draytel to my Asterisk installation


PEER DETAILS

username=MYUSERNAME
usereqphone=yes
type=friend
secret=MYPASSWORD
port=5065
outboundproxy=nat.draytel.org
host=draytel.org
fromuser=MYUSERNAME
fromdomain=draytel.org
dtmfmode=rfc2833
context=from-trunk
canreinvite=no
allow=alaw,g711,ulaw

REGISTRATION STRING

MYUSERNAME:MYPASSWORD:MYUSERNAME@draytel.org/MYUSERNAME

These are loosely based on the settings described here:
https://support.voiptalk.org/hc/en-us/articles/115006438427-Configuration-of-a-FreePBX-with-a-VoIPtalk-trunk

External IP Reporting from CENTOS

Much like my PHP example of external IP reporting, the following script performs exactly the same task, but in Centos. This combined with creating a custom system service should provide dynamic IP resolution even if the PC reboots.


#!/bin/bash
i=1
while [ $i == 1 ]
do
datestring=$(date –utc +%FT%TZ)
ipfile=”myip.txt”
ipdir=”/var/manage/”
logfile=/var/manage/myiplog.txt
oldip=$(cat $ipdir$ipfile)
echo “Getting IP… ”
wanip=$(dig +short EXTERNAL IP RESOLVER ADDRESS)
#if [ 1 -ne 1 ]
if [ $oldip != $wanip ]
then
echo My IP has changed! Saving change to file…
echo $wanip > $ipdir$ipfile
echo Connecting to FTP server…
lftp -u FTP_USERNAME,FTP_PASSWORD FTP_SITE -e ” lcd $ipdir; put $i$
echo Writing log…
echo “$datestring IP changed to $wanip” >> $logfile
echo Log written!
else
echo My IP is the same!
fi
echo Sleeping for 5 mins…
sleep 300s
done

Setting up dhcpd for TFTP

I need to tell my TFTP enabled clients about the TFTP server hosted on another site. Without this I wont be able to continue working on my SIP on Cisco handsets project (Not yet mentioned on here).

TFTPD can do this, although you have to declare the variable in the config file before you can reference it – unlike the standard options which do not require declaring. The following is at the top of the config file.

/etc/dhcp/dhcpd.conf

option tftp150 code 150 = array of ip-address; 
option tftp66 code 66 = array of ip-address;

Unlike the declarations used in some examples, I’m using an array, in the hope that my devices can automatically work-around a failure of the VPN. The next extract is from within the subnet declaration.

/etc/dhcp/dhcpd.conf

option tftp150 192.158.0.100, [other site fqdn];

option tftp66 192.168.0.100, [other site fqdn];