Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: LukasD 31. 08. 2017, 07:21:45
-
Snažím se vytvořit tunel pomocí IPsec (site-site) zatím jen v testovacím prostředí.
Mám dvě veřejné IP ve dvou městech.
1. město
IP: 192.168.13.99 (veřejná IP: 172.217.23.195)
2. město
IP: 10.10.20.99 (veřejná IP: 172.217.23.206)
Když použiji dva Mikrotiky, tak není problém, vše funguje jak má.
Jenže jakmile místo jednoho Mikrotiku použiju IPFire, tunel se mi vůbec nedaří zprovoznit.
Když jsem testoval všechny možné nastavení, tak se mi tunel podařilo zprovoznit pouze v rámci prvního města, když jsem měl Mikrotik a IPFire vedle sebe.
IPFire:
IP: 192.168.13.99 (veřejná IP: 172.217.23.195)
Mikrotik:
IP: 192.168.13.120 (veřejná IP: 172.217.23.196)
Když v IPFrie zadám lokální adresy (nikde nezadávám veřejnou), tak s tunelem není problém a vše se naváže jak má. V Global Settings (IPsec) je parametr pod názvem „Public IP or FQDN for RED interface or <%defaultroute>:“ a když tam zadám 192.168.13.99 tak je to ok, jenže když bych nastavil 172.217.23.195 tak se mi to žádným způsobem nedaří zprovoznit ani v rámci města ani v rámci dvou měst.
Poradil byste někdo v čem by mohl být problém?
PS: U Mikrotiků stačilo zadat lokální adresy 192.168.13.99, 10.10.20.99 a druhá strana je viděla normálně pod veřejnou, jako je tomu u většiny systémů.
Případně sem mohu vložit logy z IPFire, ale problém bude asi s nějakou routou nebo v čem.
-
Poradit neumím, ale můžu potvrdit, že podobné problémy jsem také zažil (v mém případě bylo na druhé straně FreeBSD). Nakonec jsem ztratil nervy a přehodil jsem tunel na GRE, což mi zafungovalo správně. Nijak hlouběji jsem to už pak nezkoumal, ale myšlenky, které jsem měl, a na které můžete možná navázat byly: 1) tunely nejsou připravené na NAT, chtějí být (rozumně) stateless, 2) nesoulad IP po NATU = bazální narušení bezpečnosti, které musí být protokolem podchyceno.
Moje řešení tedy nakonec bylo stanovení pořadí podle situace: 1) ipip, 2) gre, 3) jakákoliv VPN (statefull).
-
A končí navázání spojení nějakou konkrétní chybou? Dají se ta zařízení přepnout do nějakého debug módu, aby třeba řekla v logu co přesně se jim nelíbí?
-
Vim, ze Mikrotiky mivaly problemy pokud na druhem konci bylo neco jineho....u nas to bylo Cisco a bylo to dost peklo :) Bohuzel taky moc neporadim, protoze to nastesti nepristalo na krku mne.....
-
Poradit neumím, ale můžu potvrdit, že podobné problémy jsem také zažil (v mém případě bylo na druhé straně FreeBSD).
1) tunely nejsou připravené na NAT, chtějí být (rozumně) stateless
Já používám IPsec mezi RouterOS a FreeBSD již dlouho a bez problémů.
IPsec má mechanismus "NAT traversal", který funguje spolehlivě. Takto rutinně používám cestovní router s LTE konektivitou, který se připojuje na čtyři jiné routery pomocí L2TP/IPsec tunelu.
Ale je pravda, že rozbitý CG-NAT to dokáže docela zkomplikovat.
-
Mám dvě veřejné IP ve dvou městech.
1. město
IP: 192.168.13.99 (veřejná IP: 172.217.23.195)
2. město
IP: 10.10.20.99 (veřejná IP: 172.217.23.206)
Opravdu máš veřejky z rozsahu Google nebo to je jenom takový ilustrační příklad? A proč do toho IPsecu pleteš ty privátní adresy, když tam máš veřejky?
Když jsem testoval všechny možné nastavení
Poradil byste někdo v čem by mohl být problém?
Možná by bylo lepší nezkoušet "všechna možná nastavení" a nastavit to tím správným způsobem.
Tobě ale bude těžké poradit, když jsi nám sem vůbec nenapsal, jak to máš nastavené a čeho vlastně chceš dosáhnout...
-
IPsec má mechanismus "NAT traversal", který funguje spolehlivě. Takto rutinně používám cestovní router s LTE konektivitou, který se připojuje na čtyři jiné routery pomocí L2TP/IPsec tunelu.
Ale je pravda, že rozbitý CG-NAT to dokáže docela zkomplikovat.
NAT-T se uplatňuje u L2TP VPN. Nutno rozlišovat tunel (stateless, dva pevné konce) od VPN (statefull, jeden konec pevný, druhý volný).
Tazatel se ale neptal na VPN L2TP, ale na tunel IPIP.
-
Mám dvě veřejné IP ve dvou městech.
1. město
IP: 192.168.13.99 (veřejná IP: 172.217.23.195)
2. město
IP: 10.10.20.99 (veřejná IP: 172.217.23.206)
Opravdu máš veřejky z rozsahu Google nebo to je jenom takový ilustrační příklad? A proč do toho IPsecu pleteš ty privátní adresy, když tam máš veřejky?
Když jsem testoval všechny možné nastavení
Poradil byste někdo v čem by mohl být problém?
Možná by bylo lepší nezkoušet "všechna možná nastavení" a nastavit to tím správným způsobem.
Tobě ale bude těžké poradit, když jsi nám sem vůbec nenapsal, jak to máš nastavené a čeho vlastně chceš dosáhnout...
Uvedené IP adresy jsou jen ilustrační. Jak jsem psal, nastavení mám nejspíše v pořádku, když jsou zařízení na stejné síti, tak se tunel naváže, problém nastává až v případě kdy jsou umístěna v jiných městech(přes veřejné IP).
Proč se ptáš na privátní IP... když např. v routeru nastavíš na ether1 co jde do WAN adresu 192.168.13.99 tak z internetu je vidět pod adresou 172.217.23.195 co přidělil ISP.
-
Přikládám část logu z IPFire:
10:22:55 charon: 05[NET] sending packet: from 192.168.13.99[500] to 172.217.23.206[500] (396 bytes)
10:22:56 charon: 09[NET] received packet: from 172.217.23.206[500] to 192.168.13.99[500] (388 bytes)
10:22:56 charon: 09[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
10:22:56 charon: 09[IKE] local host is behind NAT, sending keep alives
10:22:56 charon: 09[IKE] remote host is behind NAT
10:22:56 charon: 09[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
10:22:56 charon: 09[NET] sending packet: from 192.168.13.99[4500] to 172.217.23.206[4500] (108 bytes)
10:22:56 charon: 07[NET] received packet: from 172.217.23.206[4500] to 192.168.13.99[4500] (92 bytes)
10:22:56 charon: 07[ENC] parsed ID_PROT response 0 [ ID HASH ]
10:22:56 charon: 07[IKE] IDir '10.109.84.145' does not match to '172.217.23.206'
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
10:22:56 charon: 07[IKE] sending DELETE for IKE_SA tunel01[101]
10:22:56 charon: 07[ENC] generating INFORMATIONAL_V1 request 193930080 [ HASH D ]
10:22:56 charon: 07[NET] sending packet: from 192.168.13.99[4500] to 172.217.23.206[4500] (108 bytes)
10:23:53 charon: 05[NET] received packet: from 172.217.23.206[500] to 192.168.13.99[500] (348 bytes)
10:23:53 charon: 05[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V ]
10:23:53 charon: 05[IKE] received NAT-T (RFC 3947) vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
10:23:53 charon: 05[ENC] received unknown vendor ID: 16:f6:ca:16:e4:a4:06:6d:83:82:1a:0f:0a:ea:a8:62
10:23:53 charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
10:23:53 charon: 05[IKE] received Cisco Unity vendor ID
10:23:53 charon: 05[IKE] received DPD vendor ID
10:23:53 charon: 05[IKE] 172.217.23.206 is initiating a Main Mode IKE_SA
10:23:53 charon: 05[IKE] 172.217.23.206 is initiating a Main Mode IKE_SA
10:23:53 charon: 05[ENC] generating ID_PROT response 0 [ SA V V V V ]
10:23:53 charon: 05[NET] sending packet: from 192.168.13.99[500] to 172.217.23.206[500] (160 bytes)
10:23:54 charon: 09[NET] received packet: from 172.217.23.206[500] to 192.168.13.99[500] (388 bytes)
10:23:54 charon: 09[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
10:23:54 charon: 09[IKE] local host is behind NAT, sending keep alives
10:23:54 charon: 09[IKE] remote host is behind NAT
10:23:54 charon: 09[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
10:23:54 charon: 09[NET] sending packet: from 192.168.13.99[500] to 172.217.23.206[500] (396 bytes)
10:23:55 charon: 07[NET] received packet: from 172.217.23.206[4500] to 192.168.13.99[4500] (92 bytes)
10:23:55 charon: 07[ENC] parsed ID_PROT request 0 [ ID HASH ]
10:23:55 charon: 07[CFG] looking for pre-shared key peer configs matching 192.168.13.99...172.217.23.206[10.109.84.145]
10:23:55 charon: 07[IKE] no peer config found
10:23:55 charon: 07[ENC] generating INFORMATIONAL_V1 request 2963741542 [ HASH N(AUTH_FAILED) ]
10:23:55 charon: 07[NET] sending packet: from 192.168.13.99[4500] to 172.217.23.206[4500] (108 bytes)
-
Mám dvě veřejné IP ve dvou městech.
když např. v routeru nastavíš na ether1 co jde do WAN adresu 192.168.13.99 tak z internetu je vidět pod adresou 172.217.23.195 co přidělil ISP.
nemas, a to bude ten problem. takze nechat to nastavit niekomu, kto tomu rozumie...
-
Mám dvě veřejné IP ve dvou městech.
když např. v routeru nastavíš na ether1 co jde do WAN adresu 192.168.13.99 tak z internetu je vidět pod adresou 172.217.23.195 co přidělil ISP.
nemas, a to bude ten problem. takze nechat to nastavit niekomu, kto tomu rozumie...
Snad jsem výše uváděl, že když v obou městech umístím Mikrotik a nastavím to úplně stejně, tak s tunelem není žádný problém, vše funguje bez chyby.
-
Snad jsem výše uváděl, že když v obou městech umístím Mikrotik a nastavím to úplně stejně, tak s tunelem není žádný problém, vše funguje bez chyby.
Mikrotik není úplně to, čeho by se měl člověk chytat. Mikrotik má spoustu úprav, které jsou diskutabilní, ale zařadili je, aby je poloamatéři mohli využívat. Už jen to, že považujete za veřejnou adresu to, že máte NAT 1:1 mluví samo za sebe, a řadí Vás do určité úrovně uživatelů. To nemyslím jako urážku, prostě jste spotřebitel a ne síťař, na tom není nic špatného.
Zvážil jste namísto tunelu nějakou formu VPN?
-
Ale dle toho logu máš evidentně v cestě NAT:
10:23:54 charon: 09[IKE] remote host is behind NAT
10:23:55 charon: 07[CFG] looking for pre-shared key peer configs matching 192.168.13.99...172.217.23.206[10.109.84.145]
10:23:55 charon: 07[IKE] no peer config found
A pro to evidentně to nemáš nastaveno, protože takovou definici nenašel pro peera.
Takže pokud to odpovídá skutečnoti ak ne, nemáš veřejnou IP adresu, jsi schován za NATem (možná NAT 1:1, což je dnesk oblíbená metoda u růzmých pseudo ISP, jak dodat zákošovi veřejku, přeci s tím vše funguje).
-
Ano, mé zkušenosti a znalosti zatím nejsou nijak závratné, proto prosím o radu, jak nyní postupovat.
Skutečně jsem schován za NAT 1:1
-
IPsec má mechanismus "NAT traversal", který funguje spolehlivě. Takto rutinně používám cestovní router s LTE konektivitou, který se připojuje na čtyři jiné routery pomocí L2TP/IPsec tunelu.
Ale je pravda, že rozbitý CG-NAT to dokáže docela zkomplikovat.
NAT-T se uplatňuje u L2TP VPN. Nutno rozlišovat tunel (stateless, dva pevné konce) od VPN (statefull, jeden konec pevný, druhý volný).
Tazatel se ale neptal na VPN L2TP, ale na tunel IPIP.
NAT-T se uplatňuje vždy, je-li zapnuto, při vyjednávání PH1. Je celkem lhostejno, jestli pak pro PH2 existuje nějaké pravidlo pro L2TP nebo tam je jiné pravidlo pro úplně jiný protokol.
-
V logu je podezřelé:
10:22:56 charon: 07[IKE] IDir '10.109.84.145' does not match to '172.217.23.206'
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
...
10:23:55 charon: 07[CFG] looking for pre-shared key peer configs matching 192.168.13.99...172.217.23.206[10.109.84.145]
Co je za IP adresu ta 10.109.84.145? V zadání není uvedena. Vyskytuje se někde v konfiguraci? V nastavení IPSecu není a proto je příchozí požadavek odmítnut, očekává se identifikátor 172.217.23.206.
IDir je patrně identifikátor druhé strany tunelu. https://doc.pfsense.org/index.php/IPsec_Troubleshooting:
To correct this condition, change the Peer Identifier setting to IP Address and then enter the pre-NAT IP address, which in this example is 192.0.2.10.
S tímto parametrem nemám zkušenost, tunely jsem řešil bez NATu, aspoň jeden prvek měl vždy veřejnou IP adresu na sobě. Jednou jsem řešil něco s OpenSwan, můžete sem dát konfig?
-
Je tedy potřeba přidat nějaké pravidlo pro NAT nebo nějakou routu?
Uměl by někdo zkusit vysvětlit, proč ten Mikrotik funguje a IPFire ne?
-
V logu je podezřelé:
10:22:56 charon: 07[IKE] IDir '10.109.84.145' does not match to '172.217.23.206'
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
10:22:56 charon: 07[IKE] deleting IKE_SA tunel01[101] between 192.168.13.99[192.168.13.99]...172.217.23.206[%any]
...
10:23:55 charon: 07[CFG] looking for pre-shared key peer configs matching 192.168.13.99...172.217.23.206[10.109.84.145]
Co je za IP adresu ta 10.109.84.145? V zadání není uvedena. Vyskytuje se někde v konfiguraci? V nastavení IPSecu není a proto je příchozí požadavek odmítnut, očekává se identifikátor 172.217.23.206.
IDir je patrně identifikátor druhé strany tunelu. https://doc.pfsense.org/index.php/IPsec_Troubleshooting:
To correct this condition, change the Peer Identifier setting to IP Address and then enter the pre-NAT IP address, which in this example is 192.0.2.10.
S tímto parametrem nemám zkušenost, tunely jsem řešil bez NATu, aspoň jeden prvek měl vždy veřejnou IP adresu na sobě. Jednou jsem řešil něco s OpenSwan, můžete sem dát konfig?
Adresa 10.109.84.145 je podle zadání 10.10.20.99, přehlédl jsem jí, ostatní adresy vkládám tak, že je měním pomocí fce najít a nahradit.
-
Obecný problém té konfigurace je v tom, že pakety, co odesíláš, tak používáš v definici IPsec peera a SPD protistrany veřejné IP protistrany a co prijimáš, po vybalení z NAT-T, tak mají vnitřní IPčka protistrany, takže ti je nenajde v definici peera/spd, pokud je to definováno s těma veřejkama a na to ti to řve.
Můžeš zkusit, že nebudeš IPSec nastavovat mezi těma veřejkama 172.217.23.195..172.217.23.206, ale nastaviš jako oba konce ty neveřejky, co máš na WAN portech 192.168.13.99..10.10.20.99. A k tomu doplníš, routu, že ta vnitřní IP protistrany se routuje na adresu tvé aktuální brány a zároveň, že pro tu vnitřní IP adresy protistrany provdedeš DSTNAT na odchozí provoz stylem 10.10.20.99->172.217.23.206 na její veřejku. A na druhé straně to stejné pro ty IPčka 192.168.13.99->172.217.23.195 (routu a dst nat).
Jiná možnost jak to ojebat (pokud to ten IPFire dovolí), tak je eliminovat to NAT-T a dosáhnout pocitu, že mám veřejky přímo na routeru. Pokud máš NAT 1:1 na obou stranách, tak si udělám virtuální loopback interface na routeru, tomu dám tu skutečnou veřejku/32 a provádím SRC/DSTNAT pro tu veřejku z loopbacku na neveřejku na daném wan portu a pak nastavuji IPsec s koncy těch veřejek a nedojde k aplikaci NAT-T.
-
S tímto parametrem nemám zkušenost, tunely jsem řešil bez NATu, aspoň jeden prvek měl vždy veřejnou IP adresu na sobě. Jednou jsem řešil něco s OpenSwan, můžete sem dát konfig?
Chtěl bych více pochopit to, jak je to s tou veřejnou IP adresou, když použiji ty co mi ISP přidělil v Mikrotiku, tak se tunel naváže v pořádku a když to zkouším s IPFire, tak to nefunguje.
Jaký zásadní rozdíl je mezi normální veřejnou IP a veřejnou IP pomocí NAT 1:1 od poskytovatele? To by nás mohlo přivést k vyřešení tohoto problému.
IPFire mám nastavený správně(parametry), když tunel vytvořím IPFire+Mikrotik na stejné lokální síti, tak se naváže hned bez chyb. Neporadí si jen s překladem těch veřejných adres které jsou od ISP pravděpodobně NAT 1:1.
-
IPsec vkládá dovnitř komunikace svoji IP, při navazování spojení pomocí IKE protokolu. Takže odejde paket, který uvnitř má napsáno, že moje IP je X, dojde protistraně ta vidí, že paket přišel se zdrojovou adresou Y, která se liší od toho, co je uvnitř paketu.
Pokud není NAT u protistrany použit, tak ti dojde IKE paket, kde je zdrojová adresa stejná s tou, co je uvedeno uvnitř protokolu (třeba obě budou 172.217.23.206) a tvým partnerem pro IPsec komunkci je stroj s IP 172.217.23.206.
Ale pokud je u protistrany NAT, tak ti dojde paket, kde je zdrojová IP aresa na paketu je třeba 172.217.23.206, ale uvnitř protokolu to tvrdí, že tvým partnerem je 10.10.20.99. A IPsec se konfiguruje a logicky sestavuje proti té vnitřní adrese 10.10.20.99.
Pokud je takto pojebána NATem jen jedna strana, je to OK, pokud obě, tak se to kapánek komplikuje.
-
A k tomu doplníš, routu, že ta vnitřní IP protistrany se routuje na adresu tvé aktuální brány a zároveň, že pro tu vnitřní IP adresy protistrany provdedeš DSTNAT na odchozí provoz stylem 10.10.20.99->172.217.23.206 na její veřejku
Začíná to vypadat, že se blížíme ke zdárnému konci s úspěšným řešením. S routami zatím moc nepracuji ale chtěl bych se to pořádně naučit, koupím nějaké knížky a budu číst co se dá.
V tuhle chvíli, poradil by si prosím přesněji jak budou vypadat příkazy pro routu na tu aktuální bránu a zároveň routu pro tu vnitřní IP protistrany jak si psal výše?
-
Prvně bych zkusil nastavit na té IPfire straně správně identifikátor té protistrany v definici IPsecu. Posílal to už kolega výše. To by ten dopad NATu protistrany také měl řešit:
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Mismatched_Identifier_with_NAT
-
Prvně bych zkusil nastavit na té IPfire straně správně identifikátor té protistrany v definici IPsecu. Posílal to už kolega výše. To by ten dopad NATu protistrany také měl řešit:
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Mismatched_Identifier_with_NAT
Nejsem si jistý, zdali přesně rozumím tomuto:
To correct this condition, change the Peer Identifier setting to IP Address and then enter the pre-NAT IP address, which in this example is 192.0.2.10.
Když na straně IPFire nastavím pro peers (Remote host/IP: 10.10.20.99) namísto 172.217.23.206 tak se stane následující, z konzole IPFire vyčteno:
sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
received packet: from 172.217.23.206[500] to 192.168.13.99[500] (348 bytes)
a jak bych tušil, nefunguje to.
Přikládám kus logu:
09:24:20 charon: 15[CFG] added configuration 'test001'
09:24:20 charon: 04[CFG] received stroke: initiate 'test001'
09:24:20 charon: 04[IKE] initiating Main Mode IKE_SA test001[172] to 10.10.20.99
09:24:20 charon: 04[IKE] initiating Main Mode IKE_SA test001[172] to 10.10.20.99
09:24:20 charon: 04[ENC] generating ID_PROT request 0 [ SA V V V V V V ]
09:24:20 charon: 04[NET] sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
09:24:20 charon: 03[NET] error writing to socket: Operation not permitted
09:24:20 charon: 05[CFG] received stroke: initiate 'test001'
09:24:24 charon: 07[IKE] sending retransmit 1 of request message ID 0, seq 1
09:24:24 charon: 07[NET] sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
09:24:24 charon: 03[NET] error writing to socket: Operation not permitted
09:24:31 charon: 12[IKE] sending retransmit 2 of request message ID 0, seq 1
09:24:31 charon: 12[NET] sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
09:24:31 charon: 03[NET] error writing to socket: Operation not permitted
09:24:33 charon: 15[NET] received packet: from 172.217.23.206[500] to 192.168.13.99[500] (348 bytes)
09:24:33 charon: 15[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V ]
09:24:33 charon: 15[IKE] no IKE config found for 192.168.13.99...172.217.23.206, sending NO_PROPOSAL_CHOSEN
09:24:33 charon: 15[ENC] generating INFORMATIONAL_V1 request 2902255063 [ N(NO_PROP) ]
09:24:33 charon: 15[NET] sending packet: from 192.168.13.99[500] to 172.217.23.206[500] (40 bytes)
09:24:43 charon: 04[NET] received packet: from 172.217.23.206[500] to 192.168.13.99[500] (348 bytes)
09:24:43 charon: 04[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V ]
09:24:43 charon: 04[IKE] no IKE config found for 192.168.13.99...172.217.23.206, sending NO_PROPOSAL_CHOSEN
09:24:43 charon: 04[ENC] generating INFORMATIONAL_V1 request 1951789508 [ N(NO_PROP) ]
09:24:43 charon: 04[NET] sending packet: from 192.168.13.99[500] to 172.217.23.206[500] (40 bytes)
09:24:44 charon: 09[IKE] sending retransmit 3 of request message ID 0, seq 1
09:24:44 charon: 09[NET] sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
09:24:44 charon: 03[NET] error writing to socket: Operation not permitted
Co kdybychom to zkusili přes ty routy a DSTNAT, poradili byste jak budou přesněji vypadat příkazy pro tu routu a pro dstnat?
-
Prvně bych zkusil nastavit na té IPfire straně správně identifikátor té protistrany v definici IPsecu. Posílal to už kolega výše. To by ten dopad NATu protistrany také měl řešit:
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Mismatched_Identifier_with_NAT
Nejsem si jistý, zdali přesně rozumím tomuto:
To correct this condition, change the Peer Identifier setting to IP Address and then enter the pre-NAT IP address, which in this example is 192.0.2.10.
Když na straně IPFire nastavím pro peers (Remote host/IP: 10.10.20.99) namísto 172.217.23.206 tak se stane následující, z konzole IPFire vyčteno:
sending packet: from 192.168.13.99[500] to 10.10.20.99[500] (200 bytes)
received packet: from 172.217.23.206[500] to 192.168.13.99[500] (348 bytes)
a jak bych tušil, nefunguje to.
Ach jo, ten popis je snad jasný. Remote host samozřejmě zůstavá ta veřejka 172.217.23.206, ale je tam někde i volba "Peer Identifier" a tu je třeba dát na tu 10.10.20.99.
-
Tak všem moc děkuji za pomoc, problém vyřešen, již to funguje.
Opravdu stačilo správně nastavit identifikátor protistrany, konkrétně v IPFire to je"Remote ID:" v pfsense to je "Peer Identifier".
-
Ještě prosím o jednu úvahu, připojuji se k síti, která je rozsáhlá, 10.109.84.0/24, 10.109.255.0/24.
Jak vytvořím spojení na všechny, je to nějak možné?
Zatím to mám nastaveno jen pro
Remote subnet: 10.109.84.0/24
...jak to nastavit abych byl ve všech sítích 10.109.*.0 ?
-
Zatím to mám nastaveno jen pro
Remote subnet: 10.109.84.0/24
...jak to nastavit abych byl ve všech sítích 10.109.*.0 ?
Remote subnet: 10.109.0.0/16
Za předpokladu, že lokální segment není v tom /16 zahrnut (či-li lokální LAN nepoužívá třeba 10.109.66.0/24).