IPFire + Mikrotik –> IPsec tunel

[LukasD]

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.

[Reklama]

[Miroslav Šilhavý]

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).

[David1234]

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í?

[Cek]

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.....

[daemon]

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.

[Reklama]

[daemon]

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...

[Miroslav Šilhavý]

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.

[LukasD]

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.

[LukasD]

Přikládám část logu z IPFire:

Kód: [Vybrat]

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)

[samalama]

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...

[LukasD]

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.

[Miroslav Šilhavý]

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?

[M.]

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).

[LukasD]

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

[daemon]

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.