Version Expert
Je veux créer une route dans pfSense qui enverra le trafic par le port physique WAN, et non par le port PPPoE WAN. Je veux pouvoir communiquer avec le serveur web de mon modem DSL ; me permettant de voir le débit de synchronisation actuel et les marges de Signal sur Bruit (SnR). Le modem ne reçoit pas les paquets destinés à lui car ils sont envoyés à travers le tunnel PPPoE.
Version Longue
Mon routeur pfSense est responsable de mettre en place la connexion PPPoE via DSL avec mon FAI. Lorsqu'une machine sur le LAN souhaite envoyer des paquets vers Internet, la route par défaut envoie les paquets via la connexion PPPoE. Ces paquets, enveloppés dans un en-tête PPPoE, sont envoyés sur le câble Ethernet à mon modem DSL. De là, ils sont envoyés à l'ISP, puis à l'Internet en général.
+----------------------+ +----------------------+
|En-tête IPv4 (20 octets)| +--------+ |En-tête PPPoE (8 octets)| +-----+ {}
| |===>|pfSense |===>|En-tête IPv4 (20 octets)|===>|Modem|===>{Internet}
| | +--------+ | | +-----+ {________}
| | | |
+----------------------+ +----------------------+Je veux pouvoir envoyer un paquet directement par le port WAN lui-même, et non par le port WAN PPPoE.
Mon modem est là-bas, avec une interface http où je peux surveiller
- la vitesse de connexion
- le rapport signal sur bruit
- la bande passante
- le temps de connexion
Chaque fois que j'essaie de définir une route pour une destination de 192.168.2.1 (l'IP à laquelle le modem écoutera pour les requêtes HTTP) pour passer par le WAN, elles finissent par passer par le port PPPoE.
La différence étant qu'ils sont enveloppés dans un paquet de protocole PPPoE, et le modem ne reçoit pas le paquet, il est livré à l'ISP.
Étant donné que pfSense n'a pas la capacité de diriger le trafic vers le port WAN physique: comment puis-je diriger le trafic vers le port WAN physique sur pfSense?
Voici la même question que j'ai posée il y a 3 ans sur le forum pfSense:
Mon modem a une interface web. C'est pratique car je peux voir s'il est réellement connecté, le bruit de la ligne, les taux d'erreur, etc.
Si je connecte le modem à mon PC de bureau (plutôt qu'au PC pfSense), je peux faire des pings et naviguer sur l'interface web du modem sans problème. L'IP du modem est 192.168.0.254, et écoute sur le port 8080. Je peux aussi tracer les paquets de mon PC :
Ping du modem
REQ ARP Phalanx => Broadcast 192.168.0.98 -?- 192.168.0.254
RESP ARP Phalanx <= Ovislink_LAN 192.168.0.254 -!- 192.168.0.98
IP/ICMP Phalanx => Ovislink_LAN 192.168.0.98 => 192.168.0.254 ECHO
IP/ICMP Phalanx <= Ovislink_LAN 192.168.0.98 <= 192.168.0.254 ECHOREPLYVous pouvez voir mon ordinateur envoyer une diffusion ARP, demandant l'adresse MAC du modem (le Ovislink). Le modem répond avec son IP, l'écho part, et je reçois une réponse. Des détails similaires peuvent être vus lorsque je me connecte au port web du modem :
Connexion au port web 8080
REQ ARP Phalanx => Broadcast 192.168.0.98 -?- 192.168.0.254
RESP ARP Phalanx <= Ovislink_LAN 192.168.0.254 -!- 192.168.0.98
IP/TCP Phalanx => Ovislink_LAN 192.168.0.98:50001 => 192.168.0.254:8080 SYN
IP/TCP Plalanx <= Ovislink_LAN 192.168.0.98:50001 <= 192.168.0.254:8080 SYNACK
IP/TCP Phalanx => Ovislink_LAN 192.168.0.98:50001 => 192.168.0.254:8080 ACKAprès la requête ARP, une connexion TCP est établie avec le processus normal de SYN, SYN ACK, ACK. Et tout va bien.
Maintenant, plutôt que de connecter le modem à mon PC de bureau, je le connecte au PC qui exécute pfSense.
Remarque : Auparavant, j'avais changé l'adresse IP LAN de pfSense pour être 192.168.1.1/16, plutôt que 192.168.1.1/24. Cela est dû au fait que mon réseau était déjà en 192.168.0.0/16.
La première chose que je fais est de désactiver la fonction "Bloquer les réseaux privés" sous Interfaces->WAN, car l'interface LAN de mon modem fonctionne sous 192.168.0.254. Cela supprime la première entrée pare-feu sous Firewall->Rules qui bloquait tout le trafic RFC1918. Ensuite, j'ajoute une règle pare-feu :
Action : Autoriser
Interface : WAN
Protocole : TCP
Source : Hôte unique ou alias, 192.168.0.254
Destination : sous-réseau LAN
Plage de ports de destination : any
Journaliser les paquets : Oui
Description : Modem ADSL
Après avoir enregistré et appliqué mes modifications, j'ai essayé d'utiliser la fonction Diagnostics->Ping pour faire un ping sur 192.168.0.254 du côté WAN. Ce qui, bien sûr, n'a pas fonctionné.
J'y ai réfléchi, et il me semble que je ne peux pas simplement autoriser les paquets TCP en provenance de 192.168.0.254 vers le WAN, je dois également autoriser les paquets de réponse ARP (sinon comment pfSense pourrait-il trouver l'adresse MAC du matériel auquel il essaie d'envoyer un paquet IP?). Il m'a également semblé que je ne pouvais pas indiquer LAN comme destination, car c'est en fait l'interface WAN qui envoie le ping. J'ai donc mis à jour la règle pare-feu comme suit :
Action : Autoriser
Interface : WAN
Protocole : any
Source : Hôte unique ou alias, 192.168.0.254
Destination : any
Plage de ports de destination : any
Journaliser les paquets : Oui
Description : Modem ADSL
Maintenant, quand je fais un ping, ça ne fonctionne pas. Aucune surprise là-bas. J'ai donc décidé de faire une trace de paquets :
Interface : WAN
Adresse de l'hôte : 192.168.0.254
Nombre : 1
Niveau de détail : Complet
J'ai démarré la trace, fait un ping depuis Diagnostics->Ping, et je n'ai rien obtenu. Aucune réponse au ping, et aucun paquet dans la trace.
Maintenant, il me semble que juste parce que :
- pfSense est sur le sous-réseau
192.168.1.1/16 - mon bureau est sur le sous-réseau
192.168.0.98/16 - mon serveur est sur le sous-réseau
192.168.0.10/16
peut-être que le modem n'est pas sur le sous-réseau /16. Je rebranche le modem à mon bureau, me connecte à l'interface web et vois qu'il est configuré pour 192.168.0.254/24. Alors je reconfigure le modem pour 192.168.1.254/24. Je reconfigure ensuite
- mon bureau pour être
192.168.1.98, - le serveur pour être
192.168.1.10, - et maintenant le modem est
192.168.1.254 - en plus de pfSense étant
192.168.1.1.
Je reconnecte le modem à la box pfSense, essaie de faire un ping et je n'obtiens...aucune réponse. J'ai alors fait une trace de paquets pour les paquets en provenance de 192.168.1.254 et je n'ai vu...rien.
Je suis maintenant perplexe et demande de l'aide.
