View Full Version : OpenVPN - Routing / NAT
Buongiorno,
vi chiedo una mano perchè sono arrivato ad un punto morto :(
Scenario : collegamento di due sedi remote via openvpn
Situazione attuale : tutto configurato, connessione up e host che si vedono fra loro
Problema : dal server openvpn della sede remota riesce a vedere tutti i pc della sede centrale, dai pc della sede centrale riesco a vedere solo il server della sede remota e oltretutto solo tramite ip del tunnel (10.0.x.x) e non tramite ip locale della macchina remota.
In sede centrale, il server openvpn è una macchina con pfsense, nella sede remota un server con ubuntu.
Ho configurato su pfsense il routing alla sede remota, se attivo la cattura dei pacchetti sull'interfaccia openvpn del pfsense e pingo un'host della sede remota, vedo che i pacchetti prendono la rotta giusta, solo che non arriva nessuna risposta
Dall'altra parte (server sede remota), pingo tranquillamente ogni ip della sede locale
A livello di NAT, non ho configurato niente
Che può esserci che non va?
P.S. aggiungo due info :
Sede remota : macchina ubuntu, non gateway di rete
Sede centrale : macchina pfsense, collegata in wan ad un router telecom
malatodihardware
21-03-2016, 21:39
Devi aggiungere una route statica sui PC (o sul gateway) della rete remota per raggiungere la sede usando come gateway il server ubuntu
Inviato dal mio Nexus 5
Già aggiunta, sia sul server openvpn che sul gateway della rete remota
Dal server della rete remota le rotte sono ok, raggiungo ogni pc della sede centrale; dai pc della rete remota invece no, ma devo sistemare il forwarding della macchina server openvpn che al momento non è attivo
Ho parzialmente risolto, adesso riesco a pingare il server remoto openvpn sul suo indirizzo di rete.
A futura referenza, è bastato cambiare il tipo di tunnel da tun a tap
Ora mi metto a sistemare il forwarding sul server remoto e vedo se sistemo il resto :)
Ho parzialmente risolto, adesso riesco a pingare il server remoto openvpn sul suo indirizzo di rete.
A futura referenza, è bastato cambiare il tipo di tunnel da tun a tap
Ora mi metto a sistemare il forwarding sul server remoto e vedo se sistemo il resto :)
tun e tap sono giusto un pelo diversi.....
Che indirizzamento hai tra le due sedi?
Confesso la mia ignoranza in fatto di VPN :)
Sede remota : LAN 192.168.5.0
Sede centrale : LAN 192.168.2.0
Tunnel : 10.0.8.0
Al momento, dopo tanti smaneggiamenti, la situazione si presenta così :
Il server sede remota raggiunge tutti i pc della sede centrale
Da ogni pc della sede centrale si raggiunge il server della sede remota, anche con il suo ip locale (192.168.5.100)
Dalla sede centrale, non si riesce ad accedere ai pc della lan remota, ne dai pc della lan centrale ne dal server centrale
Dai pc della rete remota, non si raggiunge niente, nemmeno il server centrale remoto
Route server sede remota
Tabella di routing IP del kernel
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.5.1 0.0.0.0 UG 0 0 0 eth0
10.0.8.0 * 255.255.255.0 U 0 0 0 tap0
192.168.2.0 10.0.8.1 255.255.255.0 UG 0 0 0 tap0
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
Route server centrale
default 192.168.1.1 UGS 45178 1500 xn1
10.0.8.0/24 link#7 U 0 1500 ovpns1
10.0.8.1 link#7 UHS 9922 16384 lo0
127.0.0.1 link#3 UH 52 16384 lo0
192.168.1.0/24 link#6 U 7334 1500 xn1
192.168.1.2 link#6 UHS 0 16384 lo0
192.168.2.0/24 link#5 U 68177 1500 xn0
192.168.2.254 link#5 UHS 0 16384 lo0
192.168.5.0/24 10.0.8.1 UGS 14 1500 ovpns1
Aggiungo tcpdump sul server remoto di ping da pc della sede remota a pc sede centrale
mauri@NasStation:~$ sudo tcpdump -i tap0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:30:25.547740 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7666, seq 1, length 64
13:30:26.549942 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7666, seq 2, length 64
Mi pare di capire che il traffico viene indirizzato correttamente, semplicemente non arrivano risposte dall'altra parte
Questo è il packet capture sull'interfaccia openvpn del server centrale dello stesso comando di prima
13:32:46.477558 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 52
13:32:46.533988 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 68
13:32:46.565297 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 0
13:32:47.165285 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 52
13:32:47.222976 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 52
13:32:47.234698 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 100
13:32:47.235063 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 0
13:32:47.239584 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 1, length 64
13:32:47.240225 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:48.241992 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 2, length 64
13:32:48.242284 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:49.241544 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 3, length 64
13:32:49.241782 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:50.240604 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 4, length 64
13:32:50.240880 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:51.241647 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 5, length 64
13:32:51.241890 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:52.241234 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 6, length 64
13:32:52.241471 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:53.240841 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 7, length 64
13:32:53.241246 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:54.242097 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 8, length 64
13:32:54.242386 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:55.244573 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 9, length 64
13:32:55.244847 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:56.240437 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 10, length 64
13:32:56.240722 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:57.241716 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 11, length 64
13:32:57.241946 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
Confesso la mia ignoranza in fatto di VPN :)
Sede remota : LAN 192.168.5.0
Sede centrale : LAN 192.168.2.0
Tunnel : 10.0.8.0
Al momento, dopo tanti smaneggiamenti, la situazione si presenta così :
Il server sede remota raggiunge tutti i pc della sede centrale
Da ogni pc della sede centrale si raggiunge il server della sede remota, anche con il suo ip locale (192.168.5.100)
Dalla sede centrale, non si riesce ad accedere ai pc della lan remota, ne dai pc della lan centrale ne dal server centrale
Dai pc della rete remota, non si raggiunge niente, nemmeno il server centrale remoto
Route server sede remota
Tabella di routing IP del kernel
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.5.1 0.0.0.0 UG 0 0 0 eth0
10.0.8.0 * 255.255.255.0 U 0 0 0 tap0
192.168.2.0 10.0.8.1 255.255.255.0 UG 0 0 0 tap0
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
E' abilitato il routing sul server remoto?
I client usano il server remoto (192.168.5.100) come gateway?
Se no, puoi impostare su 192.168.5.1 di passare da 192.168.5.100 per 192.168.0.2/24 e 10.0.8.0/24.
Route server centrale
default 192.168.1.1 UGS 45178 1500 xn1
10.0.8.0/24 link#7 U 0 1500 ovpns1
10.0.8.1 link#7 UHS 9922 16384 lo0
127.0.0.1 link#3 UH 52 16384 lo0
192.168.1.0/24 link#6 U 7334 1500 xn1
192.168.1.2 link#6 UHS 0 16384 lo0
192.168.2.0/24 link#5 U 68177 1500 xn0
192.168.2.254 link#5 UHS 0 16384 lo0
192.168.5.0/24 10.0.8.1 UGS 14 1500 ovpns1
[/quote]
Qua non batte 10.0.8.1. Non dovrebbe essere 10.0.8.2? (ma ti confesso che le vpn tap-tap le evito a prescindere, quindi metterei tun-tun).
Assicurati inoltre che i due "server vpn" non nattino.
Non l'avevo precisato, ma nella sede remota il server openvpn non è il default gateway, ma ho già provveduto ad aggiungere al default gateway (192.168.5.1) le due route per 10.0.8.0 e 192.168.2.0
Qua non batte 10.0.8.1. Non dovrebbe essere 10.0.8.2? (ma ti confesso che le vpn tap-tap le evito a prescindere, quindi metterei tun-tun).
Assicurati inoltre che i due "server vpn" non nattino.
Sono un co....ne, si, dovrebbe essere 10.0.8.2, e infatti adesso va tutto :D
Pensa te, c'avrò guardato 100 volte e non me n'ero accorto :cry:
Grazie mille Dane :)
ben.
prima di metterlo in produzione togli il tap a favore del tun.
Ti dovrebbe evitare un po' di broadcast inutili (nel senso che se servono c'è qualcosaltro che non va).
W!
Dane
Sto provando a reimpostare la vpn con tun, solo che ora mi ritrovo nella situazione iniziale :cry:
Questo è il route attuale sul server centrale
default 192.168.1.1 UGS 3848 1500 xn1
10.0.8.0/24 10.0.8.2 UGS 307 1500 ovpns1
10.0.8.1 link#7 UHS 1288 16384 lo0
10.0.8.2 link#7 UH 115 1500 ovpns1
127.0.0.1 link#3 UH 36 16384 lo0
192.168.1.0/24 link#6 U 1200 1500 xn1
192.168.1.2 link#6 UHS 0 16384 lo0
192.168.2.0/24 link#5 U 5398 1500 xn0
192.168.2.254 link#5 UHS 0 16384 lo0
192.168.5.0/24 10.0.8.2 UGS 3 1500 ovpns1
Mar 22 16:51:21 openvpn[61971]: xxxxxx [xxxxx] Peer Connection Initiated with [AF_INET]xxxxxxxx
Mar 22 16:51:21 openvpn[61971]: xxx/xxxx MULTI_sva: pool returned IPv4=10.0.8.6, IPv6=(Not enabled)
Mar 22 16:51:23 openvpn[61971]: xxx/xxxx send_push_reply(): safe_cap=940
Questo il route sul server remoto
Tabella di routing IP del kernel
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.5.1 0.0.0.0 UG 0 0 0 eth0
10.0.8.1 10.0.8.5 255.255.255.255 UGH 0 0 0 tun0
10.0.8.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 10.0.8.5 255.255.255.0 UG 0 0 0 tun0
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
ma stai mettendo indirizzi a caso?
10.0.8.2
10.0.8.5
10.0.8.6 :confused:
Ho visto, in realtà non sto mettendo niente io, sono indirizzi che prende in automatico :
in pratica server prende 10.0.8.1 e come gateway 10.0.8.2
Server remoto prende 10.0.8.6 come ip e 10.0.8.5 come gateway
I due indirizzi 10.0.8.2 e 10.0.8.5 non sono pingabili
Dal server remoto riesco però a raggiungere correttamente tutti i pc della rete centrale
Ok, ho trovato il responsabile di questo "comportamento", nella configurazione di default tun di pfsense abilita un'opzione "Address Pool : Provide a virtual adapter IP address to clients (see Tunnel Network) "
Disabilitata questa, il client mi prende 10.0.8.2 e tutti son felici e contenti :D
Grazie ancora Dane :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.