Dotaz: IPSec StrongSwan CISCO

[donjirka]

Ahoj, prosím o pomoc s IPSec pomocí StrongSwan.

Zatím se mi z dokumentace nepodařilo pochopit, jak ten StrongSwan vlastně funguje. Podařilo se mi zprovoznit podle návodů na netu IPSec mezi CISCO ASA a StrongSwan (pomocí PSK klíče), ale myslel jsem, že se mi vytvoří nějaký virtuální adaptér a budu tak moct přes routing nějak nasměrovat packety (Podobně jako u WireGuard). Po vytvoření tunelu se ale v systému nic takového neobjeví a já nechápu, jak mám serveru říci, že má například adresu 10.110.6.128/25 spojit přes NAT na 192.168.15.0/24 a obráceně. příkaz ipsec statusall vypisuje toto:

root@ipsec:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.0-89-generic, x86_64):
  uptime: 14 minutes, since Dec 05 16:19:01 2023
  malloc: sbrk 2162688, mmap 0, used 1412912, free 749776
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  192.168.15.22
Connections:
cisco_asa:  192.168.15.22...xx.xx.xx.xx  IKEv2, dpddelay=30s
cisco_asa:   local:  [192.168.15.22] uses pre-shared key authentication
cisco_asa:   remote: [xx.xx.xx.xx] uses pre-shared key authentication
cisco_asa:   child:  10.110.6.128/25 === 10.100.7.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
cisco_asa_spp[1]: ESTABLISHED 14 minutes ago, 192.168.15.22[192.168.15.22]...xx.xx.xx.xx[xx.xx.xx.xx]
cisco_asa_spp[1]: IKEv2 SPIs: 2fe2f55bdc316605_i* d4acb220cb97c7f5_r, pre-shared key reauthentication in 23 hours
cisco_asa_spp[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384
cisco_asa_spp{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cd7c311e_i c9e1ebd7_o
cisco_asa_spp{1}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 40 minutes
cisco_asa_spp{1}:   10.110.6.128/25 === 10.100.7.0/24

výpis sítě:

root@ipsec:~# ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fe:ba:67:72:7b:12 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.15.22/24 brd 192.168.15.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::acbf:67ff:fe72:7b12/64 scope link
       valid_lft forever preferred_lft forever

Našel jsem, že by stím mohlo mít něco společného v iptables policy

   policy
       This module matches the policy used by IPsec for handling a
       packet.

       --dir {in|out}
              Used to select whether to match the policy used for
              decapsulation or the policy that will be used for
              encapsulation.  in is valid in the PREROUTING, INPUT and
              FORWARD chains, out is valid in the POSTROUTING, OUTPUT
              and FORWARD chains.

       --pol {none|ipsec}
              Matches if the packet is subject to IPsec processing.
              --pol none cannot be combined with --strict.

       --strict
              Selects whether to match the exact policy or match if any
              rule of the policy matches the given policy.

       For each policy element that is to be described, one can use one
       or more of the following options. When --strict is in effect, at
       least one must be used per element.

       [!] --reqid id
              Matches the reqid of the policy rule. The reqid can be
              specified with setkey(8) using unique:id as level.

       [!] --spi spi
              Matches the SPI of the SA.

       [!] --proto {ah|esp|ipcomp}
              Matches the encapsulation protocol.

       [!] --mode {tunnel|transport}
              Matches the encapsulation mode.

       [!] --tunnel-src addr[/mask]
              Matches the source end-point address of a tunnel mode SA.
              Only valid with --mode tunnel.

       [!] --tunnel-dst addr[/mask]
              Matches the destination end-point address of a tunnel mode
              SA.  Only valid with --mode tunnel.

       --next Start the next element in the policy specification. Can
              only be used with --strict.

Může mě prosím někdo posunout?

Odpovědi

[X]

ip xfrm policy list
ip xfrm state list
ip route list table 220

[Max]

Standardně se u všech možných věcí apod. nevytváří sólo interface, ale je tunel zavěšený na wance. Prostě na tom interface, přes který se navazuje ipsec.
Nicméně, StrongSWAN od nějaké verze podporuje vytvoření virtuálního xfrm interface. Lze mu tedy říci, aby vytvořil interface pro konkrétní tunel a ty pak můžeš směrovat a dělat pravidla per interface.
V rámci StrongSWAN nemám rozjetý Site2Site tunel, ale jen BYOD pro mobilní zařízení. Example ti tedy v rychlosti nedám, ale řeknu ti, že takto ten interface vytvoříš + nastavíš příslušné routy:

nano /etc/rc.local
ip link add ipsec0-pobocka1 type xfrm dev ens224 if_id 10
ip link set dev ipsec0-pobocka1 up
ip route add 192.168.1.0/24 dev ipsec0-pobocka1
ip route add 192.168.2.0/24 dev ipsec0-pobocka1
ip route add 192.168.3.0/24 dev ipsec0-pobocka1

Ten "if_id 10" je identifikátor iface, který rozpozná i Strongswan. Tzn., že pak ve Strongswanu říkáš, přes který iface se má routovat ipsec provoz konkrétního tunelu:

nano /etc/swanctl/conf.d/pobocky-ikev2.conf
...
if_id_in = 10
if_id_out = 10
...

Snad je to takto dostatečné.
Zdar Max

[donjirka]

Moc děkuji, jdu studovat

[donjirka]

Ahoj, můžete mi ještě vysvětlit následující? Bohužel tak nějak stále vůbec nevím. Nechápu co má vlastně společného strongswan a /etc/ipsec.conf. (V dokumentaci se píše o konfiguraci v /etc/ipsec.conf a někde se provádí v /etc/strongswan.conf s úplně jinou syntaxí) K čemu je vlastně charon. Jak nasměrovat provoz na 10.100.7.100/24. (Když dám tracert na 10.100.7.100 hází mi to provoz na bránu a ta jej zahazuje)

Dle konfigurace se mi vytvoří interface ip_vti0@NONE který je ve stavu DOWN, který nejde upravit ani smazat. Nikde v dokumentaci jsem nenašel jak se konfiguruje.

Stav tedy je, že se mi tunel sestavil, ale nic mi neprochází protože vůbec nechápu jak letí packety přes ens18 a dále ip_vti0 (což nechápu proč se jmenuje takto, ale dělá to automaticky).

ip link add ip_vti0 type xfrm dev ens18 if_id 42
RTNETLINK answers: File exists

ip tunnel add ip_vti0 local 192.168.15.22 remote 10.100.7.100 mode vti key 42

3: ip_vti0@NONE: NOARP mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0

root@ipsec:~# cat /etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file

config setup
        charondebug=all
        uniqueids=yes
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default
        ikelifetime=1440m
        keylife=60m
        rekeymargin=3m
        authby=secret

conn cisco_asa_spp
        left=192.168.15.22
        leftsubnet=10.110.6.128/25
        leftid=192.168.15.22
        leftauth=psk
        leftfirewall=yes
        right=xx.xx.xx.x
        rightsubnet=10.100.7.0/24
        rightid=xx.xx.xx.x
        rightauth=psk
        auto=start
        esp=aes256-sha256-ecp384!
        ike=aes256-sha256-ecp384!
        keyexchange=ikev2
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart
        keyingtries=%forever
        close|dpdaction=restart
        type=tunnel
        mark=42

root@ipsec:~# ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ae:bf:67:72:7b:12 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.15.22/24 brd 192.168.15.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::acbf:67ff:fe72:7b12/64 scope link
       valid_lft forever preferred_lft forever
3: ip_vti0@NONE: NOARP mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0

root@ipsec:~# ip link set ip_vti0 up
root@ipsec:~# ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ae:bf:67:72:7b:12 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.15.22/24 brd 192.168.15.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::acbf:67ff:fe72:7b12/64 scope link
       valid_lft forever preferred_lft forever
3: ip_vti0@NONE: NOARP,UP,LOWER_UP mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0

[Max]

Charon je služba, která se stará o ipsec (součástí strongswanu). Implementuje v sobě ikev1 a ikev2. Dříve to bylo trochu roztříštěno a existovalo něco jako Pluto pro ikev1 a další implemetace. Oni to časem přepsali a s verzí Strongswan 5.0 vyšel monolistický daemon Charon a Pluto se vyhodilo (Bye Bye Pluto!).

Ve starších verzích se dělala konfigurace v "/etc/ipsec.conf" a strongswan se ovládal příkazy "ipsec něco". Od nějaké verze (teď si to nepamatuji přesně) se přešlo na "/etc/swanctl.conf", resp. "/etc/swanctl/conf.d/" a jako cli se používá "swanctl něco".
Jedná se tedy o přepsání cli a dalších věcí a na to se váže novější styl a názvy konfiguračních souborů.

Virtuální iface xfrm je podporovaný od kernelu 4.19, Strongswanu 5.8.0 a iproute2 5.1.0+, ale tobě to hlásí, že interface už existuje "RTNETLINK answers: File exists". Snažíš se tedy vytvořit, něco, co už je vytvořeno? Když přidáš "ip_vti0" vázaný na iface "ens18", tak by se ti měl vytvořit interface "ip_vti0@ens18" a né "ip_vti0@NONE".

Jinak ty se ještě snažíš o používání VTI interface, což je ale lehce horší ekvivalent pro XFRM, viz: VTI Devices on Linux.
Zdar Max

[donjirka]

Tedy smekám kloubouček před znalostmi. Jdu se do toho zase ponořit a díky moc.

[donjirka]

Děkuji za posun, nyní mám už adaptér ip_xfrm a opravdu se tam provoz směruje, nyní mi vrací 192.168.15.22 nedostupné. Zase nevím co dál

root@ipsec:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.0-91-generic, x86_64):
  uptime: 3 seconds, since Dec 21 12:42:07 2023
  malloc: sbrk 2138112, mmap 0, used 1254176, free 883936
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6
  loaded plugins: charon aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  192.168.15.22
Connections:
cisco_asa_spp:  192.168.15.22...xxx.xx.xx.x IKEv2, dpddelay=30s
cisco_asa_spp:   local:  [192.168.15.22] uses pre-shared key authentication
cisco_asa_spp:   remote: [xxx.xx.xx.x] uses pre-shared key authentication
cisco_asa_spp:   child:  192.168.15.0/24 === 10.100.7.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
cisco_asa_spp[1]: ESTABLISHED 2 seconds ago, 192.168.15.22[192.168.15.22]...xxx.xx.xx.x[xxx.xx.xx.x]
cisco_asa_spp[1]: IKEv2 SPIs: 9d1360962da496ee_i* b785f60b7c2c1101_r, pre-shared key reauthentication in 23 hours
cisco_asa_spp[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384

ip link add ip_xfrm type xfrm dev ens18 if_id 42
ip link set ip_xfrm up
ip route add 10.100.7.0/24 dev ip_xfrm

root@ipsec:~# ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ae:bf:67:72:7b:12 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.15.22/24 brd 192.168.15.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::acbf:67ff:fe72:7b12/64 scope link
       valid_lft forever preferred_lft forever
3: ip_xfrm@ens18: NOARP,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet6 fe80::8f49:cec4:e408:5047/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

root@ipsec:~# ip route list
default via 192.168.15.1 dev ens18 proto static
10.100.7.0/24 dev ip_xfrm scope link
10.110.6.128/25 dev ip_xfrm scope link
192.168.15.0/24 dev ens18 proto kernel scope link src 192.168.15.22

root@ipsec:~# traceroute 10.100.7.131
traceroute to 10.100.7.131 (10.100.7.131), 30 hops max, 60 byte packets
 1  ipsec (192.168.15.22)  0.018 ms !H  0.005 ms !H  0.004 ms !H
root@ipsec:~# ping 10.100.7.131
PING 10.100.7.131 (10.100.7.131): 56 data bytes
92 bytes from ipsec (192.168.15.22): Destination Host Unreachable
92 bytes from ipsec (192.168.15.22): Destination Host Unreachable
^C--- 10.100.7.131 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
root@ipsec:~#

[donjirka]

root@ipsec:~# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

[donjirka]

Tak jsem zjistil, že mám asi nějakou chybu v routingu. IPsec se mi spojí a vytvoří tunel, dokonce se objeví packet se směru z venku ke mě, ale nemůžu nasměrovat nic do tunelu.

adresa eth18 mám 192.168.15.22/24 a 10.110.6.129/25 a chci se spojit s adresu v na druhé straně ipsec 10.100.7.1/24.

root@ipsec:~# ip route list
default via 192.168.15.1 dev ens18 proto static
10.100.7.0/24 dev ens18 proto kernel scope link src 10.110.6.129
10.110.6.128/25 dev ens18 proto kernel scope link src 10.110.6.129
192.168.15.0/24 dev ens18 proto kernel scope link src 192.168.15.22

Po ping na 10.100.7.1 je v statusu stále 0 bytes_i, 0 bytes_o. Když zkoušíme ping z druhé strany na 10.110.6.129 je tam 40 bytes_i, 0 bytes_o.

Evidentně je chyba pouze u mě.

[X]

Maxuv navod nevysel? https://www.abclinuxu.cz/poradna/linux/show/494577#1 + tcpdump

[donjirka]

Ahoj, ten vyšel, ale neumím nasměrovat provoz do IPSec tunelu. Na obou stranách se nachází NAT a nerozumím síťařině natolik, abych to rozchodil. IPSec se mi vytvoří mám IKE i SA a dokonce při ipsec statusall RX/TX jsou dokonce vidět příchozí packety z druhé strany od CISCO. Ovšem když zkusím ping odemě, tak pěkné kulové.

[Max]

Proč děláš u ipsecu nat? Resp. možná by jsi měl dodat nějaké schema, jak ta komunikace jde / má fungovat?
Zdar Max

[X]

IPSec s oboustrannym NAT mozny je, ale doporucoval bych si nejprve vytvorit prevodni tabulku pro dve strany => jake site se budou pouzivat pro IPSec a a jake site se budou prekladat.

[donjirka]

Příloha:

• IPSec.png (55409 bytů)

Posílám schéma

[X]

No tak nic ;). Pust si konecne ten tcpdump a podivej se zda tvuj ping odchazi zabaleny do ipsecu, nebo to pada nesifrovane jinam.

[donjirka]

To dělám od začátku, ale nevím co s tím, prostě packety vrací můj server a říká cíl nedostupný. Packety mi prostě nevlezou do tunelu.

[donjirka]

Nabízím za připojení a opravu tiscku na hodinu, pokud by se někdo našel.

[Max]

Narazil jsem na případ, že se tunel jakoby sestavil, ale data nešla, bo to šlo přes NAT a port 4500 byl nedostupný, takže došlo jen k částečné komunikaci na portu 500.
Zdar Max

[X]

Opracdu nerad se opakuju, ale posli vypis tech tri prikazu co jsem poslal na zacatku. Nevzdaval bych to.

[alkoholik]

Predpoklad virtualniho adapteru je chybny. Kernel zasifruje paket po routingu, pokud trefi nejakou xfrm policy.
Viz napoveda.
Vidis neco ve vystupu tcpdump -lnp -i any esp?