SMPFR

tite question car je tourne en rond j'ai demandé à Z elle m'a donné une piste mais j'ai pas envie de la faire chier trop avec ca

pour replacer le contexte j'ai mon esxi avec une VM gateway qui contient mes 4 ips publiques, le lan interne et un serveur openvpn
je fais du NAT/firewall avec le petit outil FriduFirewall qui permet de faire des scripts assez parlant pour gérer les paramètres

genre on définit une ip / zone par interface publique et il fait tout seul les chains/et autres entrées iptables

ca marche nickel sauf quand j’essaie de nater vers un client openvpn
avec ce que j'ai actuellement de réglé j'ai essayé de débugger avec nmap / tcpdump et ce que je vois :
* mon port naté est vu comme filtered depuis l'extérieur
* quand j'essaie d'ouvrir une page web (le port nat pointe sur du 80) je vois bien un premier paquet avec tcpdump mais pas de réponse jsute le navigateur qui envoi la première demande
* quand je fouine le paquet il arrive bien après le NAT et repart bien vers le client openvpn
* sur le client openvpn je vois bien ce paquet arriver ... mais pas de traffic

* quand je test ma page web depuis la vm gateway (genre lynx http://ip_client_openvpn) j'ai bien ma page qui s'affiche donc le serveur web répond bien à la gateway
mais voila ... y'a un truc qui passe pas avec le nat

sans aller dans ce que j'ai déjà configuré
quel devrait être les lignes de base pour router de eth0 (une des ip publique) vers tun0

Voici juste la partie iptables-save concernant la zone vpn
*nat
:zVpn0-postrouting - [0:0]
:zVpn0-prerouting - [0:0]

-A PREROUTING -j zVpn0-prerouting
-A POSTROUTING -j zVpn0-postrouting
-A zVpn0-postrouting -s LAN_OPENVPN/24 -o eth0 -j SNAT --to-source IP_PUBLIC
-A zVpn0-prerouting -d IP_PUBLIC/32 -i eth0 -p tcp -m tcp --dport 89 -j DNAT --to-destination IP_OPENVPN_CLIENT:80

*filter
:zVpn0-brforward - [0:0]
:zVpn0-forwarding - [0:0]
:zVpn0-input - [0:0]
:zVpn0-output - [0:0]
-A FORWARD -j zVpn0-forwarding
-A FORWARD -j zVpn0-brforward
-A OUTPUT -j zVpn0-output

-A zVpn0-brforward -i tun0 -o eth0 -j ACCEPT
-A zVpn0-brforward -i eth0 -o tun0 -j ACCEPT
-A zVpn0-brforward -i tun0 -o tun0 -j ACCEPT
-A zVpn0-input -i tun0 -j ACCEPT
-A zVpn0-input -d IP_PUBLIC/32 -i eth0 -p tcp -m tcp --dport 89 -j ACCEPT



si quelqu'un a une idée ^^ j'ai pas vu de diff entre d'autres zones qui marche et cette zone zVpn0 ou alors y'a une questionde config dans openvpn que j'ai loupé
mais je pars du principe que si en Cli depuis la gateway le serveur web répond bien ... c'est que ca doit marcher
pas différent du lan

snif personne cador de iptables ?

peut être con mais t'as ca: -A zVpn0-input -i tun0 -j ACCEPT

pk pas tester avec en plus un ouput?

je peux tester oui
mais aps sur car les autres zones l'ont pas et elles marchent

il me semble que j'avais déjà rencontré ce problème et que ce n'était peut être pas possible quand openvpn était effectué depuis la même interface réseau où tu souhaites faire le routage.

Mais je dis peut être des bétises

testé sans succès giz


Z, j'ai pas tout compris

bon tout simplement un soucis de route visiblement ...
quand je force avec un redirect-gateway en début de conf client openvpn
.... miracle ca marche
donc y'a une couille

bon tout simplement un soucis de route visiblement ...
quand je force avec un redirect-gateway en début de conf client openvpn
.... miracle ca marche
donc y'a une couille

ahhhh

si t'as un paquet qui vient de l'extérieur, qui est redirigé vers ton pc via le tunnel, faut qu'il utilise le pc qui fait le NAT comme passerelle, et pas utiliser sa route par défaut qui lui permet d'aller vers l'extérieur.

ça fait genre ça


[client] -----> [routeur] ----> [serveur via VPN] ------> _j'utilise ma route par défaut__ ---X [client] (oh tiens ça marche pas, il sait pas que je suis censé lui répondre par là)

uhmmmm faut qu'on papote en mp demain jte passerai mes ips et réglages tu me dira ce qui merde si ca te dérange pas

je sais pas utiliser iptables

ça dérange si tout ton trafic internet du client VPN passe par le serveur VPN ?

edit: en fait il te faudrait une route par défaut différente pour l'interface tun0 sur ton client VPN, quand ça vient par là il sait que ça doit repartir par la route du VPN

la c'est pas iptables mais route au niveau client
j'y connais pas énorme
mais oui voila il doit savoir que ce qui arrive du vpn doit repartir par la
mais il faut qu'il puisse accéder au reste de son propre lan aussi
je peux pas tout passer par le serveur vpn .... quoique ^^ je vais tester ^^

dans les option VPN, t'as une option push_route ou un truc du genre qui te permet de donner la route a utiliser plutôt que la Gateway par defaut pour le traffic vers le serveur VPN ou le LAN derriere.

bien ce qu'il me semble que j'ai mais je me demande si j'avais pas eu un soucis avec windows ou autre et adapté ce push_route

je regarde tout à l'heure

http://smpfr.mesdiscussions.net/smpfr/S ... _514_1.htm
ligne 35 de la conf serveur

NB: dans mon cas client et serveur etaient du Windows, mais pas de raison que l'option soit pas reconnue sur un serveur linux.

bon j'ai rajouté mes routes (effectivement je pensai les avoir dans la conf mais niet ...)
si je prend par exemple le plan d'adressage suivant
192.168.1.0 = réseau de mes VMs sur l'esxi
192.168.10.0 = réseau de mon vpn



sur mon client je dois router
192.168.1.0 255.255.255.0
192.168.10.0 255.255.255.0

j'ai bien les deux routes dans mes linux/win

donc depuis le client vpn j'arrive bien à accéder à mes vms
(si je fais un wget de l'ip interne de la vm web j'ai bien ma page de base)

mais par contre toujours aucun retour
brainfuck c'est vraiment un domaine ou je ne suis pas à l'aise

ça donne quoi "ip route show" sur ton client openvpn ?

default via 129.xxxxxx dev eth0

essaie ça

route add default gw 192.168.10.9 dev tun0 (ou peut être qu'y a pas le mot clé dev)

des que je rajoute la route
je peux plus pinger depuis mon serveur vpn vers le client et le client n'a plus accès a son lan origine (logique tu me dira)

des que je rajoute la route
je peux plus pinger depuis mon serveur vpn vers le client et le client n'a plus accès a son lan origine (logique tu me dira)

non pas logique

on a précisé "dev tun0" du coup il est censé pas faire n'importe quoi

après avoir fait la commande route add, "ip route show" ressemble à quoi ?

2sec je bricole un truc avec les ccd je lui avait pas mis une ip fixe ^^

non pas logique

si, logique vu que tu redirige tout le traffic (default GW).
il n'a donc plus accès au lan local au client.

ce qui est moins logique c'est qu'il ne joigne toujours pas le LAN du VPN (enfin le retour)

si, logique vu que tu redirige tout le traffic (default GW).
il n'a donc plus accès au lan local au client.

ce qui est moins logique c'est qu'il ne joigne toujours pas le LAN du VPN (enfin le retour)

route par défaut pour tun0 [:al0y]

ouais mais non, c'est par defaut tout court.

poulpi, t'as vu ça ? (surtout la fin)
http://smpfr.mesdiscussions.net/smpfr/S ... htm#t10558
pas sur que ça résolve tes soucis, mais je me rappelle en avoir chié pour faire tourner openvpn sur des Win7

ouais mais non, c'est par defaut tout court.

poulpi, t'as vu ça ? (surtout la fin)
http://smpfr.mesdiscussions.net/smpfr/S ... htm#t10558
pas sur que ça résolve tes soucis, mais je me rappelle en avoir chié pour faire tourner openvpn sur des Win7

non non, tu peux avoir une route par défaut par interface sous linux ou même par adresse IP sur une interface !

je l'ai déjà fait (des trucs tordus où faut passer du trafic par un VPN quand ça utilise telle IP)