У меня есть недавно приобретенный беспроводной маршрутизатор cisco rv220w. Моя установка выглядит следующим образом:

Internet -> asa 5505 -> 10.0.1.0 subnet -> wireless router

(подсеть 10.0.3.0, публичный ip - 10.0.1.140).

Я могу нормально пропинговать между двумя подсетями, но не намного. Я сделал захват пакета с помощью wireshark и заметил кое-что действительно интересное. Если я пытаюсь подключиться с компьютера из подсети 10.0.1.0 к подсети 10.0.3.0, скажем, для удаленного рабочего стола для этого примера, я получаю SYN, затем SYN_ACK, а затем не ACK обратно. От устройства, инициирующего соединение, отправляется только сброс (RST).

Это супер странно. Любая помощь будет оценена. У меня есть подробные снимки, если это необходимо. Кроме того, вот результат трассировки пакетов, скажем .. компьютер в подсети 10.0.1.0, пытающийся удаленно подключиться к компьютеру в подсети 10.0.3.0:

packet-tracer input inside tcp 10.0.1.46 33000 10.0.3.151 3389

Phase: 1
Type: FLOW-LOOKUP`
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.0.3.0        255.255.255.0   inside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit tcp any any object-group DM_INLINE_TCP_1
object-group service DM_INLINE_TCP_1 tcp
 group-object ftpdatatls
 group-object ftptls
 group-object gtalk
 group-object imapssl
 group-object smtp2
 group-object smtpssl
 group-object sqlserver
 port-object eq ftp
 port-object eq ftp-data
 port-object eq www
 port-object eq https
 port-object eq imap4
 port-object eq pop3
 port-object eq smtp
 port-object eq ssh
 port-object eq telnet
 group-object internetradio
 port-object eq whois
 group-object webmail
 group-object rdp
 group-object mtbogcweb
 group-object git
 group-object iCloudSMTP
 group-object whm
 group-object utahsde
 port-object eq 1401
 port-object eq 5442
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
  match ip inside 10.0.1.0 255.255.255.0 inside 10.0.3.0 255.255.255.0
    NAT exempt
    translate_hits = 23, untranslate_hits = 0
Additional Information:

Phase: 7
Type: NAT-EXEMPT
Subtype: rpf-check
Result: ALLOW
Config:
  match ip inside 10.0.3.0 255.255.255.0 inside 10.0.1.0 255.255.255.0
    NAT exempt
    translate_hits = 0, untranslate_hits = 23
Additional Information:

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 9
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 11
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 13
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 77684, 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
|источник

2 ответа2

0

Если я правильно понял, ваша полная настройка:

Интернет -> ASA 5505 -> 10.0.1.0 подсеть -> беспроводной маршрутизатор -> 10.0.3.0 подсеть

Поскольку беспроводной маршрутизатор является новым, я предполагаю, что все ПК в подсети 10.0.1.0 используют asa 5505 в качестве шлюза по умолчанию. В результате пакеты, поступающие с 10.0.1.0 по 10.0.3.0, транслируются в пул 1, что каким-то образом мешает потоку пакетов.

Попробуйте:1. Изменить шлюз по умолчанию для всех ПК в подсети 10.0.1.0 на беспроводной маршрутизатор или 2. отключить подключение к пулу 1

|источник
0

Итак, в конечном итоге кто-то из Reddit указал мне в правильном направлении. Решение, которое сработало для меня, находится здесь: https://serverfault.com/questions/511059/routing-via-cisco-asa-is-changing-tcp-sequence-ack-numbers.

Похоже, что ASA рандомизировала порядковые номера, что сбивало с толку беспроводной маршрутизатор. В частности, я добавил

set connection advanced-options tcp-state-bypass

к моей глобальной политике проверки.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .