Salut,
J'ai fait l'acquisition d'un bloc d'IP vrack qui fonctionne correctement avec 2 noeuds proxmox.
L'idée était de mettre en pfsense sur un noeud proxmox en amont des autres serveurs, mais il s'avère que c'est impossible.
Je m'explique, le pfsense a une IP publique dans le VRACK et une IP privée sur une autre interface vers un autre serveur du proxmox, les pings passent très bien, les communications ssh en interne (LAN) aussi.
Premier constat, le serveur interne disons 192.168.1.10 avec pour GW le pfsense en 192.168.7.2 ne peut que faire des pings vers l'extérieur, l'UDP passe mais pas le TCP, ainsi impossible de faire un apt-get par exemple.
De l'extérieur je me connecte parfaitement à l'IP publique du pfsense en SSH. mais si je tente une redirection de port vers mon serveur interne je vois les paquets arriver, mais il semble que la liaison ne se fasse pas, ce n'est pas vrai si je ping, j'ai bien une réponse là encore qui provient bien de mon serveur interne!!!
Si jamais quelqu'un a déjà pu essayer ce type de conf merci...
VRACK + proxmox-pfsense = TCP impossible
Related questions
- IP LB : Création infra multi DC
7922
25.12.2017 14:32
- Routage - Vpn IPsec + vrack + public cloud + serveur dédié
7474
04.06.2017 10:02
- IPLB Graphiques
7184
15.03.2018 17:23
- IP LB NextGen Multi DC
7157
10.02.2017 09:42
- Sonde http IPLB Nextgen
6681
02.11.2016 12:09
- Firewall compatible ipv6
6535
13.03.2017 11:12
- Nbr de règles sur le parefeu OVH
6334
22.11.2019 08:36
- Iplb http 503 pour 100% des requetes
6334
11.01.2018 16:51
- Activer firewall
6257
29.11.2022 08:08
Ça ne serait pas plutôt l'inverse (une interface réseau avec l'IP publique connectée à Internet et une autre avec l'IP privée connectée au vrack) ?
T'es sûr que que ça passe en UDP mais pas en TCP ? Comment fais-tu pour le vérifier ?
Du reste, d'après ce que tu décris, ça me ferait penser à un problème dans la configuration des règles iptables. Tu pourrais détailler les règles que tu as définies ?
Bonjour,
Non, le VRACK n'a que des IP publiques, le noeud proxmox en a une, le pfsense aussi, ils ont la même passerelle, jusque là tout fonctionne bien. le proxmox a ensuite d'autres interfaces avec des LAN, le pfsense a une interface avec un de ces LAN en 192.168.7.0/24
Disons que non ce n'est pas certains que l'UDP passe, je n'ai fait de tests qu'avec ICMP qui passe bien et répond, depuis mon serveur 192.168.7.11 qui a le pfsense en passerelle (192.168.7.2) je peux faire un ping de 8.8.8.8 et inversement, lorsque je suis à l'extérieur chez moi par exemple je peux faire un ping de l'IP publique du pfsense qui redirige bien l'ICMP sur le serveur 192.168.7.11 puisqu'en faisant un tcpdump sur ce dernier je vois les paquets arriver et j'ai bien une réponse sur ma machine extérieure de ce dernier.
J'aimerais que ce soit ça oui, mais je ne vois pas pourquoi j'ai la même conf sur un autre pfsense qui n'est pas dans le Vrack mais a une IP publique isolée et ça marche très bien.
[2.4.3-RELEASE][root@1ha.overlaps.fr]/root:ha.overlaps.fr]/root: pfctl -sr
scrub on vtnet0 all fragment reassemble
scrub on vtnet1 all fragment reassemble
anchor "relayd/*" all
anchor "openvpn/*" all
anchor "ipsec/*" all
pass in quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
block drop in log quick inet6 all label "Block all IPv6"
block drop out log quick inet6 all label "Block all IPv6"
block drop in log quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local"
block drop in log quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"
block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"
block drop in log inet6 all label "Default deny rule IPv6"
block drop out log inet6 all label "Default deny rule IPv6"
block drop log quick inet proto tcp from any port = 0 to any label "Block traffic from port 0"
block drop log quick inet proto udp from any port = 0 to any label "Block traffic from port 0"
block drop log quick inet proto tcp from any to any port = 0 label "Block traffic to port 0"
block drop log quick inet proto udp from any to any port = 0 label "Block traffic to port 0"
block drop log quick from to any label "Block snort2c hosts"
block drop log quick from any to label "Block snort2c hosts"
block drop in log quick proto carp from (self) to any
pass quick proto carp all no state
block drop in log quick proto tcp from to (self) port = ssh label "sshlockout"
block drop in log quick proto tcp from to (self) port = http label "webConfiguratorlockout"
block drop in log quick from to any label "virusprot overload table"
block drop in log quick on vtnet0 from to any label "block bogon IPv4 networks from WAN"
block drop in log on ! vtnet0 inet from 147.A.X.R/27 to any
block drop in log inet from 147.A.X.P1 to any
block drop in log inet from 147.A.X.P2 to any
block drop in log on vtnet0 inet6 from fe80::845b:a4ff:fe19:3773 to any
block drop in log quick on vtnet1 from to any label "block bogon IPv4 networks from LAN"
block drop in log on ! vtnet1 inet from 192.168.7.0/24 to any
block drop in log inet from 192.168.7.2 to any
block drop in log on vtnet1 inet6 from fe80::e0ee:a4ff:fee2:59d8 to any
pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out route-to (vtnet0 147.A.X.Z) inet from 147.A.X.P1 to ! 147.A.X.R/27 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (vtnet0 147.A.X.Z) inet from 147.A.X.P2 to ! 147.A.X.R/27 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass in quick on vtnet1 proto tcp from any to (vtnet1) port = http flags S/SA keep state label "anti-lockout rule"
pass in quick on vtnet1 proto tcp from any to (vtnet1) port = ssh flags S/SA keep state label "anti-lockout rule"
anchor "userrules/*" all
pass in log quick on vtnet0 reply-to (vtnet0 147.A.X.Z) inet proto tcp from any to 192.168.7.0/24 flags S/SA keep state label "USER_RULE: Everything TCP to LAN"
pass in log quick on vtnet0 reply-to (vtnet0 147.A.X.Z) inet proto udp from any to 192.168.7.0/24 keep state label "USER_RULE: Everything TCP to LAN"
pass in log quick on vtnet0 reply-to (vtnet0 147.A.X.Z) inet proto icmp from any to 192.168.7.0/24 keep state label "USER_RULE: Ping to LAN"
pass in quick on vtnet0 reply-to (vtnet0 147.A.X.Z) inet proto tcp from any to 147.A.X.Y port = http flags S/SA keep state label "USER_RULE: HTTP to pfsense-ha"
pass in quick on vtnet0 reply-to (vtnet0 147.A.X.Z) inet proto tcp from any to 147.A.X.Y port = ssh flags S/SA keep state label "USER_RULE: SSH to pfsense-ha"
pass in quick on vtnet1 inet from 192.168.7.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
anchor "tftp-proxy/*" all
Ah, j'avais oublié que tout ça tourne sous Proxmox (ton serveur interne et ton pfsense sont donc 2 VM qui communiquent à travers un LAN Proxmox).
Par curiosité, quel est l'intérêt d'utiliser un vrack avec un bloc d'IP publiques ?
Si ça passe en ICMP dans les deux sens mais pas en TCP (et peut-être pas en UDP) ça ne serait donc pas un problème de NAT à priori — mais je ne suis pas familier d'ipfilter donc je ne peux pas trop juger des règles que tu as configurées.
T'as pensé à regarder du côté du firewall OVH associé à l'instance ?
icmp est un protocole différent de tcp et udp, non?
Non, j'ignorais qu'il y avait un pare-feu OVH!!! Je vais jeter un oeil...
C'est d'avoir une architecture HA derrière, avec 2 noeuds proxmox, ainsi un pfsense qui a une IP du vrack et qui bascule d'un noeud à l'autre en cas de pb sytème reste joignable puisque l'IP ne bouge pas et la passerelle non plus