pf & openvpn

[Mephisto]

Bonjour,

Je loue depuis peu un serveur, ou je fais tourner openvpn.

Tout semble fonctionner chez les amis avec qui j'ai monte ca.

Cependant, il reste un probleme de mon cote, sur la configuration de mon firewall pf.

La gateway est egalement le client du vpn.

J'ai imagine que reprendre les regles de mon interface externe et les appliquer a l'interface du vpn suffirait.

Et en effet, mon port ssh est correctement redirige sur la gate

cependant, lorsque j'essais de joindre une machine derriere la gate, la connexion n'aboutie pas...

mon pf.conf :

ext_if="bge0"
int_if="bge1"
vpn_if="tun0"

lc = $int_if:network
 vpn="10.253.254.1"
emma="10.242.42.200"
alpha="10.42.42.42"
delta="10.42.42.44"
  xi="10.42.142.44"

set skip 	on lo0
scrub in 	all
#scrub in 	on $ext_if all fragment reassemble
#scrub in 	on $vpn_if all fragment reassemble
#INTERNETZ
nat      	on $ext_if             	from $lc to any -> ($ext_if)
nat      	on $vpn_if             	from $lc to any -> ($vpn_if)
#EMMA
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port   80 -> $emma  port   80
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port   80 -> $emma  port   80
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 1101 -> $emma  port   22
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 1101 -> $emma  port   22
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 3306 -> $xi	port 3306
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 3306 -> $xi	port 3306
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 8080 -> $emma  port 8080
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 8080 -> $emma  port 8080
#WHAT.CD
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 1666 -> $alpha port 1666
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 1666 -> $alpha port 1666
#GIT
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 1669 -> $xi	port   22
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 1669 -> $xi	port   22
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 9418 -> $xi	port 9418
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 9418 -> $xi	port 9418
#REMOTE ADM
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 1667 -> $delta port   22
rdr      	on $vpn_if inet proto tcp  from any to $vpn  	port 1667 -> $delta port   22
rdr      	on $ext_if inet proto tcp  from any to ($ext_if) port 1668 -> $alpha port   22
rdr      	on $vpn_if inet proto tcp  from any to any   	port 1668 -> $alpha port   22
pass  in 	on $ext_if inet proto tcp  from any to $ext_if   port 53
pass  in 	on $vpn_if inet proto tcp  from any to $vpn_if   port 53
pass  in 	on $ext_if inet proto udp  from any to $ext_if   port 53
pass  in 	on $vpn_if inet proto udp  from any to $vpn_if   port 53
pass  in 	on $ext_if inet proto tcp  from any to $ext_if   port 1664
pass  in 	on $vpn_if inet proto tcp  from any to $vpn_if   port 1664
pass  in 	on $int_if inet proto tcp  from any to any
pass  in 	on $int_if inet proto udp  from any to any
block in log on $ext_if inet proto icmp from any to $ext_if
block in log on $vpn_if inet proto icmp from any to $vpn_if

Quelqu'un voit une erreur ?

[PyKaBoo]

Bonjour à toi,

As-tu essayé d'utiliser un sniffer pour savoir ou les paquets s'arrêtent ? Cela permettrait aussi de voir si tes règles de nattage fonctionnent correctement.

A la limite, si tu peux ajouter les tables de routages des différents hosts...

Bon courage,

[Mephisto]

La réponse qu'on m'a donné sur la ML FreeBSD sous-entend qu'il n'est pas possible de faire du scrub sur deux niveaux (si j'ai bien suivi)

J'en suis arrivé à la conclusion que les machines de mon réseau devant être accessible par redirection de port doivent être membre à part entière (certificat+IP) du VPN

la réponse en question:

Im not sure if i understand you correctly but are you trying to forward ports from your colo rented machine to boxes on your LAN via the openvpn connection?

If you are and this is where the problem is, you probably need to be natting on the colo boxes vpn interface (tun0). So you will need some iptables config. Doing this avoids the asymetric routing and natting issue you will be getting.

Basically if a packet enters your colo box (dst ip A) from client (B), your coloe box will forward it down the tunnel to host C on a private ip. This will respond, and create a packet to goto B. However when this packet will have a public ip as a destination, so when it hits your pf firewall it will probably get routed out of the default route, and not the vpn interface. As its not a tcp syn it will most probably be dropped by pf. However if it isnt it will be natted to the the public ip of your pf box. This is a problem as this source address isnt the same as the destination address of the initial packet generated by the client B. Therefore when it actually get to the client it will just be dropped

Natting on the colo boxes vpn interface sorts all this out for you

mon iptables sur le serveur VPN (mode open, tant que j'ai pas fini de tout mettre en place) ressemble à ça

EXT=eth0
VPN=tun0

# see /etc/openvpn/clients.txt to get network addresses of clients
FAUST_HOME=10.253.254.6

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -N external

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i $VPN -j ACCEPT
iptables -A INPUT -i $EXT -j ACCEPT

#ports opening
iptables -A external -i $EXT -p tcp --dport 1668

#EMMA samuel
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 8000 --to-destination $FAUST_HOME:80    	#WEB @emma
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 8000 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1101 --to-destination $FAUST_HOME:1101  	#SSH @emma
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1101 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 3306 --to-destination $FAUST_HOME:3306  	#MYSQL @xi
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 3306 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 8080 --to-destination $FAUST_HOME:8080  	#RWEB @emma
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 8080 -d $FAUST_HOME

#WHAT.CD samuel
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1666 --to-destination $FAUST_HOME:1666  	#TORRENT @alpha
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1666 -d $FAUST_HOME

#GIT piwi
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1669 --to-destination $FAUST_HOME:1669  	#SSH @xi
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1669 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 9418 --to-destination $FAUST_HOME:9418  	#GIT @xi
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 9418 -d $FAUST_HOME

#REMOTE ADMIN samuel
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1664 --to-destination $FAUST_HOME:1664  	#SSH @psi
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1664 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1667 --to-destination $FAUST_HOME:1667  	#SSH @delta
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1667 -d $FAUST_HOME
iptables -t nat -A PREROUTING  -j DNAT   	-i $EXT -p tcp --dport 1668 --to-destination $FAUST_HOME:1668  	#SSH @alpha
iptables -t nat -A POSTROUTING -j MASQUERADE -o $VPN -p tcp --dport 1668 -d $FAUST_HOME

iptables -t nat -A POSTROUTING -j MASQUERADE -o $EXT
#iptables    	-A POSTROUTING --table nat -o $EXT -j MASQUERADE

[PyKaBoo]

Bonsoir,

Si je comprend le sens de sa réponse, il serait plutôt en train d'expliquer qu'il faut que pour que ta règle de nattage fonctionne, il faut que les réponses à tes requêtes ssh soient correctement routées. Effectivement, pour que le nattage fonctionne, il faut que le flux ne soit pas asymétrique, la question et la réponse doivent passer par le pf.

Il te manque p-e simplement une route statique pour forcer la réponse en retour vers le tunnel.

Comme je te l'ai conseillé précédemment, un sniffer sur les machines destinations et vérification des tables de routage pourrait te rendre service.