ASA - routing z inside do inside

Problemy z zakresu security (VPN, firewall, IDS/IPS itp.)

Moderatorzy: mikrobi, garfield, gangrena, Seba, aron, PatrykW

Wiadomość
Autor
Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

ASA - routing z inside do inside

#1

#1 Post autor: Luc@sM »

witam,

napotkałem na problem ze statycznym routingiem na ASA5510. Adres inside na ASA to 192.168.0.1, sieć inside (LAN): 192.168.0.0/22. Komputery maja ustawioną bramę na inside ASY.

W sieci lan postawiłem router z interfejsem 192.168.0.25/22 i siecią (10.10.200.0/24). Na routerze jest default route na adres inside ASY. Chciałbym, żeby niektóre komputery w sieci inside miały dostęp do sieci 10.10.200.0.

Dodałem wpis do tablicy routingu na ASA:

route inside 10.10.20.0 255.255.255.0 192.168.0.25

Z poziomu ASY pinuję adresy z sieci 10.10.20.0/24.

Natomiast nie pinguję sieci 10... z komputerów pracujących w podsieci 192.168.0.0/22 - w logu pojawia się wpis:

Kod: Zaznacz cały

3	Aug 19 2012	10:22:14		10.10.20.180		portmap translation creation failed for icmp src inside:192.168.1.21 dst inside:10.10.20.180 (type 8, code 0)
Czego mi jeszcze brakuje do działania takiej konfiguracji?

Dodam, że mam wpisy:
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface


pozdrawiam

hangie
wannabe
wannabe
Posty: 229
Rejestracja: 01 maja 2007, 21:18
Lokalizacja: Londyn

#2

#2 Post autor: hangie »

Pokaz

Kod: Zaznacz cały

sh run nat
Pozdrawiam
Krzysztof Goławski

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#3

#3 Post autor: Luc@sM »

natowi podlega cała podsieć 192.168.0.0/22

Kod: Zaznacz cały

nat (outside) 0 access-list vpn-to-siech
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 192.168.0.0 255.255.252.0

hangie
wannabe
wannabe
Posty: 229
Rejestracja: 01 maja 2007, 21:18
Lokalizacja: Londyn

#4

#4 Post autor: hangie »

Widze ze masz stara wersje (przed 8.3).

Dawno juz starego natu nie ruszalem. W skrocie teraz asa najprawdopodobniej probujue natowac ruch miedzy tymi dwoma sieciami.

Sprobuj dodac siec docelowa do inside_nat0_outbound gdyz to pewnie ACL robioaca wyjatek dla VPN.

Warto tez sprawdzic co sie dzieje z pakietami w packet tracerze (skladnia z pamieci):

Kod: Zaznacz cały

packet-tracer input inside icmp 192.168.1.21 8 10.10.20.18 det
Pozdrawiam
Krzysztof Goławski

Awatar użytkownika
frontier
wannabe
wannabe
Posty: 1849
Rejestracja: 16 lis 2004, 13:55
Lokalizacja: Edinburgh

#5

#5 Post autor: frontier »

Masz problem z NATem ale musialbys cos wiecej z konfiga pokazac, najlepiej caly. Testowo wywal wszystkie komendy NAT i powinno dzialac.
Jeden konfig wart więcej niż tysiąc słów

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#6

#6 Post autor: Luc@sM »

komputer w sieci odwołuje się do default gatewaya (ASA), który powinien zawinąć ruch z powrotem, gdyż next hop znajduje się w sieci komputera. NAT działa zawsze pomiędzy parą interfejsów - a w przypadku kiedy ruch przychodzi i wychodzi tym samym interfejsem (inside) też działa NAT?

Jeżeli chodzi o NAT w moim configu, to mam NAT "0" do VPN oraz PAT do wyjścia inside na outside.

Awatar użytkownika
Dzastiz
CCIE
CCIE
Posty: 74
Rejestracja: 25 wrz 2011, 13:36
Lokalizacja: Warszawa

#7

#7 Post autor: Dzastiz »

Nie ma znaczenia, czy para interfejsów to (inside,inside) czy (inside,outside). Dopóki na interfejsie 'inside' robisz NAT dla 192.168.0.0/22 i masz wpisaną komendę 'nat (inside) 1' dla tego zakresu, ASA będzie szukać odpowiednika w postaci 'global' dla interfejsu wyjściowego. A u Ciebie wyjściowym interfejsem jest inside.

hangie podpowiedział Ci już uruchomienie packet-tracer'a - znajdziesz tam odpowiedź dlaczego komunikacja nie działa. Powinieneś zobaczyć tam mniej więcej coś takiego:

Kod: Zaznacz cały

Phase: 9
Type: NAT
Subtype: 
Result: DROP
Config:
nat (inside) 1 192.168.0.0 255.255.252.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
Dopisz komunikację między 192.168.0.0/22 i 10.10.20.0/24 do nat 0, jak Ci koledzy sugerują :-)

Kod: Zaznacz cały

access-list inside_nat0_outbound permit ip 192.168.0.0 255.255.252.0 10.10.20.0 255.255.255.0
Knowledge is power.

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#8

#8 Post autor: Luc@sM »

dzięki za pomoc. faktycznie problem był z natem.

zrobiłem rekonfigurację sieci i zamiast używania routera skonfigurowałem routing na switchu HP 5412zl, który obsługuje dwa vlany (10.10.20.0/24 i 192.168.0.0/21). Vany mają IP odpowiednio: 10.10.20.1 i 192.168.0.25. Default route na switchu wskazuje na ASA (192.168.0.1).

Po podłączeniu hostów do podsieci 10.x ucieszyłem się, gdyż wszystko ładnie się pinguje, np. pinguję z stacji 192.168.1.21 adres 10.10.20.180 (jest to serwer).

Ale zauważyłem, że po RDP do serwera podłączyć się nie mogę. Nie jest to problem z RDP, bo po zmianie bramy na stacji (192.168.1.21) ze 192.168.0.1 na 192.168.0.25 połączyć po RDP się mogę. To samo się tyczy urządzeń pracujących w podsieci 10.x, do których próbuję się połączyć po http lub https. Po zmianei bramy łącze się normalnie.

Sprawdziłem komunikację packet-tracerem i zmodyfikowałem access-listy. Dodałem:

Kod: Zaznacz cały

access-list inside_access_in extended permit ip 192.168.0.0 255.255.248.0 10.10.20.0 255.255.255.0
access-list inside_access_out extended permit ip any any
Obecnie wynik packet-tracer input inside tcp 192.168.1.21 2793 10.10.20.100 http pokazuje mi:

Kod: Zaznacz cały

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
Mimo to, nadal http czy rdp nie działa... w logach ASA jest wpis:

Kod: Zaznacz cały

Deny TCP (no connection) from 192.168.1.21/5872 to 10.10.20.180/3389 flags RST  on interface inside

Zrobiłem dalsze badanie - w drugą stronę:

Kod: Zaznacz cały

hl-asa-1# packet-tracer input inside tcp 10.10.20.100 http 192.168.1.21 2793 de

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   inside-network  255.255.248.0   inside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xaba4c4f8, priority=11, domain=permit, deny=true
        hits=14, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
W czym może tkwić problem?

Awatar użytkownika
conip
wannabe
wannabe
Posty: 134
Rejestracja: 14 maja 2007, 12:39

#9

#9 Post autor: conip »

zamiast opisywac skrotowo co teraz zmieniles mozesz wkleic aktualny konfig? oraz opis - ta stacja ma ten gateway itp ?

czarli
member
member
Posty: 16
Rejestracja: 12 sty 2011, 12:18
Kontakt:

#10

#10 Post autor: czarli »

A moze bys tak dodal:

access-list inside_access_in extended permit ip 10.10.20.0 255.255.255.0 192.168.0.0 255.255.248.0

Skoro obie sieci sa za tym samym miedzy-mordziem (ang. interface ) :) to powinienes dodac permit w obie strony. Szczegolnie ze nie wszystkie protokoly sa stateful i ASA zablokuje powracajace pakiety (np. ICMP).

Packet tracer w ktorym "symulujesz" roch powrotny nie zadzila bo ASA nie widzi polaczenia w connection table :]

Mam nadzieje ze to co napisalem ma jakis sens.

Pozdrawiam

--------------------------------------------------------
itlibrary.net

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#11

#11 Post autor: Luc@sM »

w związku z czasochłonnym trobleshuttingiem przeniosłem routing na aske, zrobiłem vlan na eth 0/3:

Kod: Zaznacz cały

interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 192.168.0.1 255.255.248.0 standby 192.168.0.2

interface Ethernet0/3
 description !Interface for vlans only!
 no nameif
 no security-level
 no ip address
!
interface Ethernet0/3.20
 description !Interface for lan management network!
 vlan 20
 nameif mgmt
 security-level 80
 ip address 10.10.20.254 255.255.255.0 standby 10.10.20.253
Oczywiście aclki przepuszczają mi cały ruch ip z inside>mgmt i odwrotnie.
Poprzednio ip eth 0/3.20 był ustawiony na 10.10.20.1, ale musiałem go zmienić, gdyż jest on wykorzystywany przez jeden serwer. Teraz z podsieci 192... łącze się czym chcę do serwerów i urządzeń w lanie 10... i wszystko pięknie działa, za jednym wyjątkiem. Mam problem z połączeniem się do hosta o ip poprzedniej bramy [10.10.20.1/24, brama:10.10.20.254].

Np. z pc o adresie 192.168.1.21 mogę tylko pingować serwer 10.10.20.1. Nie mogę dostać się przez przeglądarkę (http,https) na ten serwer. Będąc podłączonym w lanie 10... bez problemu dostaję się na serwer.

W syslogu mam logi:

Kod: Zaznacz cały

2012-09-19 11:59:10,Local4.Info,192.168.0.1,Sep 19 2012 11:55:14: %ASA-6-302013: Built outbound TCP connection 3340930 for mgmt:10.10.20.1/443 (10.10.20.1/443) to inside:192.168.1.21/3786 (192.168.1.21/3786)

2012-09-19 11:59:10,Local4.Info,192.168.0.1,Sep 19 2012 11:55:14: %ASA-6-302014: Teardown TCP connection 3340930 for mgmt:10.10.20.1/443 to inside:192.168.1.21/3786 duration 0:00:00 bytes 0 TCP Reset-I

2012-09-19 11:59:13,Local4.Info,192.168.0.1,Sep 19 2012 11:55:17: %ASA-6-106015: Deny TCP (no connection) from 192.168.1.21/3786 to 10.10.20.1/443 flags RST  on interface inside
Walczę już z problemem drugi dzień, w czym może tkwić problem? Dodam, że zmieniłem również IP tego serwera na 10.10.20.2, co nie zmieniło sytuacji.

pozdrawiam

Awatar użytkownika
conip
wannabe
wannabe
Posty: 134
Rejestracja: 14 maja 2007, 12:39

#12

#12 Post autor: conip »

wg loga ASA zauważyła RST polączenia i dlatego masz pozniej DENY bo nie ma juz w tablicy conn takiego polaczenia.

pozostaje Ci chyba sprawdzic na ASA packet-capture na tych interfejsach i odpalić Wiresharka, wówczas wyjaśni się co wysyła RST dla tej sesji.

czy nie masz IPSa albo inny wynalazek który mogłby uwalać ten flow?
Name: reset-in
TCP Reset-I:
This reason is given for closing an outbound flow (from a low-security interface to a
same- or high-security interface) when a TCP reset is received on the flow.
Recommendation:
None.
Syslogs:
302014
----------------------------------------------------------------
Name: reset-out
TCP Reset-O:
This reason is given for closing an inbound flow (from a high-security interface to
low-security interface) when a TCP reset is received on the flow.
Recommendation:
None.
Syslogs:
302014

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#13

#13 Post autor: Luc@sM »

w podsieci 10... znajdują się 2 esx'y (VM 5.0) o adresach ip (management): 10.10.20.1 i 10.10.20.3. Są to identyczne serwery. Z łączeniem się do 10.10.20.3 (na porty 80, 443) z lanu 192... nie mam żadnego problemu, natomiast mam problem z 10.10.20.1. IPSa nie mam w sieci, mam proxy, ale wyłączyłem je tymczasowo w przeglądarce, żeby wykluczyć problem z proxy.

Ciekawostką jest to, że np. z serwera o IP: 192.168.0.254 łącze się do 10.10.20.1 komendą telnet 10.10.20.1 80, czyli wychodzi na to, że problem jest z ruchem powrotnym

komenda:

Kod: Zaznacz cały

sh conn | inc 10.10.20.1
nie pokazuje żadnych wpisów

Awatar użytkownika
conip
wannabe
wannabe
Posty: 134
Rejestracja: 14 maja 2007, 12:39

#14

#14 Post autor: conip »

ponieważ nie wkleiles calego konfigu ASA - zakladam ze masz analogiczną konfigurację reguł ACL, inspekcji czy co tam innego. Skoro na 10.10.20.3 działa to pozostaje tylko zweryfikować przy uzyciu packet-capture (i wiresharka) ze RST jest od ESXa faktycznie wysylany i tam szukać problemu.
wyczysc moze arpy na urządzeniach moze to wcale nie ESX odpowiada skoro kilkukrotnie zmieniales jakiest tam IP i readresacje robiles.

przede wszystkim wireshark bym wciagnal do roboty

Luc@sM
wannabe
wannabe
Posty: 94
Rejestracja: 29 cze 2009, 13:23

#15

#15 Post autor: Luc@sM »

witam,

dziękuję wszystkim za pomoc. Okazało się, że esx nie odpowiada wcale na ruch generowany z innej podsieci. Przeinstalowanie esx'a na nowo rozwiązało problem.
Swoją drogą ciekawostka sieciowa...

ODPOWIEDZ