GRE over IPSec Tunnel Between Cisco and VyOS

Posted on October 6, 2015 by Radovan BrezulaUpdated on September 17, 2016

The previous tutorial shown GRE tunnel configuration between Cisco router and Linux Core. The big advantage of GRE protocol is that it encapsulates L3 and higher protocols inside the GRE tunnel so routing updates and other multicast traffic can be successfully transferred over the tunnel. The main drawback of GRE protocol is the lack of built-in security. Data are transferred in plain-text over the tunnel and peers are not authenticated (no confidentiality). Tunneled traffic can be changed by attacker (no integrity checking of  IP packets). For this reason GRE tunnel is very often used in conjunction with IPSec. Typically, GRE tunnel is encapsulated inside the IPSec tunnel and this model is called GRE over IPSec.

The tutorial shows configuration of OSPF routing protocol, GRE and IPSec tunnel on Cisco 7206 VXR router and appliance running VyOS network OS. Devices are running inside GNS3 lab an they are emulated by Dynamips (Cisco) and Qemu (VyOS).

 

Picture 1 - Topology

1. R3 Configuration
R3(config)# interface gigabitEthernet 1/0
R3(config-if)# ip address 1.1.1.1 255.255.255.0
R3(config-if)# no shutdown
R3(config-if)# interface gigabitEthernet 0/0
R3(config-if)# ip address 2.2.2.2 255.255.255.0
R3(config-if)# no shutdown

2. R1 Configuration
2.1 Interfaces and Static Route Configuration
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip address 1.1.1.10 255.255.255.0
R1(config-if)# no shutdown
R1(config)# interface gigabitEthernet 1/0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no shutdown

A static route pointing to the subnet 2.2.2.0/24 via router R3 is needed in a routing table of the router R1 so we have to create it.

R1(config)# ip route 2.2.2.0 255.255.255.0 1.1.1.1

2.2 IPSec Tunnel Configuration

Internet Security Association and Key Management Protocol (ISAKMP), is the negotiation protocol that lets two hosts agree on how to build an IPsec security association. ISAKMP separates negotiation into two phases - Phase 1 and Phase 2.

Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data (IPSec).

ISAKMP Configuration - ISAKMP Phase 1

First we create isakmp policy and select encryption, the hash algorithm, type of authentication, Diffie-Hellman group and lifetime.

R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encryption aes 256
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 14
R1(config-isakmp)# lifetime 86400
R1(config-isakmp)# exit

Note: You can check these parameters in the Transform payload located in first and the sixth packet  of the attached pcap file.

Then we configure key the shared key and peer address.

R1(config)#crypto isakmp key test123 address 2.2.2.10

IPSec Configuration - ISAKMP Phase 2

In phase two we create  IPSec transform set and configure encryption and the hash algorithm. This is also a place where we define IPSec mode - either a tunnel (default) or transport mode. In the tunnel mode a completely new IP delivery header is inserted in each IPSec packet while in a transport mode IP header stays untouched (except of the changed protocol type  - 50 for ESP).

R1(config)# crypto ipsec transform-set MyTS esp-aes esp-md5-hmac
R1(cfg-crypto-trans)# mode tunnel

Continue with creating a new IPSec profile named Protect-Gre. Assign transform-set MyTS is to the profile Protect-GRE and configure the lifetime.

R1(config)# crypto ipsec profile Protect-GRE
R1(ipsec-profile)# set security-association lifetime seconds 86400
R1(ipsec-profile)# set transform-set MyTS
And finally assign IPSec profile to the interface tun0.
R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile Protect-GRE

2.3 GRE Tunnel Configuration
R1(config)# interface tunnel 0
R1(config-if)# description Tunnel to R2
R1(config-if)# ip address 172.16.0.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# ip ospf network broadcast
R1(config-if)# tunnel source 1.1.1.10
R1(config-if)# tunnel destination 2.2.2.10

It is recommend to use the Cisco online IPSec overhead calculator to calculate Maximum Transmission Unit (MTU) for IP packet.

3. VyOS Configuration
3.1 Interfaces and Static Route Configuration
vyos@vyos:~$ configure
vyos@vyos# set interfaces ethernet eth0 address 2.2.2.10/24
vyos@vyos# set interfaces ethernet eth1 address 192.168.2.1/24
Again we have to configure static route pointing to the subnet 1.1.10/24.
vyos@vyos# set protocols static route 1.1.1.0/24 next-hop 2.2.2.2
3.2 IPSec Tunnel Configuration
Enable IPSec on interface eth0.
vyos@vyos# set vpn ipsec ipsec-interfaces interface eth0
Configure an IKE Group - Phase 1
Set the encryption, the hash algorithm, DH group and lifetime for phase 1.
vyos@vyos# set vpn ipsec ike-group cisco proposal 1
vyos@vyos# set vpn ipsec ike-group cisco proposal 1 encryption aes256
vyos@vyos# set vpn ipsec ike-group cisco proposal 1 hash md5
vyos@vyos# set vpn ipsec ike-group cisco proposal 1 dh-group 14
vyos@vyos# set vpn ipsec ike-group cisco lifetime 86400
Configure an ESP Group - Phase 2
Set the encryption, the hash algorithm and lifetime for phase 2.
vyos@vyos# set vpn ipsec esp-group cisco proposal 1
vyos@vyos# set vpn ipsec esp-group cisco proposal 1 encryption aes128
vyos@vyos# set vpn ipsec esp-group cisco proposal 1 hash md5
vyos@vyos# set vpn ipsec esp-group cisco pfs enable
vyos@vyos# set vpn ipsec esp-group cisco lifetime 86400
vyos@vyos# set vpn ipsec esp-group cisco mode tunnel

Configure tunnel peer and pre-shared key.

vyos@vyos# set vpn ipsec site-to-site peer 1.1.1.10 authentication pre-shared-secret test123
Configure ike-group used for the tunnel.
vyos@vyos# set vpn ipsec site-to-site peer 1.1.1.10 ike-group cisco
Configure esp-group used for the tunnel.
vyos@vyos# set vpn ipsec site-to-site peer 1.1.1.10 tunnel 0 esp-group cisco
Configure local address used for connection.
vyos@vyos# set vpn ipsec site-to-site peer 1.1.1.10 local-address 2.2.2.10
Configure protocol encapsulated inside IPSec.
vyos@vyos# set vpn ipsec site-to-site peer 1.1.1.10 tunnel 0 protocol gre
3.3 GRE Tunnel Configuration
Create a new route policy that changes TCP MSS to 1360 bytes.
vyos@vyos# set policy route change-mss rule 1 set tcp-mss 1360
vyos@vyos# set policy route change-mss rule 1 protocol tcp
vyos@vyos# set policy route change-mss rule 1 tcp flags SYN
Configure GRE tunnel.
vyos@vyos# set interfaces tunnel tun0 encapsulation gre
vyos@vyos# set interfaces tunnel tun0 address 172.16.0.2/24
vyos@vyos# set interfaces tunnel tun0 description "Tunnel to R1"
vyos@vyos# set interfaces tunnel tun0 mtu 1400
vyos@vyos# set interfaces tunnel tun0 policy route change-mss
vyos@vyos# set interfaces tunnel tun0 local-ip 2.2.2.10
vyos@vyos# set interfaces tunnel tun0 remote-ip 1.1.1.10
vyos@vyos# set interfaces tunnel tun0 multicast enable
3.4 OSPF Configuration
vyos@vyos# set interfaces tunnel tun0 ip ospf network broadcast
vyos@vyos# set protocols ospf area 0.0.0.0 network 172.16.0.0/24
vyos@vyos# set protocols ospf area 0.0.0.0 network 192.168.2.0/24
vyos@vyos# commit
vyos@vyos# save

4. Verification

4.1 Verification on VyOS

Below are various show commands that help you to verify status of tunnels on VyOS.

List all currently active IKE Security Associations (SA) - Phase 1:
vyos@vyos# show vpn ike sa

List all active IPsec Security Associations (SA) - Phase 2:
 vyos@vyos# show vpn ipsec sa

Check status of GRE tunnel interface:
vyos@vyos# show interfaces tunnel tun0

4.2 Verification on Cisco

Below are various show commands that help you to verify status of tunnels on Cisco device.

List all currently active IKE Security Associations (SA) - Phase 1:

R1# show crypto isakmp key

List all active IPsec Security Associations (SA) - Phase 2:
R1# show crypto ipsec sa

Check status of GRE tunnel interface:
R1# show interfaces tunnel 0

Tunnel line state evaluation:
R1# show tunnel int

End.
References:
http://brezular.com/2015/10/06/gre-over-ipsec-tunnel-between-cisco-and-vyos/
http://cromwell-intl.com/tcpip/what-is-ipsec.html
http://www.carbonwind.net/VyattaOFR/AdvVPN/AdvVPN14.htm

Как настроить Cisco для работы основного и бэкапного каналов

From: fenix2 <fenix111@mail.ru.>
Newsgroups: email
Date: Mon, 24 Oct 2007 14:31:37 +0000 (UTC)
Subject: Как настроить Cisco для работы основного и бэкапного каналов.


ip sla или как сделать чтобы красиво работал основный\бэкапный каналы без BGP.


Итак, у нас есть маршрутизатор Cisco и 2 канала, основной и бэкапный. 

Мы хотим 

1. чтобы когда отваливался основной, работал бэкапный (и когда основной
поднялся, маршрут обратно переписывался на него)

2. чтобы нагрузка между ними балансировалась (и с PBR в том числе).
Опять же, при падении провайдера трафик не него не должен ходить.

Оба провайдера у нас через ethernet, и статический маршрут не исчезнет
при падении провайдера.

Настроим IP SLA для проверки доступности провайдеров
(пингуем наши дефолт-гейтвеи)

        ip sla 1
        icmp-echo 80.91.170.13 source-interface GigabitEthernet0/1  
        timeout 2000  
        frequency 3 
        ip sla schedule 1 life forever start-time now

        ip sla 2
        icmp-echo 83.218.239.13 source-interface GigabitEthernet0/2  
        timeout 2000  
        frequency 3 
        ip sla schedule 2 life forever start-time now

        track 1 rtr 1 reachability
        track 2 rtr 2 reachability


Метод icmp-echo не очень хорош, т.к. при пропадании одного icmp пакета,
что случается чаще чем я думал (можно глянуть коммандой show track), 
идёт переключение маршрута(об этом чуть позже). Лучше использовать, icmp-jitter 
(доступен с только с 12.4Т), тк. он пускает несколько пакетов.
Например:

        ip sla 1
          icmp-jitter 80.91.170.13 source-ip 80.91.170.14 num-packets 5
          timeout 2
          frequency 4
        ip sla schedule 2 life forever start-time now

        ip sla 2
          icmp-jitter 83.218.239.13 source-ip 83.218.239.14 num-packets 5
          timeout 2
          frequency 4
        ip sla schedule 2 life forever start-time now


И собственно добавим статические маршруты на провайдеров.

        ip route 0.0.0.0 0.0.0.0 80.91.170.13 50 track 1 (основной провайдер, AD 50)
        ip route 0.0.0.0 0.0.0.0 83.218.239.13 100 track 2 (бэкапный, AD 100)


Если нету ответа на эхо запрос от провайдера, статический маршрут
убирается.

При отсутствии AD (Administrative Distance) в ip route у статических маршрутов будет load blancing
(per destanation, при влючённом ip cef. Т.е. на один dst-ip всё поёдет через одного провайдера, на другой dst-ip через другого)

Добавим еще PolicyBasedRouting (если у нас не симметричные каналы, или мы хотим чтобы
некоторые внутренние хосты выходили через конкретного провайдера, а в
случае его падения через бэкапного). В route-map выставляется приоритет
на лучшего провайдера.

рисуем рoут мап

        route-map 115 permit 10
        match ip address 115
        set ip next-hop verify-availability 80.91.170.13 10 track 1
        set ip next-hop verify-availability 83.218.239.13 20 track 2


указывем в acl внутренних хостов

        access-list 115 permit ip host 192.168.0.15 any
        access-list 115 permit ip host 192.168.10.2 any
        access-list 115 permit ip host 192.168.0.161 any


И вешаем 

        ip policy route-map 115


На интерфейс который смотрит в локалку.

При такой конфигурации переход на живого провайдера происходит примерно
за время timeout в ip sla, т.е. 2 секунды.

Мониторинг сети с помощью tcpdump

Мониторинг сети с помощью tcpdump

Оригинальная статья. 

Довольно часто встает проблема, когда ему нужно узнать как работает сеть. Или просто для учебных-исследовательских целей узнать как взаимодействуют между собой объекты сети. Для этих целей в UNIX-мире написано целая куча инструментов. В данном материале будет рассматриваться один из них: tcpdump.
Итак, tcpdump.
$ man tcpdump, нам гласит
Tcpdump выводит заголовки пакетов проходящих через сетевой интерфейс, которые совпадают с булевым выражением. Он может также быть запущен с ключем -w, который заставляет сохранять данные пактов в файл для дальнейшего исследования, и/или с ключем -r, который заставляет читать сохраненные пакеты из файла, вместо чтения пакетов из сетевого интерфейса. В любом случае, tcpdump будут обработаны только те пакеты, которые совпадают с выражением.
Tcpdump будет, если не запущен с ключем -c, продолжать собирать пакеты до тех пор, пока не будет прерван сигналом SIGINT (генерируемым, для примера, вводом Вашего символа прерывания, обычно CTRL+C) или сигналом SIGTERM (обычно генерируемого командой kill). Если запуск был с ключем -c, то сбор пакетов будет продолжаться до тех пор, пока не произойдет прерывание сигналом SIGINT или SIGTERM или пока не будет обработано определенное количество пакетов.
Когда tcpdump закончит сбор пакетов, то будет сообщено об количестве:

• пакетов "полученных фильтром" (received by filter) (значение зависит от той ОС, на какой Вы запускаете tcpdump, и, возможно, от способа, котрым ОС была сконфигурирована - если фильтр был определен в командной строке, на некоторых ОС будут сосчитаны пакеты независимо от фильтрующего выражения, а в других ОС будут сосчитаны только те пакеты, которые попадают под фильтрующее и выражение, и были обработаны tcpdump);
• пакетов "отброшенных ядром" (dropped by kernel) (это число пакетов, которые были отброшены, в зависимости от механизма сбора пакетов (недостаточного объема буферов) на той ОС, где запускается tcpdump, ОС предоставит эту инофрмацию приложению или нет, и тогда будет выведено число 0)

Это был перевод - исправления приветствуются.
Дальше идет описание ключей. Вот некоторые из них:

• -c count Выйти после получения определенного количества пакетов.
• -C file_size Перед записью "сырого" пакета в файл, происходит проверка на превышение размером файла лимита, указанного в file_size. Если размер файла больше, то файл закрывается и открывается новый. Новый файл будет иметь имя определенное в ключе -w, со стоящим в конце числом 2, которое будет увеличиваться в следующих именах файлов. file_size определяет размер в миллионах байт (1,000,000), а не мегабайтах (1,048,576).
• -F file Использовать file для ввода фильтрующего выражения. Выражение, указанное в командной строке, будет игнорироваться.
• -i interface Собирать пакеты только на определенном интерфейсе. Если не указан - берется минимальный по номеру интерфейс (исключая loopback). Для Linux-ядер 2.2 и более новых, возможно указать 'any', тогда будет происходить сбор на всех интерфейсах, но они не будут переведены в режим promiscuous.
• -n Не преобразовывать адрес хоста в имя. Может быть использовано, если необходимо избегать DNS-запросов.
• -nn Не преобразовывать протокол и номер порта в их имена.
• -N Не выводить доменную часть имени хоста. Например, при данном ключе будет выводится "nic" вместо "nic.ddn.mil"
• -p Не переводить интерфейс в режим promiscuous. Следует заметить, что интерфейс может быть в режиме promiscuous по другим причинам.
• -r file Читать пакеты из file (который, был создан с ключем -w). Если file указан как "-", то используется стандартный ввод.
• -t Не выводить временной штамп (timestamp) в каждой строке дампа (dump).
• -tt Выводит не форматированный временной штамп в каждой строке дампа.
• -ttt Выводить разницу (в микросекундах) между текущей и предыдущей строками дампа.
• -tttt Выводить временной штамп вместе с датой в формате по-умолчанию в каждой строке дампа.
• -v (Чуть более) подробный вывод. Для еще более подробного вывода используются: -vv и -vvv.
• -w file Писать "сырые" пакеты в file перед тем как произвести их разбор и вывести. Они могут быть позднее выведены с ключем -r. Если file указан как "-", то используется стандартный вывод.
• -x Печатать каждый пакет (без заголовков уровня соединения) в шестнадцатиричном виде.
• -X Помимо шестнадцатиричного вида выводить их ASCII-значения.

Теперь, рассмотрим фильтрующее выражение.
Оно выбирает какие пакеты будут выбираться из общего потока. Если оно не указано, то будут выбираться и выводится все пакеты идущие через интерфейс. Иначе, будут обработаны только те пакеты, для которых проверка с выражением выдаст значение "истина" (true).
Выражение состоит из одного или более примитивов. Примитивы обычно состоят из ID (имя или номер) следующего за одним или более классификаторами. Различают три вида классификаторов:

• type Говорят к какому виду относить ID. Возможный значения host, net или port. Пример: 'host foo', 'net 128.3', 'port 20'. Если классификатор type не указан, то подразумевается host.
• dir Определяет конкретное направление передачи "к" и/или "от" ID. Возможны значения src, dst, src or dst and src and dst. Пример, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'. Если не указан, то подразумевается src or dst. Для соединений нулевого ('null') уровня (к примеру, протокол точка-точка, такой как slip) указанием направления могут быть классификаторы inbound и outbound.
• proto Ограничивает совпадение конкретным протоколом. Возможные протоколы: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp и udp. Пример, 'ether src foo', 'arp net 128.3', 'tcp port 21'. Если классификатор proto не указан, то подразумеваются все перечисленные типы протоколов. Например, 'src foo означает '(ip or arp or rarp) src foo', 'net bar' означает '(ip or arp or rarp) net bar', а 'port 53' означает '(tcp or udp) port 53'.

В добавок, существует несколько специальных примитивов - ключевых слов: gateway, broadcast, less, greater и арифметические выражения.
Более сложные фильтрующие выражения могут быть построены с помощью слов and, or и not, объединяющих примитивы. Пример, 'host foo and not port ftp and not port ftp-data'. Чтобы уменьшить количество вводимой информации, идентичные списки классификаторов могут быть опущены. Пример, 'tcp dst port ftp or ftp-data or domain' это тоже самое, что и 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'
Перечислим некоторые из допустимых примитивов (за более полным списком в man tcpdump):
dst host host

• Истина, если поле "назначение" пакета -это host, который может быть адресом или именем

src host host

• Истина, если поле "источник" пакета - это host.

host host

• Истина, если или поле "назначение", или поле "источник" пакета - это host. Любое из описанный выше выражений может быть приписано к ключевому слову ip, arp, rarp, или ip6, как в 'ip host host', что эквивалентно 'ether proto \ip and host host'. Если host - это имя с несколькими IP адресам, то проверяется совпадение по каждому адресу.

net net mask netmask

• Истина, если IP адрес входит в сеть с указанной сетевой маской. Может быть классифицировано с dst или src.

net net/len

• Истина, если IP адрес входит в сеть с указанной сетевой маской, заданной количеством бит. Может быть классифицировано с dst или src.

dst port port

• Истина, если пакет протоколов ip/tcp, ip/udp, ip6/tcp или ip6/udp, и порт-назначения имеет значение указанное в port. Порт может быть числом или именем, используемым в /etc/services. Если используется число или неоднозначное имя, то проверяется только номер порта (пример, 'dst port 513' будет выводить трафик и для tcp/login и для udp/who, а 'port domain' будет выводить трафик и для tcp/domain и для udp/domain).

src port port

• Истина, если пакет имеет порт-источник - port

port port

• Истина, если или порт-назначение, или порт-источник в пакете - port. Любое из описанных выше выражений может быть приписано к ключевому слову tcp или udp, как в 'tcp src port port', проверяющее совпадения только для TCP-пакетов.

less length

• Истина, если пакет имеет длину меньше или равную length. Это эквивалентно len <= length.

greater length

• Истина, если пакет имеет длину больше или равную length. Это эквивалентно len >= length.

ip proto protocol

• Истина, если пакет - это IP-пакет протокола, указанного в protocol. Протокол может быть числом или одним из имен icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, или tcp. Заметим, что идентификаторы tcp, udp и icmp - ключевые слова и должны быть "заэкскейпены" через обратный слэш (\).

Прежде чем переходит к примерам рассмотрим, что может нам выдать tcpdump при выполнении.
Типичные результаты работы tcpdump -ttt:

1. 000107 192.168.2.13 > 192.168.2.254: icmp: 192.168.2.13 udp port 3631 unreachable
2. 000313 192.168.2.254.53 > 192.168.2.13.3656:  4 ServFail 0/0/0 (22) (DF)
3. 000287 192.168.2.254 > 192.168.2.100: icmp: net 205.188.179.233 unreachable [tos 0xc0]
4. 010956 192.168.2.254.139 > 192.168.2.13.3661: P 1:5(4) ack 73 win 5840 NBT Packet (DF)
5. 276274 192.168.2.150.3053 > 192.168.2.254.53:  7+ A? Tatyana.karavay-shops.ru. (42)
6. 001162 192.168.2.100.32772 > 192.168.2.254.16007: . ack 73 win 5840 (DF)

Первое поле - поле времени, т. к. запуск осуществлялся с ключом "-ttt", то это разница в микросекундах между этим пакетом и предыдущим.
Потом идет IP-адрес (или имя) отправителя пакета, через точку может указываться порт. После знака ">", указывается получатель пакета (или его имя) и также порт. Затем будет идти либо сразу служебная информация идущая в пакете, либо протокол (у нас это icmp). В служебной информации может быть указано либо состояние флагов в пакете, либо расшифрованная информация ("192.168.2.13 udp port 3631 unreachable" или DNS-запрос об хосте "Tatyana.karavay-shops.ru").
Ну а теперь пора взяться за конкретные примеры.
1. Ловим весь входящий трафик из локальной сети на сервер. Здесь все просто.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt dst host 192.168.2.254
Если вы запускаете его в SSH сессии, то подготовьтесь - польется очень много и очень быстро...
2. Ловим весь входящий трафик, исключая трафик генерируемый нашей SSH-сессией.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'dst host 192.168.2.254 and not ( src host 192.168.2.100 and dst port 22 )'
Вот теперь в потоке пакетов можно разобраться.
3. Нужна информация об DNS-общении между сервером и каким-нибудь узлом сети.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and ip proto \udp'
Здесь, кстати будет бегать не только DNS-трафик. А вообще весь, который идет по UDP. Исправить это можно следующим:
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and port 53'
4. Отлавливаем исключительно icmp пакеты.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'ip proto \icmp'
Вот. Теперь все.
Не забывайте, что более подробную информацию можно получить из man tcpdump. Там же можно прочитать об структуре пакетов основных протоколов, что позволит еще глубже исследовать Ваши сети.

PacketFence on Debian

How to install PacketFence on Debian?

To install PacketFence under Debian 7.0 (Wheezy), you simply have to add the Inverse repository under /etc/apt/sources.list.d/ by adding the file packetfence.list

echo 'deb http://inverse.ca/downloads/PacketFence/debian wheezy wheezy' > /etc/apt/sources.list.d/packetfence.list

Then do:

sudo apt-key adv --keyserver keys.gnupg.net --recv-key 0x810273C4

or:

sudo apt-key adv --keyserver hkp://keys.gnupg.net:80 --recv-keys 0x810273C4

Then:

sudo apt-get update
sudo apt-get install packetfence

Once apt-get finished to install all the packages, reboot your server and after please fire up your Web browser and go to http://:1443/configurator to complete your PacketFence configuration.

---*---

Network:
vi /etc/network/interfaces
/etc/init.d/networking restart

DNS service:
vi /etc/bind/named.conf.options
/etc/init.d/bind9 restart

Asterisk:
run: asterisk -cd
console: asterisk -r
restart(from console): module reload
debug level(from console): core set verbose 3
external IP(*): vi /etc/asterisk/sip.conf (check register, localnet)
restart IAX (from console): iax2 reload

Port forward on router:
(udp) 5060, 10000 - 20000, 4569

Defaults for ttySx: 9600 8n1n

NAT ext forward example

В этом примере внешне инициируемое соединение для порта SMTP (25) будет посылаться на внутренний хост 192.168.10.1.

ip nat inside source static tcp 192.168.1.1 25 213.130.24.4 25


Следующий пример конфигурации демонстрирует трансляцию между внутренними хостами сети, адресуемыми в сети 9.114.11.0, и глобальной уникальной сетью 171.69.233.208/28. Пакеты с внешних хостов, адресуемых в сети 9.114.11.0 ("подлинной" сети 9.114.11.0), транслируются, чтобы производилось впечатление, что они из сети 10.0.1.0/24.

ip nat pool net-20 171.69.233.208 171.69.233.223 netmask 255.255.255.240
ip nat pool net-10 10.0.1.0 10.0.1.255 netmask 255.255.255.0
ip nat inside source list 1 pool net-20
ip nat outside source list 1 pool net-10
!
interface Ethernet0
ip address 171.69.232.182 255.255.255.240
ip nat outside
!
interface Ethernet1
ip address 9.114.11.39 255.255.255.0
ip nat inside
!
access-list 1 permit 9.114.11.0 0.0.0.255