Archives par étiquette : iptables

Vmware Server, NAT et PPTP

L’objectif

Un ami m’a soumis la problématique suivante: Il souhaite louer un serveur hébergé chez OVH (donc avec une seule interface réseau) avec vmware server pour héberger plusieurs machines virtuelles, dont une devant faire office de serveur pptp. Il comptait s’appuyer sur le « NAT Networking » de vmware server pour gérer la translation d’adresses, ce qui ne pose pas de problèmes pour le port TCP/1723 (PPTP) mais ne fonctionne pas avec le protocole 47 (GRE).
La solution est simple: Linux sachant parfaitement remplir ce rôle, il suffit de lui confier et de reléguer le « vm network » sur une interface virtuelle.

Voici donc un guide pas à pas concernant vmware server 2.0 sur une Debian 5.0.2.
Les paramètres sont les suivants:

  • IP « publique » de l’hôte: 192.168.3.1 (oui je sais, c’est une maquette)
  • Réseau privé: 172.16.0.0/24
  • IP privée de l’hôte: 172.16.0.1
  • IP serveur virtuel PPTP: 172.16.0.2

Ajout de l’interface virtuelle tap1

Installer le paquet contenant le binaire tunctl

apt-get install uml-utilities

Ajouter dans /etc/network/interfaces:

auto tap1
iface tap1 inet static
       pre-up tunctl -u root -t tap1
       pre-up ifconfig tap1 up
       post-down tunctl -d tap1
       address 172.16.0.1
       netmask 255.255.255.0

puis activer tap1

ifup tap1

vérifier le tout

#ifconfig tap1
tap1      Link encap:Ethernet  HWaddr 00:ff:c0:7f:c8:83
          inet adr:172.16.0.1  Bcast:172.16.0.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:3805 overruns:0 carrier:0
          collisions:0 lg file transmission:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Configuration vmware

Nous avons donc une nouvelle interface réseau, nous allons maintenant dire à vmware server de se « bridger » sur cette interface, et non pas une autre.
Pour cela, lancer la commande

vmware-config.pl

et modifier la partie concernant les bridges, soit en ajoutant un nouveau brigde, soit en modifiant le bridge actuel pour qu’il utilise tap1. Dans notre cas, la deuxième solution semble la plus appropriée, les vm n’ayant plus à être connectées directements via l’interface « publique ».
Les machines virtuelles peut maintenant être connectées à ce bridge, et se voir affecter une adresse IP en 172.16.0.x avec comme passerelle 172.16.0.1

Configuration iptables

Désormais, il n’y a plus qu’à paramétrer netfilter afin qu’il route correctement les paquets pptp.
Tout d’abord on active le routage:

echo 1 > /proc/sys/net/ipv4/ip_forward

Puis on natte le réseau privé:

iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -j  MASQUERADE

En renvoyant le port pptp et le protocole GRE vers notre VM:

iptables -t nat -A PREROUTING -d 192.168.3.9 -p 47 -j DNAT --to-destination 172.16.0.2
iptables -t nat -A PREROUTING -d 192.168.3.9 -p tcp --dport 1723 -j DNAT --to-destination 172.16.0.2

Si ça ne fonctionne pas, penser à charger le module « Netfilter NAT helper module for PPTP »:

modprobe nf_nat_pptp

Conclusion

Cette astuce peut-être appliquée dans d’autres cas, par exemple pour simplement profiter de réseaux virtuels supplémentaires avec vmware server (ou encore kvm), ces réseaux contenant l’hôte et les invités.

Rediriger un port avec iptables et ssh

Une petite démonstration de la puissance et de la souplesse de Linux :

Le contexte

Suite à un déménagement, ma connexion ADSL tardait à revenir, et mes mails commençaient à s’entasser sur un MX secondaire herbegé par un ami. Ne voulant pas attendre, je me décidais à utiliser une connexion internet RTC pour rapatrier mon courrier, mais je ne voulais pas modifier la configuration du serveur mail distant. De plus, l’adresse IP de la connexion RTC n’étant pas fixe, cela m’aurait obligé à modifier cette configuration à chaque connexion.

La solution

mxsecondaire essayait de se connecter à mxprincipal (dont l’ancienne IP fixe était A.A.A.A) de façon régulière.
Il fallait donc arriver à détourner de trafic de mxsecondaire à destination de mxprincipal:25 pour l’amener à bon port.

La solution consistait donc à:

  • Connecter mxprincipal à internet via un windows XP qui possédait un modem RTC
  • Ouvrir une session ssh de mxprincipal sur mxsecondaire, en activant le forward de ports de mxsecondaire:65000 vers mxprimaire:25
  • Sur mxsecondaire, détourner le trafic sortant vers A.A.A.A:25 et le renvoyer vers 127.0.0.1:65000
  • Attendre une saisie de l’utilisateur pour remettre tout correctement en place et se déconnecter

LA ligne de commande

Evidemment, en bon linuxien, il fallait que tout cela se fasse en une seule ligne de commande, lancée depuis mxprimaire

ssh mxsecondaire -R 65000:localhost:25 "iptables -A OUTPUT -t nat -p tcp -d A.A.A.A 
--dport 25 -j DNAT --to 127.0.0.1:65000 &&  echo "Appuyer sur entrée pour quitter" && 
read && iptables -D OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000"

Petite explication de texte:

ssh mxsecondaire -R 65000:localhost:25

On se connecte en ssh de mxprimaire vers mxsecondaire, en activant le forward du port 65000 distant vers le port 25 local, et en executant la commande indiquée après. Une fois l’éxécution de celle-ci terminée, la connexion ssh est fermée.

iptables -A OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000 

On dit au noyau de rediriger tout le traffic sortant à destination de A.A.A.A:25 vers le port 65000

echo "Appuyer sur entrée pour quitter" && read 

On attend l’appui sur entrée pour continuer (le temps que les emails soient rapatriés)

iptables -D OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000

On annule ce qui a été fait auparavant

Et voilà… En espérant que ça en inspirera d’autres.

OpenWRT to Zywall VPN

Here is how I configured my Linksys WRT54G routeur/AP to connect to my office’s Zywall 70

              --------                  --------
      Home --| WRT54G |--- Internet ---| Zywall |--- Office
              --------                  --------                
192.168.3.X         W.W.W.W          Z.Z.Z.Z          192.168.2.x

Linksys WRT54G

Backup your access point, go to http://openwrt.org, read carefully the wiki, and install the latest OpenWRT release. WhiteRussian RC6 worked for me.

I upgraded from an old Alchemy release, and all my settings were kept.

Install openswan

#ipkg update
#ipkg install openswan

Create /etc/ipsec.d/private/zywall

conn zywall
       right=%defaultroute
       rightsubnet=192.168.3.0/24
       rightid=@someid
       left=Z.Z.Z.Z
       leftsubnet=192.168.2.0/24
       leftid=@someid
       authby=secret
       pfs=no
       ike=aes128-sha1-modp1024
       esp=3des-md5-96
       keylife=9600s
       keyingtries=0
       auto=add
       dpddelay=30

Modify /etc/ipsec.conf to include your new config

# Add connections here
include /etc/ipsec.d/private/zywall

Add you preshared key in /etc/ipsec.secrets

@someid @someid: PSK "mysecret"

Zywall 70

Open « VPN Rule (IKE) » tab and add a new gateway policy

  • Remote Gateway Address : W.W.W.W
  • Pre-Shared Key : mysecret
  • Negotiation Mode : Main
  • Encryption Algorithm: AES
  • Authentication Algorithm : SHA1
  • SA Life Time (Seconds): 9600
  • Key Group : DH2

Add a new network policy

  • Active: Yes
  • Local Network
    • Address Type: Subnet address
    • Starting IP Address: 192.168.2.0
    • Subnet Mask: 255.255.255.0
  • Remote Network
    • Address Type: Subnet address
    • Starting IP Address: 192.168.3.0
    • Subnet Mask: 255.255.255.0
  • Encapsulation Mode: Tunnel
  • Active Protocol: ESP
  • Encryption Algorithm : 3DES
  • Authentication Algorithm: MD5
  • SA Life Time (Seconds): 28800
  • Prefect Forward Secrecy: None
  • Enable Replay Detection: Yes

It should now work. Try to connect the VPN from the WRT54G:

# ipsec auto --up zywall
104 "zywall" #26: STATE_MAIN_I1: initiate
003 "zywall" #26: ignoring unknown Vendor ID payload [afcad71368a1f1c96b8696fc7757]
003 "zywall" #26: ignoring unknown Vendor ID payload [625027749d5ab97f5616c1602765cf480a3b7d0b]
106 "zywall" #26: STATE_MAIN_I2: sent MI2, expecting MR2
108 "zywall" #26: STATE_MAIN_I3: sent MI3, expecting MR3
004 "zywall" #26: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
117 "zywall" #27: STATE_QUICK_I1: initiate
004 "zywall" #27: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x595ef372 <0xb540297d xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}

Hiding the personnal network

It works, but my colleagues can now browse my home network. I want to « masquerade » the 192.168.3 subnet, so all connections seems to come from 192.168.203.1 :

                  ---------                  --------
      Home -- (NAT) WRT54G |--- Internet ---| Zywall |--- Office
                  ---------                  --------                
192.168.3.x  192.168.203.x  W.W.W.W   Z.Z.Z.Z          192.168.2.x

Edit /etc/firewall.user :

iptables -t nat -A postrouting_rule -d 192.168.2.0/255.255.255.0 -j SNAT --to 192.168.203.1
iptables -A forwarding_rule -d 192.168.2.0/24 -j ACCEPT

Run /etc/firewall.user to apply theses rules
Modify the ipsec rules to use 192.168.203.x instead of 192.168.3.x

Notes

  • The local and remote ID must be the same
  • 3DES/MD5 is not the most secure cypher for phase 2, but other cyphers does not seem to work
  • See openwrt wiki for encryption and speed
  • This should work with any zywall model and with ipsec-capable Prestige models (652, 662). Some buggy firmwares (Zywall 10) use local and/or remote id instead of « secure gateway address ».