Problema con rotta statica

Tutto ciò che ha a che fare con le reti

Moderatore: Federico.Lagni

Rispondi
casalicomputers
n00b
Messaggi: 6
Iscritto il: ven 05 ott , 2012 1:46 pm

Salve a tutti,
Ho la necessità di poter raggiungere dalla mia rete LAN (192.168.2.0/24) degli host su una VPN (172.16.202.0/24) avendo come default gateway per la LAN uno ZyWALL con IP 192.168.2.254 e un server linux con IP 192.168.2.103 che fa da router per la VPN (OpenVPN). Visto che vorrei evitare di configurare la rotta statica su ogni pc, ho pensato di aggiungerla sullo ZyWALL...

Sorpresa sorpresa: non funziona nada.. o meglio gli host sulla vpn rispondono al ping, ma se provo ad es. a connettermi alla porta 25 di un server SMTP sulla VPN la connessione viene stabilita ma non c'è traffico (non vedo nemmeno il banner dell'smtp..). Configurando invece direttamente la rotta statica sui pc, funziona tutto perfettamente.

Dopo una sessione di sniffing sul client ho notato che i pacchetti eseguono questo percorso:

(SRC: 192.168.2.123 - DST: 172.16.202.5)

1. CLIENT (192.168.2.123) -> ZYWALL (192.168.2.254)
2. ZYWALL (192.168.2.254) -> LINUX (eth0:192.168.2.103)
3. LINUX (tun0:172.16.202.1) -> VPN (172.16.202.5)
4. VPN (172.16.202.5) -> LINUX (tun0:172.16.3.201)
5. LINUX (eth0:192.168.2.103) -> CLIENT (192.168.2.123)

<miopensiero>
Al punto 5 mi aspettavo che il pacchetto passasse nuovamente per lo zywall e successivamente ritornasse al client, ma evidentemente ha come indirizzo di destinazione l'ip del client e quindi viene routato direttamente verso l'interfaccia eth0, il client si accorge che il pacchetto di ritorno che gli arriva non proviene dalla sorgente giusta e lo scarta. Però comunque non mi spiego perchè la sessione viene stabilita...
</miopensiero>


- Come posso risolvere questo problema?
- Perchè i ping funzionano?
- Perchè la sessione viene stabilita ma non c'è traffico?

Spero di essere stato chiaro...
Grazie
Michele Brodoloni
System & Network Administrator
Rizio
Messianic Network master
Messaggi: 1158
Iscritto il: ven 12 ott , 2007 2:48 pm
Contatta:

Prova ad impostare la rotta di ritorno sull'host linux verso il ZyWall.
Credo che il problema possa derivare dal fatto che la macchina linux conosce già i client della tua lan perciò li contatta direttamente dopo aver ruotato il traffico dalla vpn e salta perciò il passaggio dallo zywall che probabilmente fà nat o altre cose simili.
Insomma mi verrebbe da pensare che salta un passaggio che per ICMP non è fondamentale mentre per l'handshake di TCP si.

Rizio
Si vis pacem para bellum
webmad
n00b
Messaggi: 10
Iscritto il: lun 27 giu , 2011 11:55 am

Ad occhio e croce, sembra che il server Linux ed il client siano sulla stessa subnet. In questo caso e' normale che i pacchetti che tornano dalla VPN vadano direttamente dal server Linux al client.
Se vuoi essere sicuro che tutto il traffico passi dallo ZW sia all'andata che al ritorno, puoi configurare una nuova interfaccia senza NAT con un'altra subnet sullo ZW (gli USG hanno LAN1 e LAN2) ed attestarci sopra solo il server Linux.
A questo punto, con IP inventati, il traffico girerebbe, p.es. cosi':

1. CLIENT (192.168.2.123) -> ZYWALL (lan1:192.168.2.1)
2. ZYWALL (lan2:192.168.10.1) -> LINUX (eth0:192.168.10.254)
3. LINUX (tun0:172.16.202.1) -> VPN (172.16.202.5)
4. VPN (172.16.202.5) -> LINUX (tun0:172.16.3.201)
5. LINUX (eth0:192.168.10.254) -> ZYWALL (lan2:192.168.10.1)
6. ZYWALL (lan1:192.168.2.1) -> CLIENT (192.168.2.123)

Se il default gw dei client e' gia' lo ZW, sui client non devi cambiare nulla.
Imposti lo ZW come default gw del server Linux ed il gioco e' fatto :)

-Pietro.
casalicomputers
n00b
Messaggi: 6
Iscritto il: ven 05 ott , 2012 1:46 pm

@Rizio:
Prova ad impostare la rotta di ritorno sull'host linux verso il ZyWall.
e come? dovrei mettere una rotta statica sul server linux dicendogli che "tutti i pacchetti per la rete 192.168.2.0/24 girameli su 192.168.2.254". Ma poi di conseguenza dai client non riuscirei a raggiungere il server linux perchè il traffico di ritorno passa dallo zywall... in pratica mi ritroverei con lo stesso problema...

@webmad:
Si c'avevo già pensato... solo che non posso stravolgere la rete in questo modo (dovrei cambiare l'indirizzo ip al server linux, e in più mi ritroverei con un link a 100mbit anzichè ad 1gbit da/verso i client visto che sarei sempre routato dallo zywall.. e siccome il server linux fa anche da file server....).
La cosa più semplice allora sarebbe far fare al server linux da default gateway per la lan (e mi andrei ad eliminare lo zywall che non mi serve più a questo punto), però vorrei capire se è possibile fare questo tipo di configurazione oppure no... Ah.. ho dimenticato di dirlo: lo ZyWALL è già il default gw del server linux.

Altre soluzioni?

Grazie ;)

EDIT:
Premetto che non so quanto sia attendibile questo test, però ho provato a simulare la cosa con packet tracer, e stranamente.... funziona... :)
Michele Brodoloni
System & Network Administrator
Rizio
Messianic Network master
Messaggi: 1158
Iscritto il: ven 12 ott , 2007 2:48 pm
Contatta:

casalicomputers ha scritto:ho dimenticato di dirlo: lo ZyWALL è già il default gw del server linux.
Se lo ZyWall è già il suo default gw la mia ipotesi in ogni caso non centra.

Altre idee non mi vengono in mente adesso, sorry

Rizio
Si vis pacem para bellum
casalicomputers
n00b
Messaggi: 6
Iscritto il: ven 05 ott , 2012 1:46 pm

Ho provato a mettere su un client di test con linux per vedere con tcpdump che succede e questo è il risultato:

Codice: Seleziona tutto

[root@TEST ~]# tcpdump -i eth0 -n | grep 172.16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:45:15.086957 IP 192.168.2.128.47126 > 172.16.202.5.smtp: Flags [F.], seq 1052538782, ack 750534613, win 115, options [nop,nop,TS val 31604 ecr 344707820], length 0
17:45:17.082946 IP 192.168.2.128.47125 > 172.16.202.5.smtp: Flags [F.], seq 561592906, ack 838252206, win 115, options [nop,nop,TS val 33600 ecr 344585885], length 0
17:45:22.461001 IP 192.168.2.128.47127 > 172.16.202.5.smtp: Flags [S], seq 1902475141, win 14600, options [mss 1460,sackOK,TS val 38978 ecr 0,nop,wscale 7], length 0
17:45:22.500669 IP 172.16.202.5.smtp > 192.168.2.128.47127: Flags [S.], seq 2173461142, ack 1902475142, win 14480, options [mss 1368,sackOK,TS val 344741307 ecr 38978,nop,wscale 7], length 0
17:45:22.500687 IP 192.168.2.128.47127 > 172.16.202.5.smtp: Flags [.], ack 1, win 115, options [nop,nop,TS val 39017 ecr 344741307], length 0
17:45:22.501271 IP 192.168.2.128 > 172.16.202.5: ICMP host 192.168.2.128 unreachable - admin prohibited, length 48
Faccio notare l'ultima riga:
17:45:22.501271 IP 192.168.2.128 > 172.16.202.5: ICMP host 192.168.2.128 unreachable - admin prohibited, length 48.

la connessione via telnet invece rimane in questo stato:

Codice: Seleziona tutto

[root@TEST ~]# telnet 172.16.202.5 25
Trying 172.16.202.5...
Connected to 172.16.202.5.
Escape character is '^]'.
Qualche idea?
Michele Brodoloni
System & Network Administrator
casalicomputers
n00b
Messaggi: 6
Iscritto il: ven 05 ott , 2012 1:46 pm

Eureka... sembra che abbia risolto il problema che a quanto pare era causato dal firewall stesso.
E' bastato semplicemente abilitare il flag Allow asymmetrical route sulla configurazione dello ZyWALL... :x

La documentazione ZyXEL riporta:

Codice: Seleziona tutto

Asymmetrical routes only apply if you have another gateway on your LAN, the ZyWALL is in Router mode, and the firewall is enabled. If return traffic is routed through the LAN gateway (instead of the ZyWALL), then the ZyWALL may reset the `incomplete' connection. When you enable asymmetrical routes, interface to same interface (for example WAN to WAN, VPN to VPN and so on) traffic is not checked by the firewall. 
Sul sito Cisco invece ho trovato un articolo dove viene spiegato in dettaglio il concetto dell'asymmetrical routing:
http://www.cisco.com/web/services/news/ ... 00903.html

Codice: Seleziona tutto

What is Asymmetric Routing?
In Asymmetric routing, a packet traverses from a source to a destination in one path and takes a different path when it returns to the source. This is commonly seen in Layer-3 routed networks.
Spero sia utile a qualcuno....
Michele Brodoloni
System & Network Administrator
Rizio
Messianic Network master
Messaggi: 1158
Iscritto il: ven 12 ott , 2007 2:48 pm
Contatta:

Buono a sapersi, grazie

Rizio
Si vis pacem para bellum
Rispondi