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.


Messages - dayer

Pages: [1] 2
1
Hi ZsZs,

I've read your description with attention and I think it could be the same problem. Although I'll wait to Derelict point of view.
I know this part is the key:
Quote
I also saw in tcpdump, that when the ssh session freezes, the traffic leaves the firewall on wrong WAN interface with the other WAN interface's source IP address.
However, according to the last Derelict suggestion, I must repeat the test with the simplest scenario.

2
Gracias rosendogarcia por tu respuesta.
El problema (como he descrito en varios ejemplos del hilo en inglés) lo tengo tanto tanto con SSH como con ping, que usa ICMP. Por lo que descarto que ataña a la conexión segura.
Tengo pendiente simplificar al máximo el montaje físico, prescindiendo de enlaces agregados por ejemplo. En las pruebas con máquinas virtuales he tenido el mismo problema y quiero descartar que pueda estar afectado también por algún despiste en VirtualBox.

3
Hola. Por supuesto.
En el hilo en inglés al que comencé haciendo referencia en este hilo puse unas capturas con una de las configuraciones que he probado varias veces. También adjunté en ese mensaje los ficheros de configuración.

Según los expertos lo que yo quiero hacer es totalmente posible y que lo usa mucha gente. Pero después de haber probado el sistema en un entorno real con enlaces agregados y VLAN, y también en un entorno virtual sin agregación de enlaces ni VLAN, la situación con la que me encuentro es la misma.

4
Thank you Derelict.
I understand your point of view. However, if...
Quote
It looks like your problem is whatever is upstream is refusing to accept the CARP VIP (and MAC address) moving from primary to secondary.
I can't understand why I only see this behavior when the gateway from LAN traffic to outside is different from the default gateway. If the gateway from LAN traffic to outside is the same from the default gateway, everything goes well.

That is:

  • LAN: 192.168.2.0/24
  • WAN1: 192.168.1.0/24
  • WAN2: 192.168.56.0/24

Rules for LAN:
Code: [Select]
States      Protocol    Source  Port    Destination     Port    Gateway     Queue   Schedule    Description     Actions
1 /427 B    IPv4 *      *       *       LAN net         *       *           none
1 /1.04 MiB IPv4 *      *       *       *               *       GW1         none

Gateways (default gateway = gateway for LAN to outside):
Code: [Select]
Name            Interface   Gateway         Monitor IP
GW1 (default)   WAN1        192.168.1.1     192.168.1.1
GW2             WAN2        192.168.56.1    192.168.56.1

I try with SSH and it's goes well.

States relalted to xx.xxx.xxx.xxx in pfsense1 (master):
Code: [Select]
LAN     tcp     192.168.2.1:60626 -> xx.xxx.xxx.xxx:22522                           ESTABLISHED:ESTABLISHED     146 / 130   11 KiB / 20 KiB
WAN1    tcp     192.168.1.20:62445 (192.168.2.1:60626) -> xx.xxx.xxx.xxx:22522      ESTABLISHED:ESTABLISHED     146 / 130   11 KiB / 20 KiB

States related to xx.xxx.xxx.xxx in pfsense2 (backup):
Code: [Select]
LAN     tcp     192.168.2.1:60626 -> xx.xxx.xxx.xxx:22522                           ESTABLISHED:ESTABLISHED     0 / 0       0 B / 0 B
WAN1    tcp     192.168.1.20:62445 (192.168.2.1:60626) -> xx.xxx.xxx.xxx:22522      ESTABLISHED:ESTABLISHED     0 / 0       0 B / 0 B

Enter Persistent CARP Maintenance Mode

States related to xx.xxx.xxx.xxx in pfsense1 (backup):
Code: [Select]
LAN     tcp     192.168.2.1:60626 -> xx.xxx.xxx.xxx:22522                           ESTABLISHED:ESTABLISHED     339 / 321   21 KiB / 48 KiB
WAN1    tcp     192.168.1.20:62445 (192.168.2.1:60626) -> xx.xxx.xxx.xxx:22522      ESTABLISHED:ESTABLISHED     339 / 321   21 KiB / 48 KiB

States related to xx.xxx.xxx.xxx in pfsense2 (master):
Code: [Select]
LAN     tcp     192.168.2.1:60626 -> xx.xxx.xxx.xxx:22522                           ESTABLISHED:ESTABLISHED     111 / 111   6 KiB / 16 KiB
WAN1    tcp     192.168.1.20:62445 (192.168.2.1:60626) -> xx.xxx.xxx.xxx:22522      ESTABLISHED:ESTABLISHED     111 / 111   6 KiB / 16 KiB

But if the default gateway is not the gateway for LAN to outside:
Code: [Select]
Name            Interface   Gateway         Monitor IP
GW1             WAN1        192.168.1.1     192.168.1.1
GW2 (default)   WAN2        192.168.56.1    192.168.56.1

Then, the behavior is well until I put CARP Maintenance Mode (pfsense1 backup, pfsense2 master) and the states related to xx.xxx.xxx.xxx in pfsense2 (master) are:
Code: [Select]
LAN     tcp     192.168.2.1:60632 -> xx.xxx.xxx.xxx:22522                           ESTABLISHED:ESTABLISHED     31 / 5      5 KiB / 1 KiB
WAN1    tcp     192.168.1.20:49862 (192.168.2.1:60632) -> xx.xxx.xxx.xxx:22522      ESTABLISHED:ESTABLISHED     31 / 5      5 KiB / 1 KiB
and the SSH client is like frozen until I leave Persistent CARP Maintenance Mode and pfsense1 recovers the master role.

5
Thank you, Derelict.

I can't find why a established state in pfSense1 isn't routed successfully when pfSense2 is the master.
I'm talking about this example (rules here):

Pinging 208.123.73.69

States on Primary/MASTER:

Code: [Select]
LAN     icmp    172.16.103.2:10618 -> 208.123.73.69:10618                           0:0     69 / 69     6 KiB / 6 KiB
WAN2    icmp    192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632     0:0     69 / 69     6 KiB / 6 KiB

States on Secondary/BACKUP:
Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                           0:0     0 / 0 0 B / 0 B
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632     0:0     0 / 0 0 B / 0 B

Persistent CARP maintenance mode on Primary:

States on secondary start seeing the traffic but something goes wrong. The number of packets observed matching the state from the destination side is zero.

Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                         0:0 58 / 0 5 KiB / 0 B
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632 0:0 58 / 0 5 KiB / 0 B

It's like the policy routing is ignored for this kind of situation and the firewall is trying route the established traffic through the default gateway (and use the NAT for a connection to exit through another WAN).
I've tried also with floating rules, without success.
There's some command or log to check what decisions takes pfSense with search state or packet

6
@Derelict, please, what VM has you tested? VirtualBox? VMware? Could you share your two XML config files?

I've tested that situation with VirtualBox (before and after a factory default, to remake and check the settings) and with two identical physical machines also. No success.
We're considering use pfSense and be sure this functionality works in pfSense is important to us.

7
Routing and Multi WAN / Re: trying to get multi-WAN working
« on: October 05, 2017, 05:36:51 pm »
Are you doing the ping from pfSense to outside (e.g. Google)?
It's important because the firewall rules (policy routing) don't apply to traffic from firewall. For that situation you should enable the gateway switching (according to  System > Advanced > Miscellaneous)

If you're trying the ping from the PC, you must look over the outbound NAT settings, to be sure the traffic from LAN is translated to the secondary WAN IP.

8
Hola j.sejo1. En la sección de Multi-WAN hemos contrastado pruebas similares Derelict y yo. A él le funciona sin problemas un laboratorio virtual que ha montado y que a mí me sigue fallando. No me ha pasado su configuración y estoy a la espera de si me confirma qué reglas de firewall y NAT ha utilizado él.

A mi modo de ver tiene que haber algo en mi configuración, o en mi manera de utilizar pfSense, que se empeña en ignorar el policy routing para las conexiones ya establecidas cuando cambio de nodos master/backup. Lo cierto es que el NAT sí que lo mantiene, pero para el enrutado parece basarse directamente en la tabla de rutas del sistema. Motivo por el que no se trata de que se pierda algún paquete, sino que se intenta enrutar por el gateway por defecto (en lugar del que configuro con policy routing) y pierda las conexiones.

9
Thank you Derelict :)

I've been simulating your tests.


WAN is the default gateway:
Code: [Select]
WAN1 (default)      WAN1 xxx.xxx.xxx.xxx     8.8.8.8     WAN1 Gateway
WAN2                WAN2 192.168.1.1         8.8.4.4     WAN2 Gateway

Policy routing all LAN traffic to outside go through WAN2:
Code: [Select]
States      Protocol    Source  Port    Destination     Port    Gateway     Queue   Schedule    Description
5 /3.80 MiB IPv4*       *       *       internals       *       *           none                Internal traffic to default gateway
0 /254 KiB  IPv4*       *       *       *               *       WAN2        none                The rest to WAN2

NAT for internal traffic to outside:
Code: [Select]
WAN1    internals * * * xxx.xxx.xxx.xxy     * NAT from internal networks
WAN2    internals * * * 192.168.1.100       * NAT from internal networks
internals is an alias with internal networks.

Pinging 208.123.73.69

States on Primary/MASTER:

Code: [Select]
LAN     icmp    172.16.103.2:10618 -> 208.123.73.69:10618                           0:0     69 / 69     6 KiB / 6 KiB
WAN2    icmp    192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632     0:0     69 / 69     6 KiB / 6 KiB

States on Secondary/BACKUP:
Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                           0:0     0 / 0 0 B / 0 B
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632     0:0     0 / 0 0 B / 0 B

Persistent CARP maintenance mode on Primary:

States on secondary start seeing the traffic but something goes wrong. The number of packets observed matching the state from the destination side is zero.

Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                         0:0 58 / 0 5 KiB / 0 B
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632 0:0 58 / 0 5 KiB / 0 B

Client doesn't get ping reponses.

States still exists on primary but are not seeing any traffic (it's reasonable):

Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                         0:0 368 / 368 30 KiB / 30 KiB
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632 0:0 368 / 368 30 KiB / 30 KiB

Leave Persistent CARP maintenance mode on Primary. States on primary are seeing the traffic again (368 now 372):

Code: [Select]
LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618                         0:0 372 / 372 31 KiB / 31 KiB
WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632 0:0 372 / 372 31 KiB / 31 KiB



SSH to aaa.bbb.ccc.ddd (I've replaced the public IP for security reasons):

States on Primary:

Code: [Select]
LAN tcp 172.16.103.2:43290 -> aaa.bbb.ccc.ddd:22                        ESTABLISHED:ESTABLISHED 138 / 126 12 KiB / 20 KiB
WAN2 tcp 192.168.1.100:54741 (172.16.103.2:43290) -> aaa.bbb.ccc.ddd:22  ESTABLISHED:ESTABLISHED 138 / 126 12 KiB / 20 KiB

States on Secondary:
Code: [Select]
LAN tcp 172.16.103.2:43290 -> aaa.bbb.ccc.ddd:22                        ESTABLISHED:ESTABLISHED 0 / 0 0 B / 0 B
WAN2 tcp 192.168.1.100:54741 (172.16.103.2:43290) -> aaa.bbb.ccc.ddd:22  ESTABLISHED:ESTABLISHED 0 / 0 0 B / 0 B

Persistent CARP maintenance mode on Primary:

States on secondary start seeing the traffic, but something appears wrong:
Code: [Select]
LAN tcp 172.16.103.2:43290 -> aaa.bbb.ccc.ddd:22                        ESTABLISHED:ESTABLISHED 13 / 3 2 KiB / 708 B
WAN2 tcp 192.168.1.100:54741 (172.16.103.2:43290) -> aaa.bbb.ccc.ddd:22  ESTABLISHED:ESTABLISHED 13 / 3 2 KiB / 708 B


With tcpdump in WAN1, I see the Secondary firewall is routing through WAN1 using the WAN2 VIP address like for NAT:

Code: [Select]
14:09:03.973890 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [.], ack 1150910396, win 593, options [nop,nop,TS val 3297622232 ecr 1263162549], length 0
14:09:07.569891 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [.], ack 1, win 593, options [nop,nop,TS val 3297625828 ecr 1263163448,nop,nop,sack 1 {4294967113:1}], length 0
14:09:08.810847 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [P.], seq 0:52, ack 1, win 593, options [nop,nop,TS val 3297627069 ecr 1263163448], length 52
14:09:08.978668 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [P.], seq 52:104, ack 1, win 593, options [nop,nop,TS val 3297627237 ecr 1263163448], length 52
14:09:09.035602 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [P.], seq 52:104, ack 1, win 593, options [nop,nop,TS val 3297627294 ecr 1263163448], length 52
14:09:09.122214 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [P.], seq 104:156, ack 1, win 593, options [nop,nop,TS val 3297627380 ecr 1263163448], length 52
14:09:09.180582 IP 192.168.1.100.54741 > aaa.bbb.ccc.ddd.22: Flags [P.], seq 0:156, ack 1, win 593, options [nop,nop,TS val 3297627439 ecr 1263163448], length 156

States still exists on primary but are not seeing any traffic (it's reasonable):

Code: [Select]
LAN tcp 172.16.103.2:43290 -> aaa.bbb.ccc.ddd:22                        ESTABLISHED:ESTABLISHED 232 / 220 17 KiB / 34 KiB
WAN2 tcp 192.168.1.100:54741 (172.16.103.2:43290) -> aaa.bbb.ccc.ddd:22  ESTABLISHED:ESTABLISHED 232 / 220 17 KiB / 34 KiB

Leave Persistent CARP mantenance mode on Primary. States on primary are seeing the traffic again (232 now 294) and SSH terminal replies again:
Code: [Select]
LAN tcp 172.16.103.2:43290 -> aaa.bbb.ccc.ddd:22                        ESTABLISHED:ESTABLISHED 294 / 291 22 KiB / 80 KiB
WAN2 tcp 192.168.1.100:54741 (172.16.103.2:43290) -> aaa.bbb.ccc.ddd:22  ESTABLISHED:ESTABLISHED 294 / 291 22 KiB / 80 KiB

I'm going to check our differences.

10
Thank you very much for your tests.

Related to the failing over during live video streams, where those using the default gateway or... a secondary gateway according to a firewall rule or a failover gateway group? This difference is important because I've only found the problem if I'm using a not default gateway while I change the master unit.

I've done several tests, with virtual and physical machines, with LACP and without them, but the behavior always has been the same  :-\
I attached my config in the reply #3 a few days ago to try clearing any doubt about the settings.

Please, do you know a more detailed guide than Multi-WAN + Configuring pfSense Hardware Redundancy (CARP) from PFSenseDocs or the High Availability » Multi-WAN with HA from The pfSense Book for this purpose?
Could you share your tests configuration?

11
One more thing.
I've done the last tests again, with SSH instead of ping, but I haven't achieved recover the SSH.

12
Thank you for your interest :)

I've followed your suggestion related to the setp #6:
  • If I kill all states the ping starts succeeding again :)
  • If I kill all states related to the destination IP, the ping starts succeeding again :)
  • If I kill the states related to the destination IP in WAN2 , the ping continues failing :(
  • If I kill the states related to the destination IP in LAN , the ping starts succeeding again :)
And in the successfully situations, If Pfsense1 recover the master rol the ping continues succeeding.
I think it's a problem related to keep the routes in established states at LAN interface.

Could it be considered a bug?

13
I attach some information I'm using to explain the problem also in mailing list thread:
  • Configuration files from a scenario with pfSense 2.4-0-RC over two virtual machines
  • Screenshots for an example

14
Gracias j.sejo1 por tu respuesta. Ya me has hecho más caso que en la sección del problema en cuestión ;D

Te comento. Estoy utilizando IP virtuales tanto para la LAN como para las dos WAN. Y utilizándolas en el NAT cuando los paquetes van fuera de la LAN o de las propias WAN.
Aparentemente la configuración funciona estupendamente, excepto con las reglas del firewall para enrutar según qué tráfico por el gateway de una WAN que no sea el por defecto del sistema.
En este último caso, el tráfico se enruta bien, pero las conexiones establecidas (enrutadas mediante esa regla) se quedan congeladas si se cambia de nodo maestro de CARP.

Pongo un ejemplo para intentar que se entienda mejor.
Configuración:
  • El nodo1 está como maestro del cluster. Nodo2 es el esclavo o backup.
  • GW1 (de WAN1) es el gateway por defecto
  • GW2 (de WAN2) es el gateway para el tráfico que proviene de LAN (con una regla del firewall).
  • Se hace NAT usando la VIP de WAN1 para el tráfico de LAN que sale por WAN1.
  • Se hace NAT usando la VIP de WAN2 para el tráfico de LAN que sale por WAN2.
Pasos para recrear la situación:
  • Establezco una conexión desde LAN hacia el exterior. Como un ssh. Acorde a las reglas del firewall sale por WAN2. Funciona bien
  • Sin cerrar la conexión, deshabilito CARP en nodo1, de manera que nodo2 se pone de master con todas las VIP.
  • La conexión que tenía establecida (por ssh) desde la LAN se queda congelada.
  • Ejecutando tcpdump en el nodo2 (ahora master) veo que:
    • El tráfico de la LAN entra por la interfaz LAN, como es de esperar. Con las mismas IP de origen/destino que cuando el nodo1 estaba como master.
    • El tráfico está intentando salir por WAN1 y utilizando la VIP de WAN2. En lugar de estar saliendo por WAN2, como indican las reglas del firewall.
  • Si cierro el cliente ssh y vuelvo a lanzarlo, entonces el tráfico sí se enruta por WAN2, como es de esperar

Así pues, el problema lo tengo con las conexiones que ya están establecidas cuando se cambia de master de CARP. Para las que pfSense parece ignorar las reglas del policy routing y las intenta enrutar por el gateway por defecto. A pesar de que con tcpdump he comprobado que el tráfico sigue entrando por la interfaz LAN.

15
Hola. Estoy teniendo un problema con Multi-WAN, alta disponibilidad y policy routing que creo que podría ser un bug. No lo quiero repetir aquí, que mi intención no es duplicar el hilo del problema o posible bug. Pero ningún experto/desarrollador me contesta y en las instrucciones de reportar bugs indican que los bugs no confirmados se pongan aquí o en la lista de correo.

En reddit también lo he comentado y al menos me ha contestado una persona con un problema similar, que parece que también considera que algo falla en Pfsense.

¿Algún consejo? ¿Lo intento por la lista de correo?
Gracias

Pages: [1] 2