GAIA DHCP-relay R75.40VS

 DHCP-relay в GAIA R75.40VS

Шлюзы  Check Point не пересылают к клиентам ответы от DHCP-сервера.  Проблема заключается в том, что запросы от шлюзов Check Point к DHCP-серверу идут с физических адресов шлюзов. 

На кластере имеем две сети: eth3 192.168.1.0/24 и eth2 192.168.2.0/24, сервер DHCP установлен в сети 192.168.2.0/24 и имеет адрес 192.168.2.100. Первые три адреса сетей принадлежат FW. 

Произведенные настройки:

DHCP-relay настроен с указанием Primary-адреса кластера:

set bootp interface eth3 primary 192.168.1.1 on

set  bootp  interface  eth3  relay-to  192.168.1.100  on

Созданы правила NAT следующего вида:

№
	Source	Destination	Service	Source	Destination	Service
1	fw01_192.168.1.2	l_dhcp_srv (192.168.2.100)	bootp	fwc_192.168.1.1	Any	Any
2	fw02_192.168.1.3	l_dhcp_srv (192.168.2.100)	bootp	fwc_192.168.1.1	Any	Any

Инсталлируем политику, и проверяем.

Link Selection для Remote Access, Checkpoint R75.40VS

Link Selection для Remote Access

Еще одна фича:) 

Если у нас кластер FW центрального офиса устанавливает Site-to-Site VPN с удаленными офисами(Check Point Edge) с интерфейса L3 сети ОПСа с адресом 192.168.XX.1) и на FW ЦО настроен Remote Access VPN для пользователей через Интернет (на внешнем интерфейсе с адресом  190.ZZ.YY.XX(белый адрес)). 

В данной конфигурации не работает механизм LinkSelection свойствах объекта :(

Для корректной работы необходимо внести правки помощи guidbedit в параметры объекта FW:

apply_resolving_mechanism_to_SR	false
ip_resolution_mechanism	singleIpVpn
ip_resolution_mechanism_GW	singleIpVpn
single_VPN_IP	192.168.XX.1
single_VPN_IP_RA	190.ZZ.YY.XX

Сохранить, закрыть dbedit и не забыть сделать Install Policy.

IP Redundancy в Checkpoint SPLAT R75.40VS

Понадобилось двух ОПСов подключить в режиме балансировки нагрузки, без BGP :)

Все предыдущие попытки это нормально сделать на роутерах cisco были костыльными. Подумали "а чем черт не шутит" и решили испытать.

Подготовка:
изучена официальная дока и пролистан бог Дениса Урасова спасибо! 
Но в отличии от Дениса, у нас трафик исходящий, т.е. просто использования Интернет'а пользователями из локалки.

Не буду сюда приводить картинки из GUI, так как оф.доки или записей Дениса хватит заглаза.

Единственное, что в нашем случае не заработало, это Hide manual Nat из локалки.

Но поиски по оф.сайту дали решение, для тех у кого нет доступа повторяю текст сюда.

Описательная часть, надо создать динамические объекты(IP адреса для Nat'ирования) и изменять их скриптами. перевод не привожу так как в оригинале всё понятно.

In SmartDashboard, define two Manual NAT rules for outgoing connections (a rule for each ISP link) - use the objects 'DYN_ISP_A' and 'DYN_ISP_B'.

Note: Order of incoming and outgoing connections is important. Placing outgoing rules before incoming rules may impair Security Server functionality.
Пример правил Nat'а

где: 
DYN_ISP_A - это у нас Primary
DYN_ISP_B -  это - Backup

host объекты l_Primary и  l_Backup - белые адреса от провайдеров.

On the Security Gateway / each member of ClusterXL, run 'cpstop' command. 
To complete the definition of Dynamic Objects, it is necessary to run the following commands on the Security Gateway / each member of ClusterXL:

Note: "DYN_ISP_A" and "DYN_ISP_B" are the names of the objects that represent the first ISP and second ISP, respectively. When running the commands below, you have to use the exact object name from SmartDashboard (case-sensitive).

[Expert@HostName]# dynamic_objects -n DYN_ISP_A
[Expert@HostName]# dynamic_objects -n DYN_ISP_B
[Expert@HostName]# dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a
[Expert@HostName]# dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a

Note: To see the correct usage and syntax, just run 'dynamic_objects' command. 

On the Security Gateway / each member of ClusterXL, edit the $FWDIR/bin/cpisp_update script, and add the following lines at the end of the script - before the "exit" line:

Note: "DYN_ISP_A" and "DYN_ISP_B" are the names of the objects that represent the first ISP and second ISP, respectively. When running the commands below, you have to use the exact object name from SmartDashboard (case-sensitive).

# Verify which link is up with this command: tail -f /tmp/cpisp_state
echo "--------------------------" >> /tmp/cpisp_state
echo `/bin/date +%d-%b-%Y_%Hh-%Mm-%Ss` >> /tmp/cpisp_state
echo "RESTARTING SCRIPT" >> /tmp/cpisp_state
echo "LINK1" >> /tmp/cpisp_state
echo $LINK1_STATE >> /tmp/cpisp_state
echo "LINK2" >> /tmp/cpisp_state
echo $LINK2_STATE >> /tmp/cpisp_state
echo "--------------------------" >> /tmp/cpisp_state
echo " " >> /tmp/cpisp_state

# Check if the Link is up or down
if ($LINK2_STATE == "down") then
fw tab -t dynobj_cache -x -y
dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -a
dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -d
dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a 
endif

if ($LINK1_STATE == "down") then
fw tab -t dynobj_cache -x -y
dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -a
dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -d
dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a 
endif

# if both Links are up, return to Load Sharing
if (($LINK1_STATE == "up") && ($LINK2_STATE == "up")) then
fw tab -t dynobj_cache -x -y
dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -a
dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -a
endif

On the Security Gateway / each member of ClusterXL, run 'cpstart' command. 


In SmartDashboard, install the Security Policy onto Security Gateway/ClusterXL.

!!! Необходимо обратить внимание:
Before upgrading this Security Gateway / Cluster, back up the modified $FWDIR/bin/cpisp_update script because during the upgrade, it will be overwritten by the default script.
After upgrading, replace the default script with your the modified script.

Checkpoint GAIA общие впечатления

Вообще данная заметка была создана еще в 2013 году... но по какой причине оставлена в черновиках. 

Общие впечатления и системе в целом.. " чем дальше в лес, тем толще партизаны"

Оболочка.
CLI:
В целом очень не плохо, все нравится, более привычный интерфейс, больше похож на CLI аля Cisco/JunOS. это сугубо мое мнение. Если что-то не получается из CLI идем в expert и получаем чистый линух, и так приступим:

по умолчанию все интерфейсы кроме Internal/Mgmt - деактивированы, поэтому

# активация интерфейса

set interface DMZ state on

# создание под интерфейса/Vlan'а ID 100 на интерфейсе DMZ
 add interface DMZ vlan 100

# повешать IP адрес
set interface DMZ.100 ipv4-address 192.168.1.1 mask-length 24

# удаление ip адреса с интерфейса, из-за глюков clish'а простая замена иногда не проходила в итого. методом проб и ошибок получил работающий метод

 delete interface DMZ ipv4-address

#Добавление специфического маршрута
set static-route 192.168.0.0/24 nexthop gateway address 192.168.1.254 on

#Добавление маршрута по умолчанию

set static-route default nexthop gateway address 192.168.1.254 on


Web:
Тут всё понятно и приятно, функциональные возможности повторяют CLI, в отличии от SPLAT...
Думаю больше сказать мне нечего, единственное:
в релизе GAIA R75.40VS есть не приятный, очень не приятный БАГ, при создании под интерфейсов >10 на одном физическом интерфейсе, демон confd отжирает почти весь проц, 50-60% и Web'ка перестает отвечать. Данная проблема решена с помощью хотфикса, выпущенного производителем (SR 28-917195161). 

DHCP-relay - очень странно себя ведет... регулярные инсталляции, и везде "танцы с бубном" - но это "Чекпойнт детка" к этому привыкаешь :) по этому поводу будет отдельная запись.


В итого: 
"+" очень удобно и просто реализовано, в отличии от SPLAT сетевая конфигурация.
"-" огорчили не ясные глюки.

фишки Cluster XL Checkpoint

ClusterXL забавная технология от Checkpoint'а.
ниже приведены различные советы и примеры грабель из жизни.

# если на каталике будет включен igmp snooping, то имеем флапинг одной из нод. 
#Up->DOWN 

1-е решение: 
на каталике
  no ip igmp snooping

2-е решение на нодах(перевести режим работы ClusterXL в broadcast)

  в файле $FWDIR/boot/ha_boot.conf

     ha_installed 1 
     ccp_mode broadcast


#или в CLI-expert     cphaconf set_ccp broadcast    ;-работать будет до перезагрузки

Для информации:
# Default settings in the ha_boot.conf file are: 
ha_installed 1 
ccp_mode multicast 

ASA 8.4 nat

ASA 8.4 nat 
! проброс порта во внутрь

interface Vlan3
 nameif PBX
 security-level 90
 ip address 192.168.19.1 255.255.255.0
!
interface Vlan22
 nameif DMZ
 security-level 90
 ip address 192.168.22.253 255.255.255.0

interface Vlan2

 nameif outside
 security-level 0
 ip address XX.XX.XX.XX 255.255.255.240


object network RDP-SRV
 host 192.168.0.6



object network PBX-SRV
 host 192.168.19.42

object service SSH_service
 service tcp destination eq ssh

object service SSH_ext
 service tcp destination eq 2222

object service RDP_service
 service tcp destination eq 3389



nat (outside,DMZ) source dynamic any interface destination static interface RDP-SRV service RDP_service RDP_service
nat (outside,PBX) source dynamic any interface destination static interface PBX-SRV service SSH_ext SSH_service


fw-asa# sh xlate
4 in use, 5 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
       e - extended
TCP PAT from DMZ:192.168.0.6 3389-3389 to outside:XX.XX.XX.XX 3389-3389
    flags srT idle 0:26:11 timeout 0:00:00
TCP PAT from PBX:192.168.19.42 22-22 to outside:XX.XX.XX.XX 2222-2222
    flags srT idle 0:05:25 timeout 0:00:00
TCP PAT from outside_intertax:YY.YY.YY.YY/60269 to PBX:192.168.19.1/60269 flags ri idle 0:10:41 timeout 0:00:30
TCP PAT from outside_intertax:YY.YY.YY.YY/32021 to DMZ:192.168.22.253/32021 flags ri idle 0:26:11 timeout 0:00:30

NAT Cisco ASA 8.4 or later

 Заметка для себя.

Source and Destination NAT.

  Возникла задача нестандартного NATa, а именно подменить и источник и назначения в пакете который идет из публичной сети и пробросить его на RDP сервис. Весь сыр бор заключается в том, что сервер(RDP-SRV) установлен в дрогой подсети.

На руках ASA 5505 8.4, и вот собственно малюсенький конфиг:


Конфигурация объектов:
object network obj_any
 subnet 0.0.0.0 0.0.0.0
object network RDP-SRV
 host 192.168.0.6

Конфигурация интерфейсов:

interface Vlan2

 nameif outside

 security-level 0

 ip address XX.XX.XX.XX 255.255.255.240

!

interface Vlan22

 nameif DMZ

 security-level 90

 ip address 192.168.2.2 255.255.255.0

ciscoasa# sh run route

route outside 0.0.0.0 0.0.0.0 XX.XX.XX.1 1

route DMZ 192.168.0.0 255.255.255.0 192.168.2.1 1

ciscoasa(config)# nat (outside,DMZ) source static any interface destination static interface RDP-SRV

Просмотреть детальный конфиг(получилось два правила, одно ручное, второе- создается автоматом, по умолчанию ):

ciscoasa# sh nat detail

Manual NAT Policies (Section 1)

1 (outside) to (DMZ) source static any interface   destination static interface RDP-SRV

    translate_hits = 3, untranslate_hits = 3

    Source - Origin: 0.0.0.0/0, Translated: 192.168.2.2/24

    !а вот и результат, мы добились трансляции Source

    Destination - Origin: XX.XX.XX.XX/28, Translated: 192.168.0.6/32

    ! и Destination

Auto NAT Policies (Section 2)

1 (inside) to (outside) source dynamic obj_any interface   dns

    translate_hits = 0, untranslate_hits = 0

    Source - Origin: 0.0.0.0/0, Translated: XX.XX.XX.XX/28

Правим списки доступа и радуемся=)