CISCO ASA как роутер для офиса с пробросом портов
Наша задача сегодня состоит в настройке Cisco ASA, мне досталась 5540.
Есть офис, его сеть условно будет 192.168.10.0/24, провайдер выдал статический адрес 1.1.1.2 а гейтвэй будет1.1.1.1.
До кучи нам нужно сделать проброс портов на одну из внутренних машин (Мы зделаем три проброса).
По сути ASA является аппаратным межсетевым экраном, умеет хранить информацию о сессиях.
Работать может в режимах routed (это режим маршрутизатора) и transparent (прозрачный режим).
Мы соответственно будем работать в режиме routed.
Далее я приведу куски из кофига с комментариями.
Имя, версия и домен:
ASA/test.ru# sh run
: Saved
: Hardware: ASA5540, 1024 MB RAM, CPU Pentium 4 2000 MHz
:
ASA Version 9.1(7)6
!
hostname ASA
domain-name test.ru
Интерфейсы:
interface GigabitEthernet0/0
nameif WAN01
security-level 0
ip address 1.1.1.2 255.255.255.252
!
interface GigabitEthernet0/1
nameif VLAN-USER
security-level 50
ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
management-only
shutdown
no nameif
no security-level
no ip address
!
DNS настроечки:
dns domain-lookup WAN01
dns server-group DNS-GRP-01
name-server 8.8.8.8
dns server-group DefaultDNS
domain-name test.ru
dns-group DNS-GRP-01
Объекты сети офиса, машины для проброса и внешний ip ASA:
object network OBJ-SUBNET-VLAN-USER
subnet 192.168.10.0 255.255.255.0
object network OBJ-HOST-SRV01
host 192.168.10.20
Объекты для проброса портов:
object service OBJ-SERVICE-RDP
service tcp destination eq 3389
object service OBJ-SERVICE-MAP01
service tcp destination eq 65320
object service OBJ-SERVICE-MAP02
service tcp destination eq 65420
object service OBJ-SERVICE-MAP03
service tcp destination eq 65020
Создаем группы для протокола ICMP, объекта OBJ-SUBNET-VLAN-USER(сеть офиса) и и объектов проброса портов:
object-group service GRP-SERVICE-ICMP-WAN01
service-object icmp echo-reply
service-object icmp unreachable
object-group service GRP-SERVICE-SRV01
service-object object OBJ-SERVICE-RDP
service-object object OBJ-SERVICE-MAP01
service-object object OBJ-SERVICE-MAP02
Создаем списки доступа (разрешим прохождение пакетов) для группы проброса портов, группы ICMP и офиса:
access-list ACL-WAN01-IN extended permit object-group GRP-SERVICE-SRV01 any object OBJ-HOST-SRV01 log
access-list ACL-WAN01-IN extended permit object-group GRP-SERVICE-ICMP-WAN01 any object OBJ-SUBNET-VLAN-USER
access-list ACL-VALN-USER-IN extended permit ip object OBJ-SUBNET-VLAN-USER any
Навесим списки доступа на интерфейсы:
access-group ACL-WAN01-IN in interface WAN01
access-group ACL-VALN-USER-IN in interface VLAN-USER
Настроим проброс портов статическим NAT:
nat (WAN01,VLAN-USER) source static any any destination static interface OBJ-HOST-SRV01 service OBJ-SERVICE-MAP01 OBJ-SERVICE-MAP01
nat (WAN01,VLAN-USER) source static any any destination static interface OBJ-HOST-SRV01 service OBJ-SERVICE-MAP02 OBJ-SERVICE-MAP02
nat (WAN01,VLAN-USER) source static any any destination static interface OBJ-HOST-SRV01 service OBJ-SERVICE-MAP03 OBJ-SERVICE-RDP
Динамический NAT для офиса:
nat (any,WAN01) after-auto source dynamic OBJ-SUBNET-VLAN-USER interface
Гейтвэй провайдера:
route WAN01 0.0.0.0 0.0.0.0 1.1.1.1 1
Настройка для http сервиса:
http server enable
http 192.168.10.0 255.255.255.0 VLAN-USER
http redirect VLAN-USER 80
Политики инспектирования траффика:
Класс. Какой тип траффика нам интересен? Весь!
class-map inspection_default
match default-inspection-traffic
Политики(действие над классом):
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
Обратите внимание на связь с политикой preset_dns_map и классом inspection_default:
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
В каком направлении будет действовать(исходящий | входящий | весь):
service-policy global_policy global
По сути действиями выше в кратце мы разрешили хождение через ASA определнных протоколов.
На этом все, советую так-же не забыть создать пользователей и организовать доступ ssh.
Cisco asa как маршрутизатор
Добрый день !
Помогите решить проблему.
Есть ASA5505. Настроены два интерфейса — outside и inside ( 192.168.1.1 ).
Адрес ASA для внутренних хостов прописан как default gateway.
Через неё из внутренней сети ходим в Интернет.
В локальной сети есть шлюз ( 192.168.1.10 ), через который настроен доступ в сеть 10.10.10.0
На ASA прописали маршрут:
route inside 10.10.10.1 255.255.255.255 192.168.1.10 1
same-security-traffic permit intra-interface
При этом пинги на 10.10.10.1 из локальной сети идут, а соединение по ssh установить не получается.
Если маршрут прописывать на самом внутреннем хосте напрямую ( не на ASA ) — то всё работает .
Подскажите, pls, что не так в настройте ?
Вот что говорит packet-tracer:
asa(config)# packet-tracer input inside rawip 192.168.1.20 22 10.10.10.10
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.10.10.10 255.255.255.255 inside
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 18685, packet dispatched to next module
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
Не знаю на сколько это ваш случай, но у меня были проблемы с ssh при кривой маршрутизации, такой как у вас.
Смысл в том что улетает с клиента всё через шлюз 1 (АСА) , а назад возвращается уже с другого (192.168.1.10).
Решил перенос второго маршрутизатора из внутренней сети в некую сеть ДМЗ за АСА.
Может нужно прописать, чтобы она при таком маршруте транслировала внутренние IP в свой IP-inside ?
Может как раз по этому ICMP проходит а другие протоколы нет .
Подскажите, как такую трансляцию прописать ? Сам не соображу ..
( тихо сам с собой я веду беседу )))
Подскажите, так ли это : что в приведённой мной выше конфигурации запрос ping с 192.168.1.20 на 10.10.10.1 уходит через ASA ( через её inside ), а ответ возвращается напрямую на 192.168.1.20 ? Поэтому создаётся впечатление что всё здорово работает ?
Так оно и происходит.
Вот влияет ли это на ssh? Я обращал внимание что некоторые устройства не хотят поднимать защищенные соединения при кривой (не симетричной) маршрутизации.
Вообще не симетричную маршрутизацию надо стараться избегать. Потому как она порой приводит к танцам с бубном.
Попробуй зацепиться за какой-то совсем внешний ssh (из дома расшарь, или друзей попроси), если не пройдет то дело в АСЕ если туда соединится тогда стоит покопать в сторону маршрутизации.
Хотя лучше все же перенести твой маршрутизатор который 1.10 куда-то за АСУ, от этого ты точно ничего не потеряешь!
Это не проблема — это называется асимметричная маршрутизация.
Как по мне — неправильное планирование сети.
Но, если Вам так нравится, вот решение Вашей проблемы.
http://www.matthewjwhite.co.uk/blog/201 . firewalls/
Aspir, Nikolay_ спасибо за пояснения и ссылку — сейчас попробую настроить.
Такая конфигурация сети исторически сложилась — когда ещё ASA не было. Со временем поменяем — уберём второй шлюз.
Пока же просто хочется разобраться как это работает.
Ещё раз спасибо.
Да, работает . Сделал ровно так как описано по ссылке.
Можно его не убирать, а сделать отдельную подсеть какую-нибудь 30 за асой в которой будет этот твой маршрутизатор. И пускать на него через АСУ. Или лучше приобрести еще один маршрутизатор и асу вместе с твоим первым за ним спрятать. Потом еще что-то появится туда же засунешь.
Работает конечно . но хочется разобраться что происходит .
Ведь по сути ASA просто меняет в заголовке адрес отправителя на свой . Как иначе ?
В связи с этим вопрос:
Можно ли обойтись без
set connection advanced-options tcp-state-bypass
а решить эту задачу с помощью настройки NAT ??
Не разу такго не пробовал но почемуто кажется что аса врядли даст написать
Nat (inside, inside).
Да и как-то это не логично. Хотя я не пробовал и не знаю, а асы под рукой чтоб проверить это нет)
Так что дерзайте, пробуйте потом расскажите.
Но я все-же заколебу тебя: АССИМЕТРИЧНАЯ МАРШРУТИЗАЦИЯ — ПЛОХО, ПЛОХО, ПЛОХО. ФУ ФУ ФУ ТАК ДЕЛАТЬ.
Идея натить адрес внутреннего хоста в inside ASA. И чтобы всё это безобразие шло на шлюз, который в этой же сети ))
Ну и соответственно пакеты будут возвращаться по этому же маршруту, т.е. не будет ассиметричной маршрутизации.
Ну тут больше академический интерес — можно ли так настроить ??