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.

Cisco SPA3102 settings for UK PSTN

A great unit even if it is 10 year old tech, only £20ish on eBay. However it comes with international settings as default. International dial tones and lack of disconnect supervision could result in a difficult and expensive situation for users.

I’ve applied the following settings for UK use. There are many more settings which could be changed – I’ve just not had the need to use the features needing these tones yet.

Dial Tone
350@-19,440@-19;10(*/0/1+2)
Outside Dial Tone
340@-19,430@-19;10(*/0/1+2)

 

Full details are in the manual, here

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpvga/ata/administration/guide/ATA_AG_v3_NC-WEB.pdf

FreePBX Error “Can Not Connect to Asterisk”

I’ve been getting an error when trying to administer Asterisk through FreePBX. Asterisk logfiles would only indicate that there was an authentication error every time I loaded the FreePBX GUI. This has prompted me to want to change the password used by FreePBX when communicating with the AMI. After trawling through many many .conf files, I discovered FreePBX in my case was getting the AMI credentials from the Asterisk MariaDB table shown below.

I had to install HeidiSQL on my windows desktop, and make changes to the database permissions to allow connections from my local subnet.

mysql asterisk

GRANT ALL PRIVILEGES ON *.* TO 'sam'@'192.168.%.%' IDENTIFIED BY 'New Password' WITH GRANT OPTION;

After this, I could login, but not update settings. To resolve run

/var/lib/asterisk/bin/retrieve_conf

Which returns

Exception: Unable to locate the FreePBX BMO Class 'Sipsettings'A required module might be disabled or uninstalled. Recommended steps (run from the CLI): 1) fwconsole ma install sipsettings 2) fwconsole ma enable sipsettings in file /var/www/html/admin/libraries/BMO/Self_Helper.class.php on line 216
Stack trace:
1. Exception->() /var/www/html/admin/libraries/BMO/Self_Helper.class.php:216
2. FreePBX\Self_Helper->loadObject() /var/www/html/admin/libraries/BMO/Self_Helper.class.php:104
3. FreePBX\Self_Helper->autoLoad() /var/www/html/admin/libraries/BMO/Self_Helper.class.php:37
4. FreePBX\Self_Helper->__get() /var/www/html/admin/modules/core/functions.inc/drivers/PJSip.class.php:860
5. FreePBX\modules\Core\Drivers\PJSip->generateEndpoints() /var/www/html/admin/modules/core/functions.inc/drivers/PJSip.class.php:313
6. FreePBX\modules\Core\Drivers\PJSip->genConfig() /var/www/html/admin/modules/core/Core.class.php:204
7. FreePBX\modules\Core->genConfig() /var/www/html/admin/libraries/BMO/FileHooks.class.php:97
8. FreePBX\FileHooks->processNewHooks() /var/www/html/admin/libraries/BMO/FileHooks.class.php:26
9. FreePBX\FileHooks->processFileHooks() /var/lib/asterisk/bin/retrieve_conf:892

So
fwconsole ma install sipsettings
fwconsole ma enable sipsettings in file /var/www/html/admin/libraries/BMO/Self_Helper.class.php on line 216

And the dashboard works!
…still getting errors when trying to reload config.

chkconfig asterisk off
fwconsole start

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

Changing Network Interface on Centos

Now I’ve got wired connectivity into the basement, I dont need to have the uplink between the comms pc and the router on Wifi. The interface shown here as wlp3s0 will now be called eth1

 

This article basically describes the process

https://unix.stackexchange.com/questions/205010/centos-7-rename-network-interface-without-rebooting/219277

 

However, I’ll also need to change the /etc/sysconfig/network-scripts/ifcfg-eth1 file to contain the IP address previously assigned to wlp3s0, and run

ip link set dev wlp3s0 down
service network restart

This is to ensure that incoming requests from the internet hit the new adapter, not the old one, which may be reassigned to something else later on.

Next, I’ll need to check firewalld has kept up with the changes

firewall-cmd --get-active-zones

and check eth1 is in the external zone