Ponieważ opisywane przeze mnie problemy z IPSec stawały się dla mnie coraz bardziej uciążliwe, postanowiłem je zacząć dokładniej diagnozować. W tym celu uruchomiłem tcpdump na ral0 i fxp0 oraz uruchomiłem isakmpd z opcją -L. W efekcie zebrałem trochę materiału, nawet ciekawego dość, przyznać muszę. Wygląda na to, że Windows... cieknie...
Windows cieknie?
Na czym to cieknięcie polega? Zacznijmy od drobnego przypomnienia:
Generic Tunnel Filters
------------------------------
Generic Tunnel Filter #1: Name : 1 Filter Id :
{C415DE3A-C3A7-4C3C-95F7-B49C0C638A6C} Policy Id :
{E6D0A0CC-14FB-4547-85FD-EE57A08A754E} Name : 3DES-SHA1-PFS Policy Id :
{E6D0A0CC-14FB-4547-85FD-EE57A08A754E} Flags : 1 (Tunnel) Offer #1 Algo
#1 : Encryption 3DES SHA1 PFS : True (Group 2147483648), Lifetime
0Kbytes/1200seconds Src Addr : Any Des Addr : 172.16.0.20 Src Tunnel
Addr : Any Des Tunnel Addr : 172.16.0.20 Protocol : 0 Src Port : 0 Des
Port : 0 Mirrored : False Interface Type : LAN<
Generic Tunnel Filter #2: Name : 2 Filter Id :
{FBFDB18B-1949-41DC-A7FA-A95E8DAACB8F} Policy Id :
{E6D0A0CC-14FB-4547-85FD-EE57A08A754E} Name : 3DES-SHA1-PFS Policy Id :
{E6D0A0CC-14FB-4547-85FD-EE57A08A754E} Flags : 1 (Tunnel) Offer #1 Algo
#1 : Encryption 3DES SHA1 PFS : True (Group 2147483648), Lifetime
0Kbytes/1200seconds Src Addr : 172.16.0.20 Des Addr : Any Src Tunnel
Addr : Any Des Tunnel Addr : 172.16.0.254 Protocol : 0 Src Port : 0 Des
Port : 0 Mirrored : False Interface Type : LAN
Jak widać (mam nadzieję) wyraźnie, filtry, jakie są skonfigurowane dla IPSec powinny wymuszać to, że każdy pakiet przychodzący lub wychodzący z komputera jest chroniony. Wyjątkiem jest (czego już nie widać, bo tych filtrów nie wklejałem) ruch związany z DHCP.
To teraz pokażę jaki ruch pojawił się na ral0...
1 0.000000 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x4eacb008 2 0.002046 172.16.0.254 -> 172.16.0.20 DHCP DHCP Offer - Transaction ID 0x4eacb008 3 0.003191 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0x4eacb008 4 0.004776 172.16.0.254 -> 172.16.0.20 DHCP DHCP ACK - Transaction ID 0x4eacb008 5 0.009413 00:13:02:aa:ef:93 -> ff:ff:ff:ff:ff:ff ARP Who has 172.16.0.20? Gratuitous ARP 6 0.610522 00:13:02:aa:ef:93 -> ff:ff:ff:ff:ff:ff ARP Who has 172.16.0.20? Gratuitous ARP 7 0.669296 172.16.0.20 -> 172.16.0.254 ISAKMP Identity Protection (Main Mode) 8 0.670998 172.16.0.254 -> 172.16.0.20 ISAKMP Identity Protection (Main Mode) 9 0.738149 172.16.0.20 -> 172.16.0.254 ISAKMP Identity Protection (Main Mode) 10 0.763281 172.16.0.254 -> 172.16.0.20 ISAKMP Identity Protection (Main Mode) 11 0.795876 172.16.0.20 -> 172.16.0.254 ISAKMP Identity Protection (Main Mode) 12 0.795984 172.16.0.20 -> 172.16.0.254 IP Fragmented IP protocol (proto=UDP 0x11, off=1480) 13 0.826658 172.16.0.254 -> 172.16.0.20 ISAKMP Identity Protection (Main Mode) 14 1.613432 00:13:02:aa:ef:93 -> ff:ff:ff:ff:ff:ff ARP Who has 172.16.0.20? Gratuitous ARP 15 1.635313 172.16.0.20 -> 172.16.0.254 ISAKMP Identity Protection (Main Mode) 16 1.635362 172.16.0.20 -> 172.16.0.254 IP Fragmented IP protocol (proto=UDP 0x11, off=1480) 17 1.639284 172.16.0.254 -> 172.16.0.20 ISAKMP Identity Protection (Main Mode) 18 2.695695 172.16.0.20 -> 192.168.1.254 DNS Standard query A 0.pool.ntp.org 19 2.696451 172.16.0.20 -> 192.168.1.254 DNS Standard query A pool.barska.home 20 2.696718 172.16.0.20 -> 255.255.255.255 DHCP DHCP Inform - Transaction ID 0x61cb4946 21 2.763824 172.16.0.254 -> 172.16.0.20 ISAKMP Quick Mode 22 2.764058 172.16.0.254 -> 172.16.0.20 ISAKMP Quick Mode 23 2.834692 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 24 2.835896 172.16.0.254 -> 172.16.0.20 ISAKMP Quick Mode 25 2.915405 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 26 2.915518 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 27 2.918351 172.16.0.254 -> 172.16.0.20 ISAKMP Quick Mode 28 2.921125 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 29 2.947999 172.16.0.254 -> 172.16.0.20 ISAKMP Informational 30 2.949911 172.16.0.254 -> 172.16.0.20 ISAKMP Informational 31 3.653947 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 32 3.654392 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 33 4.637341 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 34 4.637611 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 35 5.626545 172.16.0.20 -> 255.255.255.255 DHCP DHCP Inform - Transaction ID 0x61cb4946 36 6.614233 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 37 6.630769 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 38 10.619332 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 39 10.625995 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 40 13.668412 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7) 41 13.668647 172.16.0.20 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0xdb46bbd5 42 13.680597 172.16.0.254 -> 172.16.0.20 DHCP DHCP ACK - Transaction ID 0xdb46bbd5 43 13.684527 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 44 13.697910 172.16.0.20 -> 192.168.1.254 DHCP DHCP Request - Transaction ID 0x65043720 45 13.699552 172.16.0.254 -> 172.16.0.20 DHCP DHCP ACK - Transaction ID 0x65043720 46 13.710701 172.16.0.254 -> 172.16.0.20 ISAKMP Quick Mode 47 13.731285 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x5dc94a4c) 48 13.732756 172.16.0.20 -> 172.16.0.254 ISAKMP Quick Mode 49 14.626120 172.16.0.20 -> 172.16.0.254 ESP ESP (SPI=0x1a926da7)
Pierwsze cztery pakiety są związane z uzyskiwaniem adresu IP z serwera DHCP. 5 i 6 o tak zwany gratuitous ARP, czyli stacja sprawdza, czy aby na pewno adres, który został przydzielony przez serwer DHCP nie jest już przez kogoś zajęty. od 7 do 17 to negocjacja ISAKMP Identity Protection, czyli upraszczając - wzajemne uwierzytelnienie dwóch komputerów. Ładnie to widać w logach isakmpd, ale ponieważ to nie jest istotne, tutaj wklejać tych logów nie będę.
Ciekawa rzecz dzieje się w pakiecie 18 i 19. Nie mogę w żaden sposób pojąć dlaczego dwa zapytania o adres są przesyłane do serwera bez wymaganej ochrony. Zapytania te są inicjowane na pewno przez usługę w32tm, ponieważ zarówno 0.pool.ntp.org, jak i pool.barska.home są skonfigurowane właśnie dla tej usługi jako źródła czasu.
A co się dzieje na drugim interfejsie (fxp0):
1 0.000000 172.16.0.254 -> 172.16.254.1 DHCP DHCP Discover - Transaction ID 0x4eacb008 2 0.001665 172.16.254.1 -> 172.16.0.254 DHCP DHCP Offer - Transaction ID 0x4eacb008 3 0.003016 172.16.0.254 -> 172.16.254.1 DHCP DHCP Request - Transaction ID0x4eacb008 4 0.004423 172.16.254.1 -> 172.16.0.254 DHCP DHCP ACK - Transaction ID 0x4eacb008 5 2.696638 172.16.0.254 -> 172.16.254.1 DHCP DHCP Inform - Transaction ID 0x61cb4946 6 2.698015 172.16.254.1 -> 172.16.0.20 DHCP DHCP ACK - Transaction ID 0x61cb4946 7 3.653916 172.16.0.20 -> 192.168.1.254 DNS Standard query A 0.pool.ntp.org 8 3.654201 172.16.0.20 -> 192.168.1.254 DNS Standard query A pool.barska.home 9 3.655858 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 212.90.124.2 A 81.169.183.159 A 195.230.70.112 A 212.186.110.32 A 217.150.242.8 A 130.60.75.60 A 207.5.137.134 A 82.92.197.115 A 147.83.205.92 A 84.16.227.214 A 66.36.243.18 A 62.44.101.22 10 3.656574 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254 A 172.16.0.254 11 4.637209 172.16.0.20 -> 192.168.1.254 DNS Standard query A 0.pool.ntp.org 12 4.637407 172.16.0.20 -> 192.168.1.254 DNS Standard query A pool.barska.home 13 4.638497 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 212.90.124.2 A 81.169.183.159 A 195.230.70.112 A 212.186.110.32 A 217.150.242.8 A 130.60.75.60 A 207.5.137.134 A 82.92.197.115 A 147.83.205.92 A 84.16.227.214 A 66.36.243.18 A 62.44.101.22 14 4.639209 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254 A 172.16.0.254 15 4.998793 00:e0:4c:e7:f9:b6 -> 00:02:a5:1e:5a:3e ARP Who has 172.16.254.2? Tell 172.16.254.1 16 4.998809 00:02:a5:1e:5a:3e -> 00:e0:4c:e7:f9:b6 ARP 172.16.254.2 is at 00:02:a5:1e:5a:3e 17 5.626425 172.16.0.254 -> 172.16.254.1 DHCP DHCP Inform - Transaction ID 0x61cb4946 18 5.627723 172.16.254.1 -> 172.16.0.20 DHCP DHCP ACK - Transaction ID 0x61cb4946 19 6.614112 172.16.0.20 -> 192.168.1.254 DNS Standard query A 0.pool.ntp.org 20 6.615124 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 212.90.124.2 A 81.169.183.159 A 195.230.70.112 A 212.186.110.32 A 217.150.242.8 A 130.60.75.60 A 207.5.137.134 A 82.92.197.115 A 147.83.205.92 A 84.16.227.214 A 66.36.243.18 A 62.44.101.22 21 6.630567 172.16.0.20 -> 192.168.1.254 DNS Standard query A pool.barska.home 22 6.631363 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254 A 172.16.0.254 23 10.619172 172.16.0.20 -> 192.168.1.254 DNS Standard query A 0.pool.ntp.org 24 10.620138 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 212.90.124.2 A 81.169.183.159 A 195.230.70.112 A 212.186.110.32 A 217.150.242.8 A 130.60.75.60 A 207.5.137.134 A 82.92.197.115 A 147.83.205.92 A 84.16.227.214 A 66.36.243.18 A 62.44.101.22 25 10.625794 172.16.0.20 -> 192.168.1.254 DNS Standard query A pool.barska.home 26 10.626597 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254 A 172.16.0.254 27 13.668475 172.16.0.20 -> 192.168.1.254 DNS Standard query A wpad.BARSKA.HOME 28 13.668589 172.16.0.254 -> 172.16.254.1 DHCP DHCP Request - Transaction ID 0xdb46bbd5 29 13.669995 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254 30 13.671418 172.16.254.1 -> 172.16.0.254 DHCP DHCP ACK - Transaction ID 0xdb46bbd5 31 13.697794 172.16.0.254 -> 172.16.254.1 DHCP DHCP Request - Transaction ID 0x65043720 32 13.699182 172.16.254.1 -> 172.16.0.254 DHCP DHCP ACK - Transaction ID 0x65043720 33 14.626036 172.16.0.20 -> 192.168.1.254 DNS Standard query A wpad.BARSKA.HOME 34 14.626973 192.168.1.254 -> 172.16.0.20 DNS Standard query response A 192.168.1.254
Jak widać do 5 pakietu jest w porządku. Ale pakiet 6 już nie ma swojego odpowiednika w zrzucie na ral0. Wynika to prawdopodobnie z tego, że OpenBSD stara się ten pakiet zabezpieczyć przez IPSec (do następnego testu jeszcze dołącz zrzut na enc0). Zapytania DNS o 0.pool.ntp.org oraz o pool.barska.home pojawiają się na fxp0 dopiero w 7 i 8 pakiecie (3.65... od pierwszego pakietu), co pozwala dopasować te dwa pakiety do pakietów 31 i 32 z ral0, które są już chronione ładnie przez IPSec... i tutaj warto popatrzeć w logi z isakmpd. Pierwsze dwa pakiety wymienione w ramach quick mode (które inicjuje 172.16.0.254, odpowiadają one pakietom 21 i 22 w zrzucie z ral0):
18:13:32.428562 172.16.0.254.500 > 172.16.0.20.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 99d2fa1a len: 280 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x1a926da7 payload: TRANSFORM len: 28 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 [ttl 0] (id 1, len 308) 18:13:32.454126 172.16.0.254.500 > 172.16.0.20.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 2f57a0d3 len: 280 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x8dc565b5 payload: TRANSFORM len: 28 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 12 type: IPV4_ADDR = 172.16.254.1 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 [ttl 0] (id 1, len 308)
Przypuszczam, że negocjacja tunelu do 192.168.1.254 została wyzwolona przez pytanie do DNS z pakietu 18 i 19. Tunel do 172.16.254.1 jest prawdopodobnie związany z DHCP Inform z pakietu 20. Na tak rozpoczęte negojacje 172.16.0.20 potulnie odpowiada:
18:13:32.542635 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE commit cookie: 6fe483c6d88140e8->663216506729f503 msgid: 99d2fa1a len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x900eff51 payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: KEY_EXCH len: 132 payload: NONCE len: 24 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 [ttl 0] (id 1, len 320) 18:13:32.623511 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE commit cookie: 6fe483c6d88140e8->663216506729f503 msgid: 2f57a0d3 len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x9d088ed2 payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: KEY_EXCH len: 132 payload: NONCE len: 24 payload: ID len: 12 type: IPV4_ADDR = 172.16.254.1 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 [ttl 0] (id 1, len 320)
Mapuje się to do pakietu 23 i pakietu 26. Chwilę później natomiast zaczyna się negocjacja tego, co skonfigurowane zostało dla 172.16.0.20 (pakiety 43 i 46):
18:13:43.392447 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: cb05687a len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xce87bf63 payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: KEY_EXCH len: 132 payload: NONCE len: 24 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 320) 18:13:43.417307 172.16.0.254.500 > 172.16.0.20.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: cb05687a len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x5dc94a4c payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 24 payload: KEY_EXCH len: 132 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 320)
Jak widać wszystko jest piękne, negocjowanie rozpoczął komputer 172.16.0.20, zgodnie ze swoją konfiguracją stara się wynegocjować tunel dla wszystkich pakietów wychodzących z 172.16.0.20 do 0.0.0.0/0.0.0.0.
Następnie 172.16.0.20 informuje o usunięciu dwóch SA:
18:19:27.319160 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 6fe483c6d88140e8->663216506729f503 msgid: aae37a3c len: 68 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x9d088ed2 [ttl 0] (id 1, len 96) 18:19:27.380513 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 6fe483c6d88140e8->663216506729f503 msgid: 918f01f9 len: 68 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x900eff51 [ttl 0] (id 1, len 96)
Ale chyba tylko po to, by chwilę później znowu takie tunele wynegocjować:
18:19:29.451976 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 11d5a6f0 len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x90ce8678 payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: KEY_EXCH len: 132 payload: NONCE len: 24 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 [ttl 0] (id 1, len 320) 18:19:29.476098 172.16.0.254.500 > 172.16.0.20.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 11d5a6f0 len: 288 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x74b2ae7c payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 24 payload: KEY_EXCH len: 132 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 [ttl 0] (id 1, len 316)
Komputer 172.16.0.20 rozpoczyna negocjację tunelu dla ruchu z 172.16.0.20 do 192.168.1.254. Po co to robi? Z jakiegoś powodu pakiet taki musiał trafić w jakiś bardziej pasujący do niego filtr. Tylko filtry jakie są, to podałem wcześniej, nie ma tam żadnego "lepiej pasującego" do pakietów kierowanych na adres 192.168.1.254! 6 sekund później sytuacja się powtarza:
18:25:29.588703 172.16.0.20.500 > 172.16.0.254.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 80496ae2 len: 292 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xae64e8a7 payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: KEY_EXCH len: 132 payload: NONCE len: 24 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 [ttl 0] (id 1, len 320) 18:25:29.612905 172.16.0.254.500 > 172.16.0.20.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 6fe483c6d88140e8->663216506729f503 msgid: 80496ae2 len: 288 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x62d5004a payload: TRANSFORM len: 32 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 000004b0 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 24 payload: KEY_EXCH len: 132 payload: ID len: 12 type: IPV4_ADDR = 172.16.0.20 payload: ID len: 12 type: IPV4_ADDR = 192.168.1.254 [ttl 0] (id 1, len 316)
...wkrótce nowe odcinki tej pasjonującej sagi...
