[Résolu] Tunnel IPSec perte de connexion lan

Message par **gizmo78** » mer. 22 oct. 2014 10:35

Yop,

Petite question,

Je me suis servis du poste de dsebire pour me faire un tunnel vpn ipsec entre mon serveur chez online et chez moi.

@home j'ai une vm avec une eth en dmz qui me sert de serveur vpn.

Le tunnel se monte bien mais ma vm perd l'accès au lan local oO du coup de mon serveur online je peux pas pinguer ni accéder à mon lan perso.

une idée du soucis?

Coté serveur ipsec.conf
[cpp]# /etc/ipsec.conf - Openswan IPsec configuration file

# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5

version 2.0 # conforms to second version of ipsec.conf specification

# basic configuration
config setup
interfaces=%defaultroute
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!172.16.35.0/24
oe=off
protostack=netkey
plutoopts="--interface=eth0"

# Add connections here

conn NET-TO-NET
authby=secret
pfs=no
rekey=yes
auth=esp
esp=3des-sha1
ike=3des-sha1
ikev2=no
compress=no
keylife=24h
ikelifetime=8h
type=tunnel

left=@ipsrvonline # Local vitals IP locale a la machine = ip publiqe
leftsubnet=0.0.0.0/0 # 172.16.35.0/24
leftid=@ipsrvonline # on utilise l'IP publique comme ID
leftnexthop=%defaultroute
leftsourceip=172.16.35.1

right=@ipfbhome # Remote vitals IP publique distante
rightsubnet=192.168.0.0/24
rightid=@ipfbhome # on s'en fiche un peu, on prend l'IP publique distante
rightnexthop=%defaultroute
rightsourceip=192.168.0.13

auto=start
[/cpp]

mv @home ipsec.conf

[cpp]# /etc/ipsec.conf - Openswan IPsec configuration file

# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5

version 2.0 # conforms to second version of ipsec.conf specification

# basic configuration
config setup
interfaces=%defaultroute
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.0.0/24
oe=off
protostack=netkey
plutoopts="--interface=eth1"

# Add connections here

conn NET-TO-NET
authby=secret
pfs=no
rekey=yes
auth=esp
esp=3des-sha1
ike=3des-sha1
ikev2=no
compress=no
keylife=24h
ikelifetime=8h
type=tunnel

left=192.168.0.13 # Local dmz vitals (IP de la machine, pas publique)
leftsubnet=192.168.0.0/24
leftid=@ipfbhome # on s'en fiche un peu, on met l'IP publique de la machine
leftnexthop=%defaultroute
leftsourceip=192.168.0.13

right=@ipsrvonline # Remote vitals (ici ip de la machine = ip locale
rightsubnet=0.0.0.0/0 # 172.16.35.0/24
rightid=@ipsrvonline
rightnexthop=%defaultroute
rightsourceip=172.16.35.1

auto=start
[/cpp]

merci

Message par **gizmo78** » mer. 22 oct. 2014 10:43

j'allais poster la partie iptables ^^

coté serveur (la partie qui nous intéresse):

[cpp]# IPSEC
iptables -A INPUT -p udp -m udp --dport 1701 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -s 172.16.35.0/24 -j ACCEPT
iptables -A INPUT -s 127.0.0.1/32 -j ACCEPT
iptables -A INPUT -s @ipsrvonline/24 -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 172.16.35.0/24 -j ACCEPT
[/cpp]

coté vm@home:
[cpp]#!/usr/bin/env bash
#Vide les tables
iptables -F
iptables -X

#Strategie par defaut
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

#LOG des paquets
#iptables -A INPUT -j LOG
#iptables -A FORWARD -j LOG
#iptables -A OUTPUT -j LOG

#Creation d'une chaine
iptables -N LOG_REJECT_SMTP
iptables -A LOG_REJECT_SMTP -j LOG --log-prefix ' SMTP REJECT PAQUET : '
iptables -A LOG_REJECT_SMTP -j DROP

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 6 --name ssh --rsource -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name ssh --rsource
iptables -A INPUT -s 61.64.128.0/17 -i eth0 -j LOG_REJECT_SMTP
iptables -A INPUT -s 122.120.0.0/13 -i eth0 -j LOG_REJECT_SMTP
iptables -A INPUT -s 168.95.0.0/16 -i eth0 -j LOG_REJECT_SMTP
iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 1701 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -j ACCEPT
iptables -A FORWARD -s 172.16.35.0/24 -j ACCEPT
iptables -A FORWARD -d 172.16.35.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/24 -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A LOG_REJECT_SMTP -j LOG --log-prefix " SMTP REJECT PAQUET : "
iptables -A LOG_REJECT_SMTP -j DROP
[/cpp]

tout ce qui est drop/anti taiwanais and co est commun aux deux iptables

Message par **dsebire** » mer. 22 oct. 2014 11:00

@home, ta DMZ arrive sur eth1 il me semble ?
et eth0 c'est LAN (meme si a l'arrivée, les 2 sont sur le LAN)

si oui, @home, tu as un souci, faut remplacer tes "-i eth0" par "-i eth1" pour les filtre en entrée ("iptables -A INPUT ......")

il te manque un "iptables -A INPUT -i eth0 -j ACCEPT" pour autoriser le LAN sur eth0

faut que je regarde mais je pense qu'il te manque l'interface de sortie sur les FORWARD vu que tu as 2 interfaces.

Message par **gizmo78** » mer. 22 oct. 2014 11:02

effectivement je m'étais dis qu'il fallait corriger et je l'ai pas fais ^^

j'ai rajouté la nouvelle ligne mais ca change rien

Message par **dsebire** » mer. 22 oct. 2014 11:05

quelle est ta passerelle pour le reseau 172.16.35.0 sur les machines du LAN@home ?

Message par **gizmo78** » mer. 22 oct. 2014 11:07

0.0.0.0 sur eth1 mais ajoutée à la main sinon y en a pas.

edit:

quand je redémarre ipsec j'ai ca comme message: some eroutes exist, du coup faut que je look

Message par **dsebire** » mer. 22 oct. 2014 11:11

je t'ai pas demandé sur la VM mais bien sur les autres machines de ton lan

que donne un tracert 172.16.35.1 a partir d'autre chose que la VM chez toi ?

Message par **gizmo78** » mer. 22 oct. 2014 11:14

ha pardon

alors :
traceroute 172.16.35.1
traceroute to 172.16.35.1 (172.16.35.1), 30 hops max, 60 byte packets
1 192.168.0.254 (192.168.0.254) 1.316 ms 1.567 ms 2.130 ms

du coup il passe pas du tout par la vm, faut que j'y colle une route à la mano non?

Message par **dsebire** » mer. 22 oct. 2014 11:18

192.168.0.254 c'est ta box internet ?

faut lire les tuto bordel !!!

soit tu ajoute une route persistante a la main (solution de goret) soit tu utilise la magnifique option 249 du DHCP (bien sur il faut que tes bécanes soient en DHCP, et mettre les routes statiques que sur celles en IP fixe)

http://smpfr.mesdiscussions.net/smpfr/S ... htm#t23886 a la fin du post

on modifie le serveur DHCP pour qu'il envoie l'option 249 (classless static routes)
l'avantage c'est qu'on peut en mettre autant qu'on veut, doncsi je veux router qqch par OVH, c'est ici que ça se passe
172.16.35.0 / 255.255.255.0 / 192.168.0.254 (ça va router tous les paquets destinés au kimsufi vers la passerelle VPN)

dans ton cas, il faut bien sur remplacer le 192.168.0.254 par une des IP de ta VM (je prendrais plutôt eth1 perso)

Message par **gizmo78** » mer. 22 oct. 2014 11:24

j'avais pas vu ces lignes effectivement

my bad

alors mes vms sont en ip fixe donc je vais modifier et le dhcp et ajouter une route à la main.

du coup pour la route, utiliser 192.168.0.13 et pas eth0 qui a une autre adresse ip?

Message par **gizmo78** » mer. 22 oct. 2014 11:29

route ajoutée sur une vm pour test et ca marche

\o/

me reste à faire ca sur toute et dans le dhcp

Mr Dsebire un grand merci

Message par **kalistyan** » mer. 22 oct. 2014 11:34

Balise [résolu]

Message par **gizmo78** » mer. 22 oct. 2014 11:36

ouaip je l'ajoute quand c'est validé sur plus d'une vm

Message par **dsebire** » mer. 22 oct. 2014 11:36

bon alors, je râle que tu lis pas le tuto, mais j'ai galéré pas mal de temps avant de la trouver

PS: je te l'avais mis dans les MP

Message par **dsebire** » mer. 22 oct. 2014 11:37

PS2: tu peux faire des IP fixes tout en gardant l'avantage du DHCP !
suffit de faire des réservations sur les MAC de tes VM

Message par **gizmo78** » mer. 22 oct. 2014 11:38

me reste à trouver pour le ssh ^^

j'avoue que je fais ca à moitié au taff donc j'ai pas forcément tout suivis dans le super détail :/

edit: dsebire oui oui je sais ^^ et je pense que je vais y venir ^^ ca et saltstack en préparation

Message par **dsebire** » mer. 22 oct. 2014 11:40

PS3: la conf du tunnel, vu que tu as repris la mienne, te permet de faire passer n'importe quoi dedans.
donc si tu veux bypasser ta box (au hasard, free avec con peering en carton vers les US) il te suffit de rajouter (toujours dans l'option 249 de ton DHCP) une nouvelle route genre 8.8.4.4 / 255.255.255.255 / 192.168.0.13 (ce qui fera passer les paquets a destination de 8.8.4.4 dans ta VM donc dans le tunnel et donc par ton dédié en peering)

Message par **dsebire** » mer. 22 oct. 2014 11:41

pour le SSH, j'ai le même pb, mais toi avec tes 2 interfaces, ça devrait être simple.
si tu ssh vers l'IP d'eth0, je pense que ça marche

Message par **gizmo78** » mer. 22 oct. 2014 11:41

ou juste de changer la gw par défaut pour tout faire passer dans le tunnel?

Message par **dsebire** » mer. 22 oct. 2014 11:42

c'est dangereux, si le tunnel tombe, ya plus rien qui marche

perso j'ai choisi de rooter dans le tunnel seulement ce dont j'avais besoin.

Message par **gizmo78** » mer. 22 oct. 2014 11:47

oui je me doute, après je vais faire pareil, le but du jeu c'est pas de tout faire passer mais juste certaines choses.

Message par **dsebire** » mer. 22 oct. 2014 11:54

ya un truc que j'ai pas testé, c'est si tu fait tout passer par la VM et que le tunnel tombe, Est-ce que ça peut router vers la box ????
je pense que oui, si la default GW de la VM est la box.
après, il faudra pt'etre faire des regles iptables "dynamiques" genre ajoutées/retirées quand le tunnel monte ou tombe. et la ça se complique je pense.

Message par **gizmo78** » mer. 22 oct. 2014 12:11

tu fais un script avec un ping sur le vpn et quand ca tombe ca execute ton fichier de iptables.sav et hop tu passe sur la box

sinon, dhcp modifié et validé

je modifie donc le titre \o/

Message par **dsebire** » mer. 22 oct. 2014 14:40

pour info, l'option 249 est dynamique.
a savoir qu'au renouvellement du bail DHCP, si les options ont été ajoutées, elles seront ajoutées à la machine.
par contre, si tu en supprime une, j'ai l'impression que ça ne la retire pas de la machine (ou alors j'ai pas attendu assez longtemps)

du coup, j'ai mis un bail assez court (1h) vu que le retry est a 1/2 de la durée du bail. en gros la mise a jour prend au plus 30mn chez moi.

inconvénient, si le serveur DHCP tombe, j'ai au plus entre 30 et 60mn pour le réparer avant de perdre le réseau

Message par **gizmo78** » mer. 22 oct. 2014 15:00

j'ai une heure aussi

la j'ai mis en place:
- dhcp avec resa d'adresses;
- toute mes vms en dhcp;
- dns avec unbound et redirection;
- le vpn ipsec;

sur mon lan, je tape ping online.home.loc et hop ca part sur le dédié

j'avoue, je suis comme un gosse xD