A proposito dell'autore

CCSP, CCNP, CCIP, CCNP(Sec)

Ultimamente mi capita spesso di realizzare VPN con IOS, PIX o ASA. I primi tempi usavo il Wizard, poi son passato a configurare le varie componenti dall’interfaccia grafica, ultimamente uso spesso la command line, indispensabile sopratutto per il troubleshooting.

Tra i vari tipi di VPN non mi era ancora capitato di dover applicare la GRE over IPSEC. Parlando con colleghi alcuni mi correggevano: “Non GRE over IPSec ma IPSec over GRE”.

Siccome l’argomento mi interessa e sono in fase di implementazione, ho ben pensato di farmi un piccolo lab per chiarire un po’ la questione:

lab-gre

Alla “nuvola” C4 ho collegato la ethernet dell’iMac che a sua volta collega un portatile usato per le prove.

Questa la configurazione IP dei due router:

R3#sh ip inte brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.2.0.2 YES manual up up
Loopback1 10.3.0.1 YES manual up up
Tunnel0 10.50.0.2 YES manual up up

R4#sh ip inte brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.1.0.220 YES manual up up
FastEthernet1/0 10.2.0.1 YES manual up up
Tunnel0 10.50.0.1 YES manual up up

E questa la configurazione dei tunnel:

R4#sh run inte tun 0

interface Tunnel0
ip address 10.50.0.1 255.255.255.0
tunnel source FastEthernet1/0
tunnel destination 10.2.0.2
crypto map vpn
end
R3#sh run inte tun 0

interface Tunnel0
ip address 10.50.0.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.2.0.1
crypto map vpn
end

Ometto i vari passaggi di configurazione di isakmp, tunnel-group, crypto map ecc. dato che sono facili e ben documentati in QUESTA guida sul sito Cisco.

Ora, la questione è… GRE over IPSEC o IPSEC over GRE, quindi qual è il pacchetto che effettivamente arriva dall’altra parte e chi viene incapsulato?

Innanzitutto una semplice prova: sul router R3 creo una access-list:

R3#sh ip access-lists 150
Extended IP access list 150
10 permit esp host 10.2.0.1 host 10.2.0.2 (890 matches)
20 permit udp host 10.2.0.1 host 10.2.0.2 eq isakmp (15 matches)
30 permit gre host 10.2.0.1 host 10.2.0.2

ed ecco la risposta, nessun match per il traffico GRE. Creo una access-list speculare su R4:

R4#sh ip access-lists 150
Extended IP access list 150
10 permit gre host 10.2.0.2 host 10.2.0.1
20 permit udp host 10.2.0.2 host 10.2.0.1 eq isakmp (30 matches)
30 permit esp host 10.2.0.2 host 10.2.0.1 (70 matches)

Provo a resettare la VPN con un “clear crypto session” e ancora, niente GRE, solo traffico ESP e UDP/isakmp.

Svelato l’arcano!

Al di là della prova empirica, ci si può arrivare anche per deduzione: il pacchetto GRE incapsula di tutto, unicast, multicast, etc mentre il pacchetto IPSEC in questo caso incapsula solo il GRE come specificato nella crypto map:

R4#sh crypto map
Crypto Map "vpn" 10 ipsec-isakmp
Peer = 10.2.0.2
Extended IP access list 100
access-list 100 permit gre host 10.2.0.1 host 10.2.0.2
Current peer: 10.2.0.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
strong,
}
Interfaces using crypto map vpn:
Tunnel0
FastEthernet1/0
  • nexthop

    Ciao Giampaolo, credo di fare un’osservazione scontata, cmq: l’ACL è applicata alle FE giusto? Immagino di si, perchè sono origine e terminazione del Tunnel. Ammesso che si possa applicare l’ACL all’interfaccia Tu0, dovremmo vedere quindi, solo tyraffico GRE, giusto?
    Grazie per l’articolo.

Close
Entra in contatto con altri professionisti ICT, seguici su Facebook e Twitter: