Dotaz: IPsec - 2 lokalne rozsahy a jeden vzdialeny

[GeorgeWH]

Zdravim.

Mam IPsec tunel S2S medzi lokalnym serverom (lokalna LAN siet 10.10.10.0/24 a lokalna (Open)VPN siet 10.81.0.0/16) a vzdialenym MikroTik-om, ktory je za NAT-om (vzdialena MKT siet 192.168.101.0/24). MKT inicializuje spojenie. Tunel sa naviaze a vsetko vyzera OK.

Problem je, ze spojenie funguje vzdy len z jednej lokalnej siete (bud LAN alebo VPN):

10.10.10.0/24 <-> 192.168.101.0/24 - OK

10.81.0.0/16 <-> 192.168.101.0/24 - nefunguje

alebo naopak. To, ktora siet bude fungovat som zatial este neodsledoval, ale mam pocit, ze je to nahodne (po restarte strongswan na lokalnom serveri).

Ked z lokalnej siete, ktora nefunguje, pingam vzdialene PC, tak na MKT vidim, ze vzdialene PC odpoveda na ping, ale neprejde to uz bud do tunela, alebo to z neho nevyjde na lokalnom serveri (je tam trafik, takze je problem odsledovat ESP pakety).

Sprava sa to rovnako pri IKEv1 aj IKEv2.

Lokalny server: CentOS 7, strongswan-5.7.1-1.el7, verejna IP

ipsec.conf

config setup

conn base
    fragmentation=yes
    dpdaction=restart
    dpddelay=120s

conn lan1
    also=base
    keyexchange=ikev2
    mobike=no
    left=1.1.1.1
    leftsubnet=10.10.10.0/24
    right=%any
    rightsubnet=192.168.101.0/24
    authby=psk
    ike=aes128-sha1-modp1536
    esp=aes128-sha1-modp1536
    ikelifetime=1d
    lifetime=1h
    margintime=9m
    keyingtries=%forever
    rekey=no
#    auto=start
    auto=route

conn lan2
    also=base
    keyexchange=ikev2
    mobike=no
    left=1.1.1.1
    leftsubnet=10.81.0.0/16
    right=%any
    rightsubnet=192.168.101.0/24
    authby=psk
    ike=aes128-sha1-modp1536
    esp=aes128-sha1-modp1536
    ikelifetime=1d
    lifetime=1h
    margintime=9m
    keyingtries=%forever
    rekey=no
    auto=route

strongswan statusall

Connections:
lan1:  1.1.1.1...%any  IKEv2, dpddelay=120s
lan1:   local:  [1.1.1.1] uses pre-shared key authentication
lan1:   remote: uses pre-shared key authentication
lan1:   child:  10.10.10.0/24 === 192.168.101.0/24 TUNNEL, dpdaction=restart
lan2:   child:  10.81.0.0/16 === 192.168.101.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
lan1[1]: ESTABLISHED 10 seconds ago, 1.1.1.1[1.1.1.1]...2.2.2.2[192.168.1.102]
lan1[1]: IKEv2 SPIs: a0bb837a343ba52b_i cade29f30cf3c13a_r*, rekeying disabled
lan1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
lan1{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf51c3da_i 0697cfc9_o
lan1{1}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 524 bytes_o (7 pkts, 0s ago), rekeying disabled
lan1{1}:   10.10.10.0/24 === 192.168.101.0/24
lan2{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cc888691_i 0698f9ae_o
lan2{2}:  AES_CBC_128/HMAC_SHA1_96/MODP_1536, 3114 bytes_i (27 pkts, 0s ago), 1128 bytes_o (16 pkts, 0s ago), rekeying disabled
lan2{2}:   10.81.0.0/16 === 192.168.101.0/24

MKT - RouterOS v6.43.7, WAN rozhranie ma privatnu IP (DHCP) 192.168.1.102

Vdaka za akukolvek radu.

---

---

Odpovědi

[NN]

Nechybi na MKT routa pro 10.81.0.0/16 smerujici do IPSec tunelu?

[GeorgeWH]

To riesi TS, nie? Ani pre lokalnu LAN som nepridaval routovanie a funguje to. Proste po restarte strongswan-u stale funguje iba jedna siet (mozno podla toho, do ktorej ide nejaky trafik ako prvy; nezalezi ani na poradi v konfiguracii).

Ale to som nekontroloval, ci to fakt nahodou neposiela cez GW mimo tunela. Vdaka.

[NN]

Moment, mozna jsem to spatne pochopil. Vypada to takto?

       Server         ipsec1
   10.10.10.0/24 | ..............        MKT
                 |                | 192.168.101.0/24
192.168.101.0/24 | ..............
                      ipsec2

Tzn. z jednoho boxu mas dva tunely naraz?

[GeorgeWH]

Ano, jedna strana (nazvime ju lokalna) ma 2 rozsahy (ethernet 10.10.10.0/24 a openvpn 10.81.0.0/16 - tam mas chybu) a druha strana (vzdialena) ma jeden ethernet rozsah 192.168.101.0/24. A po nabehnuti ipsec funguje (prejde trafik) cez tunel vzdy iba z jedneho lokalneho rozsahu - bud 10.10.10.0/24 <-> 192.168.101.0/24 alebo 10.81.0.0/16 <->192.168.101.0/24 - proste nefunguju oba lokalne rozsahy naraz.

    Server   ipsec1
10.10.10.0/24 |.............        MKT
              |             | 192.168.101.0/24
 10.81.0.0/16 |.............
                  ipsec2

[bigBRAMBOR]

Jezisi to se mi taky delo a taky strongswan vs mikroTik, snad si vzpomenu co jsem s tim delal

Pokud ma sna jedne strane dve sire, urcite pouzij ikev2 to ti umozni pouzit multisite na jedne strane, jde to tam lepe nastavit.

[GeorgeWH]

Multisite myslis nekonfigurovat 2x conn, ale v jednej conn pridat oba subnety leftsubnet=10.10.10.0/24,10.81.0.0/16? Lebo to som skusal, ale tiez to nefungovalo.

Ale keby si si spomenul, ako si to fixol, by bolo super :).

[GeorgeWH]

Tak podla vsetkeho vyriesene - MKT zdiela pre rozne subnety jednu SA, co sice medzi dvoma MKT funguje (a zrejme porusuje IPsec standard), ale strognswan-u sa to nepaci. Po nastaveni level=unique v jednotlivych policy sa to rozbehlo.

BTW tento "bug" je v MKT uz 10 rokov, neviem preco nezmenili default konfiguraciu.

Velka vdaka vsetkym za nakopnutie.

[Michal Kubeček]

Tak to je síla. Jakkoli by možnost použít víckrát stejnou SA mohla být za určitých okolností praktická (a za mnohých jiných zásadní bezpečnostní problém), dohodnout si s protistranou nějakou SA a pak použít úplně jinou, která navíc ani neodpovídá paketům, na které se aplikuje, to je bug zcela určitě.

[GeorgeWH]

Tak MKT sa sprava presne podla dokumentacie:

Specifies what to do if some of the SAs for this policy cannot be found:

- use - skip this transform, do not drop packet and do not acquire SA from IKE daemon

- require - drop packet and acquire SA (default)

- unique - drop packet and acquire a unique SA that is only used with this particular policy. It is used in setups where multiple clients can sit behind one public IP address (clients behind NAT).

Ale to dohodnutie roznych SA a pritom pouzit iba jednu asi uz bude bug (v pripade level=require).

[GeorgeWH]

Co je este ale divne, je ze

shell# ip r g 192.168.101.10
192.168.101.12 via [ip.adresa.default.gw]] dev wan0  src 10.10.10.1 
    cache

vracia src 10.10.10.1 - podla mna by tam mala byt verejna IP servera (v nasom priklade 1.1.1.1) a nie jeho lokalna (aspon tak som to pochopil, ze by to malo fungovat a v inych pripadoch ipsec to aj tak mam).

[NN]

Asi bych klasicky vysledoval ICMP od problematickeho zdroje k cili a spatky. Se spravnym tcpdump filtrem by to nemel byt problem, je to cele routovane. Mel by jsi videt paket odejit, vylezt z tunelu a stejnou cestu zpet. Na strane serveru nevidim problem..

[Michal Kubeček]

To je vždycky dobrý začátek: snažit se lokalizovat, kde přesně se pakety ztrácejí, pak už je většinou mnohem jednoduché poznat proč.

Další věci, na které by bylo dobré se podívat:

  ip route show
  ip xfrm policy show
  ip xfrm state show

Případně jestli není problém v konfiguraci netfiltru - zejména překlady adres často způsobují problémy (hlavně příliš obecná pravidla pro maškarádu).

[Michal Kubeček]

(A samozřejmě problém může být na kterékoli straně - na to se taky často zapomíná.)

[GeorgeWH]

shell# ip xfrm policy show                                                                                          
src 10.10.10.0/24 dst 192.168.101.0/24 
        dir out priority 375423 ptype main 
        tmpl src 1.1.1.1 dst 2.2.2.2
                proto esp spi 0x04ee0fc1 reqid 2 mode tunnel
src 192.168.101.0/24 dst 10.10.10.0/24 
        dir fwd priority 375423 ptype main 
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 2 mode tunnel
src 192.168.101.0/24 dst 10.10.10.0/24     
        dir in priority 375423 ptype main  
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 2 mode tunnel
src 10.81.0.0/16 dst 192.168.101.0/24 
        dir out priority 379519 ptype main 
        tmpl src 1.1.1.1 dst 2.2.2.2
                proto esp spi 0x0f850dc5 reqid 1 mode tunnel
src 192.168.101.0/24 dst 10.81.0.0/16      
        dir fwd priority 379519 ptype main 
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 1 mode tunnel
src 192.168.101.0/24 dst 10.81.0.0/16      
        dir in priority 379519 ptype main  
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main

Problem bude asi v tom, ze sa pouzije nespravna SA (bud server alebo MKT):

shell# tcpdump -vvnn -i wan0 'host 2.2.2.2 and port ! (1194 or 1201)'
tcpdump: listening on wan0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:55:45.764133 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 608)
    1.1.1.1.4500 > 2.2.2.2.4500: [no cksum] UDP-encap: ESP(spi=0x04ee0fc1,seq=0x7), length 580
22:55:45.768938 IP (tos 0x0, ttl 56, id 42957, offset 0, flags [none], proto UDP (17), length 608)
    2.2.2.2.4500 > 1.1.1.1.4500: [no cksum] UDP-encap: ESP(spi=0xcd609f7f,seq=0x10), length 580
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

shell# strongswan statusall | grep '04ee0fc1\|cd609f7f'
lan{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_o


shell# tcpdump -vvnn -i wan0 'host 2.2.2.2 and port ! (1194 or 1201)'
tcpdump: listening on wan0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:55:57.016446 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1024)
    1.1.1.1.4500 > 2.2.2.2.4500: [no cksum] UDP-encap: ESP(spi=0x0f850dc5,seq=0x3), length 996
22:55:57.022014 IP (tos 0x0, ttl 56, id 42958, offset 0, flags [none], proto UDP (17), length 1024)
    2.2.2.2.4500 > 1.1.1.1.4500: [no cksum] UDP-encap: ESP(spi=0xcd609f7f,seq=0x13), length 996
^C
3 packets captured
4 packets received by filter
0 packets dropped by kernel


shell# strongswan statusall | grep '0f850dc5\|cd609f7f'
vpn{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0be4177_i 0f850dc5_o
lan{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_o

Prvy ping a grep, ktory funguje, je z LAN (10.10.10.0/24) a "pouzije" sa rovnaka SA.

Druhy ping, nefunkcny, je z VPN (10.81.0.0/16) a pouziju sa obe SA.

shell# strongswan statusall
...
Connections:
lan:  1.1.1.1...%any  IKEv2, dpddelay=120s
lan:   local:  [1.1.1.1] uses pre-shared key authentication
lan:   remote: uses pre-shared key authentication
lan:   child:  10.10.10.0/24 === 192.168.101.0/24 TUNNEL, dpdaction=restart
vpn:   child:  10.81.0.0/16 === 192.168.101.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
lan[1]: ESTABLISHED 21 minutes ago, 1.1.1.1[1.1.1.1]...2.2.2.2[192.168.1.102]
lan[1]: IKEv2 SPIs: 059f7792a6358633_i fdbfb613553f93e8_r*, pre-shared key reauthentication in 23 hours
lan[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
vpn{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0be4177_i 0f850dc5_o
vpn{1}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i (0 pkts, 107s ago), 2856 bytes_o (3 pkts, 1212s ago), rekeying in 2 seconds
vpn{1}:   10.81.0.0/16 === 192.168.101.0/24
lan{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_o
lan{2}:  AES_CBC_128/HMAC_SHA1_96/MODP_1536, 30444 bytes_i (305 pkts, 0s ago), 8100 bytes_o (70 pkts, 0s ago), rekeying in 58 seconds
lan{2}:   10.10.10.0/24 === 192.168.101.0/24

ipsec.conf

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn base
    fragmentation=yes
    dpdaction=restart
    dpddelay=120s


conn lan
    also=base
    keyexchange=ikev2
    mobike=no
    left=1.1.1.1
    leftsubnet=10.10.10.0/24
    right=%any
    rightsubnet=192.168.101.0/24
    authby=psk
    ike=aes128-sha1-modp1536
    esp=aes128-sha1-modp1536
    ikelifetime=1d
    lifetime=30m
    margintime=5m
    keyingtries=%forever
    auto=route

conn vpn
    also=base
    keyexchange=ikev2
    mobike=no
    left=1.1.1.1
    leftsubnet=10.81.0.0/16
    right=%any
    rightsubnet=192.168.101.0/24
    authby=psk
    ike=aes128-sha1-modp1536
    esp=aes128-sha1-modp1536
    ikelifetime=1d
    lifetime=30m
    margintime=5m
    keyingtries=%forever
    auto=route

1.1.1.1 - verejna IP servera

2.2.2.2 - verejna IP MKT (skryty za S-NAT)

[Michal Kubeček]

Jestli dobře vidím, tak problém nastává až u odpovědi, takže chyba by měla být na tom mikrotiku, ne na serveru, na který jste se zatím soustředil.

[GeorgeWH]

Ano, vyzera to tak. MKT to vracia zlym tunelom. Otazka je preco, resp. je fakt chyba na strane MKT?

[Michal Kubeček]

Teoreticky je sice možné, že je chyba na straně serveru (např. kdyby ho při IKE výměně nějak uvedl v omyl), ale varianta, že je problém na straně mikrotiku (ať už konfigurace nebo bug), mi připadá podstatně pravděpodobnější.

[Michal Kubeček]

Kdyby to bylo tak, jak si to představujete, nemohlo by to fungovat, protože jakákoli odpověď by nešla tím tunelem. A vlastně už ani ten původní paket, protože by zdrojová adresa neodpovídala politice.

[Michal Kubeček]

neprejde to uz bud do tunela, alebo to z neho nevyjde na lokalnom serveri (je tam trafik, takze je problem odsledovat ESP pakety)

Tak si vyfiltrujte jen ESP pakety s konkrétním SPI.