La Fibre
Datacenter et équipements réseaux => Routeurs => Ubiquiti => Discussion démarrée par: Salamafet le 14 mars 2019 à 11:33:23
-
Bonjour à tous,
Alors je sais, mon titre n'est pas très clair mais mon problème est difficile à résumer en seulement quelques mots.
Actuellement une partie de mon réseau est derrière une passerelle OpenVPN (vtun0).
Le problème c'est que quand j'ouvre un port vers une machine qui est derrière ce fameux VPN, ca ne fonctionne pas.
La machine doit absolument passer par la passerelle normale (WAN) pour que le port forwarding fasse son boulot.
J'ai aussi le problème quand je me connecte depuis l’extérieur en VPN (L2TP/IPsec) sur mon routeur. Je ne peux pas accéder à l'adresse IP local (LAN) d'un appareil sur mon réseau si ce dernier passe par la passerelle VPN (vtun0).
Ci-dessous la configuration de mon routeur:
firewall {
all-ping enable
broadcast-ping disable
group {
address-group VPN_address {
address 192.168.10.200
address 192.168.10.101-192.168.10.119
description "Source passant par le vpn"
}
address-group no_VPN_destination {
address 10.0.0.0/24
description "Destination ne passant pas par le VPN"
}
}
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
modify OPENVPN_ROUTE {
rule 10 {
action modify
description "via vpn"
destination {
address ""
group {
address-group !no_VPN_destination
}
}
modify {
table 1
}
source {
address ""
group {
address-group VPN_address
}
}
}
}
name DMZ_OUT {
default-action accept
description ""
rule 20 {
action drop
description "Block EdgeOS Manage"
destination {
address 10.0.0.1
port 80,443,22
}
log disable
protocol tcp_udp
}
rule 30 {
action drop
description "Block EdgeOS Ping"
destination {
address 10.0.0.1
}
log disable
protocol icmp
}
rule 40 {
action drop
description "Denied access to LAN"
destination {
group {
address-group NETv4_eth1
}
}
log disable
protocol all
}
}
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
log disable
state {
established enable
invalid disable
new disable
related enable
}
}
rule 30 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 20 {
action accept
description "Allow established/related"
log disable
state {
established enable
invalid disable
new disable
related enable
}
}
rule 30 {
action accept
description IKE
destination {
port 500
}
log disable
protocol udp
}
rule 40 {
action accept
description L2TP
destination {
port 1701
}
log disable
protocol udp
}
rule 50 {
action accept
description ESP
log disable
protocol esp
}
rule 60 {
action accept
description NAT-T
destination {
port 4500
}
log disable
protocol udp
}
rule 70 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
options {
mss-clamp {
mss 1412
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
ethernet eth0 {
address dhcp
description WAN
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
poe {
output off
}
speed auto
}
ethernet eth1 {
address 192.168.10.1/24
description LAN
duplex auto
firewall {
in {
modify OPENVPN_ROUTE
}
local {
}
out {
}
}
poe {
output off
}
speed auto
}
ethernet eth2 {
address 10.0.0.1/24
description DMZ
duplex auto
firewall {
local {
name DMZ_OUT
}
out {
name DMZ_OUT
}
}
poe {
output off
}
speed auto
}
ethernet eth3 {
disable
duplex auto
speed auto
}
ethernet eth4 {
address 192.168.50.1/24
disable
duplex auto
poe {
output off
}
speed auto
}
ethernet eth5 {
address dhcp
disable
duplex auto
mtu 1500
speed auto
}
loopback lo {
}
openvpn vtun0 {
config-file /config/vpn.ovpn
}
}
port-forward {
auto-firewall enable
hairpin-nat enable
lan-interface eth1
lan-interface eth2
rule 1 {
description "GIT [HTTP]"
forward-to {
address 10.0.0.2
port 80
}
original-port 80
protocol tcp
}
rule 2 {
description "GIT [HTTPS]"
forward-to {
address 10.0.0.2
port 443
}
original-port 443
protocol tcp
}
rule 3 {
description "GIT [SSH]"
forward-to {
address 10.0.0.2
port 22
}
original-port 22
protocol tcp
}
rule 4 {
description "NAS [CloudStation]"
forward-to {
address 192.168.10.10
port 6690
}
original-port 6690
protocol tcp
}
rule 5 {
description "NAS [Transmission Remote]"
forward-to {
address 192.168.10.10
port 9091
}
original-port 9091
protocol tcp
}
wan-interface eth0
}
protocols {
static {
table 1 {
interface-route 0.0.0.0/0 {
next-hop-interface vtun0 {
}
}
}
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name DMZ {
authoritative disable
subnet 10.0.0.0/24 {
default-router 10.0.0.1
dns-server 10.0.0.1
lease 86400
start 10.0.0.2 {
stop 10.0.0.2
}
static-mapping SRV-GIT {
ip-address 10.0.0.2
mac-address **:**:**:**:**:**
}
}
}
shared-network-name LAN1 {
authoritative enable
subnet 192.168.10.0/24 {
default-router 192.168.10.1
dns-server 192.168.10.1
lease 86400
start 192.168.10.101 {
stop 192.168.10.119
}
static-mapping TV {
ip-address 192.168.10.5
mac-address **:**:**:**:**:**
}
static-mapping WarMachine {
ip-address 192.168.10.100
mac-address **:**:**:**:**:**
}
static-mapping WifiMesh {
ip-address 192.168.10.200
mac-address **:**:**:**:**:**
}
static-mapping ipcam_00626E4C2041 {
ip-address 192.168.10.150
mac-address **:**:**:**:**:**
}
static-mapping jeedom {
ip-address 192.168.10.250
mac-address **:**:**:**:**:**
}
static-mapping raspberrypi {
ip-address 192.168.10.251
mac-address **:**:**:**:**:**
}
}
}
static-arp disable
use-dnsmasq disable
}
dns {
forwarding {
cache-size 3000
listen-on eth1
listen-on eth2
}
}
gui {
http-port 80
https-port 443
older-ciphers enable
}
nat {
rule 5001 {
description "LAN to DMZ"
destination {
address 10.0.0.0/24
}
disable
log disable
outbound-interface eth2
protocol all
type masquerade
}
rule 5002 {
description WAN
log disable
outbound-interface eth0
protocol all
source {
}
type masquerade
}
rule 5003 {
description "OpenVPN Client"
destination {
group {
}
}
log disable
outbound-interface vtun0
protocol all
source {
group {
}
}
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
ubnt-discover {
disable
}
unms {
connection wss://*********.pouet.fr
disable
}
upnp {
listen-on eth1 {
outbound-interface pppoe0
}
}
}
system {
host-name Snoopy
login {
user pouet {
authentication {
encrypted-password P0u3T
plaintext-password ""
}
full-name Pouet
level admin
}
}
name-server 1.1.1.1
name-server 1.0.0.1
name-server 9.9.9.9
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
offload {
hwnat disable
ipv4 {
forwarding enable
pppoe enable
}
}
static-host-mapping {
host-name 1.pouet.fr {
inet 10.0.0.2
}
host-name 2.pouet.fr {
inet 192.168.10.10
}
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone Europe/Paris
traffic-analysis {
dpi disable
export disable
}
}
vpn {
ipsec {
auto-firewall-nat-exclude enable
ipsec-interfaces {
interface eth0
}
nat-traversal enable
}
l2tp {
remote-access {
authentication {
local-users {
username pouet {
password P0u3T
}
}
mode local
}
client-ip-pool {
start 192.168.222.2
stop 192.168.222.10
}
dhcp-interface eth0
dns-servers {
server-1 1.1.1.1
server-2 9.9.9.9
}
idle 1800
ipsec-settings {
authentication {
mode pre-shared-secret
pre-shared-secret P0u3T
}
ike-lifetime 3600
lifetime 3600
}
}
}
}
Dans l'attente de vos lumière :)
-
Il est important d'être précis, car "ça ne fonctionne pas" ne veut pas dire grand chose :P
Déjà, si je comprends bien (à corriger si j'ai mal compris!) :
- Tu as un routeur connecté à un internet.
- Sur ce routeur tu as un VPN de configuré vers... (quelque part sur internet ? En local ?)
- Un réseau local
Quand tu dis "ça ne fonctionne pas", c'est de quelle machine vers quelle machine ? C'est important de le préciser. Depuis une machine d'internet vers une machine de ton VPN ? Ou depuis une machine du LAN vers ton VPN ?
Je ne sais pas trop ce que tu veux faire, mais le port forwarding est seulement configuré avec la patte wan, il est donc normal que "La machine doit absolument passer par la passerelle normale (WAN) pour que le port forwarding fasse son boulot.".
On doit pouvoir t'aider si tu précises un peu mieux tout ça :P
-
Merci de ton aide et pardon pour les imprécisions.
Oui mon routeur est connecté sur une Freebox en mode bridge.
Mon routeur à un serveur VPN en L2TP/IPsec et un client (fournisseur VPN) en OpenVPN.
J'aimerais pouvoir accéder depuis internet (port forwarding) à une machine sur mon LAN qui passe par la passerelle VPN.
Et j'aimerais pouvoir accéder aux machines de mon réseau local passant par la passerelle VPN quand je suis connecté au serveur VPN du routeur depuis l’extérieur.
J'espère être un peu plus clair même si j’admets m'y perdre aussi dans mes propres explications.
-
Ca veut dire quoi "une machine sur mon LAN qui passe par la passerelle VPN." ? Tes machines LAN n'utilises pas ton routeur puis ta freebox pour aller sur internet ? ou alors elles sortent sur internet via une machine hébergé ailleurs sur internet via OpenVPN ?
Je comprends pas, tu as un ou deux VPN ? Car ton VPN L2TP/IPsec ne peut pas se connecter à ton client OpenVPN, si ?
Si tu en as deux, qui se connecte à L2TP/IPsec et quelle est la deuxieme extrémité de ton client OpenVPN ?
Fais un petit schéma c'est dur à comprendre, ou alors c'est moi :P
-
J'ai fais un petit schéma pour essayer d'être plus claire.
(https://i.imgur.com/EUkikvV.png)
Les flèches rouge indiquent que la connexion ne fonctionne pas.
Les flèches verte indiquent que la connexion fonctionne.
En gros le serveur 1 passe par une passerelle VPN.
Quand une connexion arrive d'internet ou du serveur VPN local, elle ne peut pas l'atteindre.
Le serveur 2 lui passe par le chemin normal (WAN)
Si on essai d'atteindre le serveur depuis internet ou le VPN local, la connexion fonctionne.
Il ne faut pas confondre le serveur VPN et le client VPN (passerelle)
Dans les deux cas, tout est géré par le routeur.
J'aimerais savoir comment je peux faire en sorte que les machines passant par le VPN en sortie soit accessible depuis internet ou le VPN local.
Je sais c'est une configuration assez spéciale mais c'est important que cela reste ainsi. Je n'avais aucun soucis avec la même configuration sur PfSense.
-
Ah oui c'est quand même super spécifique, tu as bien fais de mettre le schéma. Il manque cependant l'adressage IP.
Serveur 1 est-il dans le même réseau que Serveur 2 ?
Car on est bien d'accord que le Serveur 1 est sur un réseau IP différent de "Fournisseur VPN".
Dans ce cas, la passerelle de Serveur 1 ne peut pas être "Fournisseur VPN" mais bien l'ip de l'edge routeur sur le "LAN" (avoir une passerelle situé dans un réseau différent me parait pas juste).
Sinon il y a une sorte de bridge, auquel cas précise nous comment tu fais. Mais du peu que j'ai regardé la configuration, ça ressemble à du PBR. En faisant ça, tu créés un routage asymétrique :
Une requête vient d'internet et ton serveur répond vers le VPN => Ton firewall ne voit pas de flux retour sur sa patte WAN et ça pose problème (pour les flux tcp du moins).
Du coup, il faut que tu rajoutes dans tes règles PBR une manière d'identifier un flux provenant de la patte WAN (via adresse ip source par exemple si tu utilises toujours la même) pour que celui-ci soit correctement renvoyé vers cette patte et non vers le fournisseur VPN lors du flux retour.
OU, ce qui serait le plus propre et le plus simple je pense, que tu fasses en sorte de communiquer sur ton serveur en passant vers ton Fournisseur VPN depuis internet et non par la patte Wan freebox (= plus de problème de routage asymétrique :) )
-
Effectivement je n'ai pas mis l'adressage IP mais le schéma est ultra simplifié.
Il y a en fait plusieurs sous-réseaux composés de DMZ et de WLAN GUEST et j'en passe. Mais les autres sous-réseaux ne sont pas concernés.
Les machines ce trouvant dans le LAN possèdent toutes la même passerelle. Tout est géré entièrement par le routeur.
C'est une règle sur le routeur qui indique si une adresse IP doit passer par le VPN en sortie ou par le WAN.
C'est pour ça que je suis sûr qu'il y a un moyen de corriger mon problème.
Dans le cas où une machine passerait par un VPN avec un logiciel par exemple, je comprendrais que cela soit compliqué.
J'ai lu quelques posts en anglais qui parlaient de règles sNAT et dNAT, mais je ne suis vraiment pas familier avec leur utilisation. Et d'ailleurs je ne sais même pas si ça réglerait mon problème.
En tout cas merci encore pour ton implication :)
-
Dans ce cas, il faut que tu saches identifier le traffic venant de la patte WAN pour faire le bon routage retour (en utilisant des IP sources publiques/un protocol ou port particulier/tag DSCP/ par exemple).
Une fois identifié, tu peux faire le même type de règle que ce que tu as fais jusqu'à présent sans problème.
Si tu n'as pas de moyen simple d'identifier le traffic source "internet", ça va être difficile de résoudre ton problème via du PBR.
-
tu obtiens qu'elle ip via le vpn (y'a quoi dans la config vpn) ou que donne un "show ip route"?
pour l2tp, ton client obtient une ip dans 192.168.222.2-10 qui n'est pas dans le no_VPN_destination du PBR.
donc quand serveur1 veut répondre a 192.168.222.2 par exemple les paquets partent directement dans le vpn (via table 1). donc soit tu changes table1 soit no_VPN_destination.
le hairpin n'a pas vtun0 comme wan-interface (pas gênant en soi dans ce cas sauf si tu utilises l'ip a l'autre bout du vpn)
-
Salut kgersen,
Merci pour ton aide. Tu viens de débloquer une partie de mon problème. J'avais créé la règle no_VPN_destination mais j'avais effectivement pas pensé à mettre le sous-réseau du serveur VPN dedans -_-'
Donc maintenant ça fonctionne, en me connectant au serveur VPN je peux me connecter à une machine qui utilise le VPN en sortie.
Voila le résultat du show ip route:
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
S *> 0.0.0.0/0 [210/0] via 82.64.90.254, eth0
C *> 0.0.0.0/24 is directly connected, vtun0
C *> 10.0.0.0/24 is directly connected, eth2
C *> 10.8.2.0/24 is directly connected, vtun0
C *> 10.255.255.0/32 is directly connected, l2tp0
C *> 8--.--.--.0/24 is directly connected, eth0 <==== Je cache volontairement mon ip fixe
C *> 127.0.0.0/8 is directly connected, lo
C *> 192.168.10.0/24 is directly connected, eth1
C *> 192.168.222.2/32 is directly connected, l2tp0
L'IP coté fournisseur VPN ne peut pas être jointe. Donc c'est normal pour le hairpin.
Voila le fichier de configuration du client VPN:
client
dev tun
proto udp
remote --.--.--.-- 1194 <=== Volontairement caché aussi :D
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo no
remote-cert-tls server
auth-user-pass pouetpouet.pouet
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512
## PERSO
route-nopull
<ca>
-----BEGIN CERTIFICATE-----
====
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
====
-----END OpenVPN Static key V1-----
</tls-auth>
-
Du coup, maintenant le problème c'est que tu veux que "Serveur 1" passe par le VPN, sauf si c'est une réponse à une connexion entrante par le WAN. Tu es obligé de faire ça parce que si tu sors par le VPN, alors l'adresse source des paquets n'est pas l'adresse sur le WAN, et c'est ce qu'un client attend...
Franchement, je ne vois pas comment résoudre ce problème.
-
Oui c'est ça.
Je suis bien conscient qu'il faut que la réponse sorte par le WAN. Sinon le routeur du demandeur de la ressource va clairement envoyer balader la réponse.
En supprimant les règles MASQUERADE sur Serveur 1 j'obtenais toujours mon IP publique. Et du coup en l'ajoutant à ma liste no_VPN_destination, ça fonctionnait.
Le problème c'est que je ne suis plus en mesure de différencier les IP externe. Ayant différents système anti hack, je ne pouvais plus compter sur le ban IP. Et ça c'est problématique.
J'avais pensé aussi à interdire la passerelle VPN pour certain port mais évidemment le port pour établir la connexion n'est pas le même une fois la connexion établie (normal).
-
Du coup, maintenant le problème c'est que tu veux que "Serveur 1" passe par le VPN, sauf si c'est une réponse à une connexion entrante par le WAN. Tu es obligé de faire ça parce que si tu sors par le VPN, alors l'adresse source des paquets n'est pas l'adresse sur le WAN, et c'est ce qu'un client attend...
Franchement, je ne vois pas comment résoudre ce problème.
Si ton hote source sur internet a une ip fixe, tu peux t'en servir pour l'identifier dans ton routage.
Si dynamique, tu peux éventuellement identifier un port fixe si il se connecte toujours sur le même service (par exemple ssh).
Actuellement :
Si IP source = Server 1 => utiliser VPN
Tu rajoutes une règle (lordre est important) :
Si IP Dest = IP Publique identifiée => utiliser WAN (OU Si port source Serveur 1 = SSH (par exemple) => utiliser WAN )
Si IP source = Server 1 => utiliser VPN
Est-ce possible sur EdgeRouter, par contre je n'en sais rien :P mais sur certain routeur (Cisco) c'est possible.
-
Tu ajoute une 2eme ip locale a serveur1 qui sortira via le NAT du wan et qui servira a le joindre depuis Internet sur les ports que tu ouvriras sur ce NAT. il suffit que cette 2eme ip ne soit pas dans le groupe "VPN_address".
-
Tu ajoute une 2eme ip locale a serveur1 qui sortira via le NAT du wan et qui servira a le joindre depuis Internet sur les ports que tu ouvriras sur ce NAT. il suffit que cette 2eme ip ne soit pas dans le groupe "VPN_address".
Plus propre ;D
-
Malheureusement ce fameux Serveur 1 est un vieux NAS et il n'est pas possible de configurer une autre adresse IP.
Les connexions entrantes peuvent arriver de n'importe quelle IP.
Je vais voir ce que j'arrive à obtenir avec des règles sur les ports, mais je ne vois pas vraiment comment m'y prendre.
Imaginons que ce soit du SSH. On est d'accord la connexion va s'initialiser depuis le WAN sur le port 22.
Mais une fois que le serveur aura reçu la demande de connexion, il va choisir un port aléatoire non ? Et du coup je ne pourrais pas savoir quelle port de sortie filtrer.
Arrêtez-moi si je me trompe.
-
Imaginons que ce soit du SSH. On est d'accord la connexion va s'initialiser depuis le WAN sur le port 22.
Mais une fois que le serveur aura reçu la demande de connexion, il va choisir un port aléatoire non ? Et du coup je ne pourrais pas savoir quelle port de sortie filtrer.
Arrêtez-moi si je me trompe.
non le serveur aura toujours 22 de son coté. c'est le client distant qui choisi un port éphémère aléatoire pour recevoir les paquets.
coté serveur: source port=22, destination port = X (sens sortant du serveur, entrant dans le port lan du routeur)
coté client: source port=X , destination port = 22 (sens sortant du client, entrant dans le port wan du routeur)
donc tu peux imposer que le traffic 22 passe par WAN et pas par le VPN mais dans ce cas tu ne pourra pas ssh depuis le VPN.
il faut exclure "source port = 22" de VPN_address ou n'y mettre que les ports qui doivent passer par le vpn (c'est surement plus simple).
Avoir l'access ssh a la fois depuis wan et depuis le vpn n'est pas possible ... sauf avec peut-etre du double NAT ou si on considere une config dual wan (le vpn étant vu comme un 2eme wan) avec load balancing et sticky sessions (mais je ne sais pas si on peut faire un group de load balance avec un port physique et un port vpn ...). a méditer. sinon tu mets un autre routeur devant serveur1.
-
Ça fonctionne merci beaucoup ;D
Je me suis un peu embrouillé l'esprit avec cette histoire de port mais c'est bon j'ai compris.
J'ai créé un groupe de port contenant les ports ouverts vers des machines étant derrière le VPN.
Puis j'ai créé une règle indiquant que les ports source contenu dans cette liste ne doivent pas passer par le VPN. Et ça fonctionne, je peux accéder aux services sans problème.
Voila un aperçu de la règle si ca peut en aider certain:
modify OPENVPN_ROUTE {
rule 10 {
action modify
description "via vpn"
destination {
group {
address-group !no_VPN_destination
}
}
modify {
table 1
}
source {
address ""
group {
address-group VPN_address
port-group !no_VPN_port
}
}
}
}
Quand je suis connecté à mon réseau en VPN, ça fonctionne quand même. Grace au NAT loopback je suppose.
Après il faut savoir que quand je suis connecté à mon client VPN, le trafic n'est pas redirigé vers la passerelle VPN mais vers le WAN. Ça change peut être la donne.
En tout cas merci encore de votre aide ;D