pfSense Support Subscription

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - chris4916

Pages: [1]
1
CARP/VIPs / CARP with multi-wan [SOLVED]
« on: November 08, 2017, 02:26:20 pm »
I'm trying to configure CARP with multi-wan and can't figure out what I'm making wrong but, basically, it doesn't work as expected.



Modem                             Modem 1                              Modem 2           
mode                               PPPoE                                   PPPoE           
public IP                       xxx.xxx.xxx.xxx                   yyy.yyy.yyy.yyy           
IP (internal side)         192.168.253.14/29           192.168.253.6/29           
forward to                   192.168.253.9/29             192.168.253.1/29


pfSense                             igb0                                   igb1                                   igb2                           igb3                             igb5
interface                            WAN1                                 WAN2                               LAN                            DMZ                             SYNC
WAN master                  192.168.253.10/29           192.168.253.2/29        192.168.0.252/24        192.168.200.252         192.168.253.17/29
WAN slave                     192.168.253.11/29           192.168.253.3/29        192.168.0.253/24        192.168.200.253         192.168.253.18/29
VIP                                 192.168.253.9/29             192.168.253.1/29       192.168.0.254/24         192.168.200.254/24            none
WHID                                   2                                           1                                      3                                 4                              none
dft GW                           192.168.253.14                192.168.253.6                       none                          none                             none

WAN1 & WAN2 are both member of "WAN" group, both tier-1, none is designed as "default gateway"
WAN is configured as gateway in all rules at LAN interface level when flow is reaching internet. This works fine.

CARP itself is almost OK (some problems with DHCP because some clients receive DHCP offer from each DHCP server with different IP) but the real problem I'm facing is with in-coming flow.

If I try to reach internal mail server from internet using modem 1 public IP, this works.
When I try to reach same server using modem 2 public IP, I can see packets reaching WAN2, even going out from LAN to mail server but it looks like packets are back using route through VIP with WHID 2 instead of WHID 1.

I did read this https://doc.pfsense.org/index.php/Bypassing_Policy_Routing and applied it without any success. (and I don't understand how this applies to non-local IPs)
I also have multiple IPsec tunnels, for the time being hardcoded to connect to either WAN1 or WAN2, depending on remote network and this works fine (yes I'm facing the issue with IPSec status preventing to display is correctly).

I, of course, changed outbound NAT rules, in manual mode, to target WAN VIPs

Well, I'm quite confused.
I feel this is related to routing, perhaps bypass policy but I've to admit that, for the time being, I'm lost with poor understanding (and not real capability to closely investigate because, to make it worst, I'm configuring everything remotely through OpenVPN access  ;D ;D ;D :o

Any idea?

2
Upgrade to 2.3 is bringing some surprises  ;)

One is that system.log contains something that looks to be inconsistent:

Quote
Apr 13 07:37:14    php-fpm    7554    /rc.newipsecdns: MONITOR: WAN_HA is down, omitting from routing group WAN_DHCP
Apr 13 07:37:14    php-fpm    7554    /rc.newipsecdns: Default gateway down setting WAN2_DHCP as default!

This looks ok but when checking configuration, group is WAN_HA and gateway is WAN_DHCP, not the opposite as shown here.

Editing and saving gateway group doesn't fix it.

So far, this is only cosmetic , I suppose ;)

3
webGUI / php-fpm crash
« on: February 19, 2016, 05:11:56 am »
I'm not really sure this is the right section to address this point.
Feel free to tell me if I'm wrong.

I'm facing an issue since couple of days with php-fpm crashing almost very day.

I need to relaunch WebGUI using option 16 in console menu.

ligthhpd.error.log contains lot of entries with:

Code: [Select]
lighttpd.error.log:2016-02-16 17:35:03: (mod_fastcgi.c.2673) fcgi-server re-enabled: unix:/var/run/php-fpm.socket
lighttpd.error.log:2016-02-16 17:35:04: (mod_fastcgi.c.1744) connect failed: Connection refused on unix:/var/run/php-fpm.socket

and

Code: [Select]
lighttpd.error.log:2016-02-16 18:08:41: (mod_fastcgi.c.2390) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/var/run/php-fpm.socket
lighttpd.error.log:2016-02-16 18:08:41: (mod_fastcgi.c.3171) response not received, request sent: 498 on socket: unix:/var/run/php-fpm.socket for /index.php?, closing connection


It looks like (but I'm not 100% sure that I started to face this issue once I configured OpenVPN server and connected with VPN client.

How can I investigate further and fix this?
Any idea?

4
Hi folks,

I plan to migrate from another platform currently acting as OpenVPN server to pfSense.
Current platform stores few hundreds of accounts with certificates thus my goal is obviously not to create and distribute these certificates again. This would make migration quite painful.
So I'm trying to import existing certificates  8)

Importing CA works seamlessly but importing users certificate fails with error message:
"This certificate does not appear to be valid."

I suspect this could be due to missing attribute like Organization or country but there is nothing obvious in logs (at leas for what is accessible from GUI. I'll check further at system level).

If my assumption is correct, do you think it would be realistic to tweak OpenSSL conf so that such certificates can be imported and used by clients ?

5
Français / Fonctionnement de la section "française" du forum pfSense
« on: October 19, 2015, 09:15:14 am »
Afin de ne pas polluer inutilement ce fil, mais comme je tiens à m'exprimer sur le sujet, j'ouvre ici un nouveau fil afin que chacun puisse s'exprimer  ;)

L'initiative de mettre à disposition des membres du forum un modèle afin de structurer les demandes d'assistance est une très bonne idée.
fortement encourager les membres à l'utiliser est également une démarche pleine de bon sens.

En revanche, rendre l'utilisation de ce "formulaire" obligatoire, avec pour conséquence d'avoir un mode de fonctionnement dans la section française différent du reste du forum pfSense me parait pour le moins surprenant.

Cette initiative, si je lis bien ce qui est publié ici, date d'il y a à peine plus d'un an, suite à cette discussion et probablement quelques échanges de messages privés.
Cela partait sur de bonnes bases et ton attitude (@jdh) de ne pas répondre à ceux qui n'utiliseraient pas de formulaire était respectable:

Quote from: jdh
En tout état de cause, dès que ce formulaire serait fortement recommandé, je refuserai de répondre à une demande ne respectant pas cela, et j'encourage à en faire autant !   


mais j'ai l'impression, à lire ton dernier message:
Quote from: jdh
Tout cela été validé par tout le monde ...
Merci d'être solidaire de TOUT le monde sur ce point !

Que nous sommes passé de:
"je ne répondrai pas si il n'y a pas de formulaire"
à
"ne pas répondre si il n'y a pas de formulaire !"

Même si je comprends ta frustration lorsque quelqu'un commence à répondre alors que tu souhaites imposer la loi du formulaire, je ne partage pas cette position, bien que je sois tout à fait favorable à l'utilisation de ce document.

Le reste du forum pfSense fonctionne sur un mode "de bon sens" sans nécessiter ce dictat. Si un membre pose une question sans prendre la peine, malgré les demandes, de fournir des explications claires, la communauté ignore rapidement son message. La régulation se fait d'elle même.

Comme je l'ai déjà écrit plusieurs fois, si le souhait, dans la section française, est d'avoir ce mode de fonctionnement, il est beaucoup plus efficace de demander à ce que question ET réponses soient modérées. Demande à être promu modérateur et tu pourras:
- rejeter les questions qui ne correspondent pas à la charte.
- bloquer les réponses qui ne méritent pas d'être publiées.

Parce que je suis un peu taquin, je suis quand même intéressé à savoir qui est "TOUT le monde" auquel tu fais référence.
Je ne peux bien sûr pas présumer de l'étendue de la discussion par message privé mais sur la partie publique au sujet de la proposition de Tatave, il y a 3 intervenants, sans compter le modérateur qui a créé le sticky  ::)

Encore une fois: l'initiative est louable et le formulaire très utile.
Le passage de "vous devriez utiliser ce formulaire..." à "pas de réponse sans formulaire et merci aux autres de respecter cette règle !" me semble plus que discutable.

C'est tout l'objet de ce post  ;)

6
DHCP and DNS / Split DNS / horizon
« on: May 14, 2015, 03:32:08 am »
Something I'd like to share with you and get your opinion:

As we were discussing this feature in the French section of this forum, I decided to have a closer look at documentation  8)
DNS Forwarder and  Unbound both provide override capability, which means that for internal users, pfSense DNS can return different IP but this is, to me, only very partial split DNS implementation.

Dnsmasq could provide something closer to split horizon when using localise-queries option but I can't see such option in GUI (for DNS Forwarder.

pfSense documentation explains "split DNS" with the override example, which I find to be slightly misleading, at least without some comments to explain that this is only very partial implementation of what is a true split DNS.

Is my view truncated / biased or do you share my comment. In such case, would it make sense to ask for documentation adjustment ?

7
Français / pfSense DNS / split horizon
« on: May 14, 2015, 03:00:41 am »
Suite au point évoqué dans ce fil, et plus particulière sur l'aspect "split DNS"
Quote from: ccnet
La solution s'appelle split horizon. Du classique. Pfsense vous permet de gérer cela.
je me suis livré à quelques recherches car le sujet m'intéresse.
Mon infrastructure s'appuie sur un DNS qui n'est pas celui de pfSense et une meilleure compréhension du fonctionnement de celui me permettrait peut-être de simplifier l'ensemble.

Pour mieux comprendre la suite, je rappelle que l'objectif du split DNS, ou split horizon consiste à fournir au client du service DNS une réponse qui dépend de l'adresse source du client.
Cela permet de faire des vues  du même DNS et de soit cacher des adresses IP soit renvoyer une IP adaptée au client.
par exemple le DNS contient des adresses IP pour des machines situées sur une DMZ mais seules quelques unes sont supposées être accessibles aux clients DNS qui sont sur cette DMZ. Avec un split DNS, tout en maintenant un seul serveur DNS, on ne va pas renvoyer d'adresse pour les machines qui ne sont pas supposées être joignables.

Pour le moment, à la lecture des différents documents trouvés sur le site de pfSense et quelques fils dans le forum, ma compréhension est la suivante:
- les différents services DNS de pfSense ne permettent pas de faire ce genre de chose. Que ce soit "DNS forwarder" qui se base sur dnsmasq ou "DNS resolver" qui se base sur Unbound, il est uniquement possible de réécrire l'adresse IP par rapport à ce qui serait maintenu sur un autre DNS et d'intercaler le DNS de pfSense pour que celui-ci prenne la priorité.

La doc de pfSense est très claire de ce point de vue, même si la terminologie utilisée est confusante (misleading)
- DNS Forwarder
- DNS Resolver

Dans ce document, la doc explique:
Quote
Method 2: Split DNS

The more elegant solution to this problem involves using Split DNS. Basically this means that internal and external clients resolve hostnames differently.

Internal clients would access resources by hostname, not IP, and clients on the local network would resolve that hostname to the LAN IP address of the actual server, and not the WAN IP as others outside the network would see.

In order for this to work using the DNS forwarder in pfSense, clients will need to have the IP Address of the pfSense router as their primary DNS server.

Example:

    www.example.com resolves to public IP 1.2.3.4, which is the WAN IP
    Forward port 80 on 1.2.3.4 to port 80 on 192.168.1.5
    Override www.example.com using System > DNS Forwarder and point www.example.com to 192.168.1.5
        Another internal DNS mechanism could also be used to enact the override.

la phrase
Quote
The more elegant solution to this problem involves using Split DNS. Basically this means that internal and external clients resolve hostnames differently.
bien que exacte, est incomplète.
Elle devrait plutôt être:
Quote
Basically this means that internal and external clients resolve hostnames differently assuming external clients use another DNS.

Il est très clair qu'il ne s'agit pas d'un split (au sens généralement admis du terme) mais d'une réécriture de l'adresse IP, et donc la nécessité de gérer un autre DNS.
La documentation pfSense précise que le son DNS (voir le lien relatif à DNS Forwarder) ne doit répondre qu'à des clients internes et ne jamais être exposé sur le web.

A noter que DNS Resolver permet de mettre en place des ACL, ce qui offre un contrôle sur "qui" est autorisé à faire des requêtes DNS mais ce n'est quand même pas du split DNS et donc je vais rester avec mon DNS actuel au moins jusqu'à ce que ma compréhension évolue  :)

En attendant, je vais écrire à ceux qui maintiennent la doc pour suggérer quelques ajustements  ;D

Pour être plus précis dans mon analyse: dnsmasq permet, grâce à l'option "-y, --localise-queries" de renvoyer une adresse IP en fonction de l'interface qu client DNS mais je ne vois pas de moyen d'utiliser cette option dans l’implémentation qu'en fait pfSense.

8
Français / Choix d'implémentaiton de FTP derrière un FW
« on: May 13, 2015, 01:49:03 am »
Suite à notre échange sur le non fonctionnement de FTP, voici une représentation graphique qui pourrait vous aider à prendre une décision.
Les 4 diagrammes montrent respectivement
- FTP actif sans firewall
- FTP passif sans FW
- FTP actif avec FW (SPI)
- FTP passif avec FW (SPI)

j'ai mis des ports au hasard coté client et serveur.
- coté client, le port data (flèches vertes) est normalement "port commande +1"
- coté serveur, en mode passif, le port data est un port random > 1023 mais certain serveurs FTP permettent de réduire le range de ce port. la taille du range ayant un impact direct sur le nombre de connexions simultanées possibles.

En mode actif:
la connexion est à l'initiative du client  ;) pour la partie commande (flèches rouges) mais c'est ensuite le serveur qui établi une session sur un port random du client  :o
sur le schéma ça fonctionne mais si le client ne dispose pas d'une adresse IP publique, ça ne marche pas tout seul. C'est potentiellement compliqué en terme de NAT (car FTP requière 2 sessions différentes)

En mode passif:
le client établi les connexions, à la fois pour la partie commande et data.
Il faut noter que le mode passif est le mode de repli (normalement) obligatoire si le mode actif ne fonctionne pas. C'est également le mode noté comme préféré par les clients FTP comme FileZilla.

Dès lors qu'on introduit un FW de type SPI (State-full Packet Inspection), compte tenu du sens d'établissement des connexions, et comme indiqué dans la doc pfSense, coté serveur le mode actif est plus simple à gérer mais il ne fonctionne pas coté client (car bien sûr j'ai lis un FW coté client  ;D)
Coté client le mode passif est plus simple mais il ne fonctionne pas coté serveur.

Il n'y a donc pas de solution simple  ::)

Compte tenu du fait que le mode passif est le mode de repli et qu'il est celui largement promu par les clients FTP, et que par ailleurs, en cas d'hébergement d'un serveur FTP, on ne contrôle souvent pas ce qui se passe coté client (et que le mode actif sera assez probablement bloqué coté client), il conviendrait de privilégier le mode passif, en terme de design car c'est très probablement celui qui va être exécuté.

Comme expliqué succinctement dans le morceau de doc "pfSense", en mode passif, il faut quelques adaptations pour faire un forward vers le serveur et il faut trouver un équilibre entre un grand nombre de connexions et l'ouverture du FW pour cette IP.

Avec un seul serveur FTP, c'est réalisable.
Dès qu'il y a plusieurs serveur FTP hébergés, ça devient plus problématique, un peu à la manière des serveurs web mais avec un degré de compléxité supplémentaire lié à la nature du protocole FTP.

Dans ce cas, il est préférable de se tourner vers des solutions de type reverse proxy.
Il y a de nombreux serveur "reverse proxy FTP" sur le web.

Un exemple ici qui est intéressant car il ne discute pas que de FTP  ;)

I hope this helps  8)

Pages: [1]