CARP - Backup box does not pass any traffic to LAN causing dhcp problem

jjstecchino

I am trying 2.1 (10/25) on 2 fireboxes in CARP mode.
New Install
I have noticed DHCP failover didnt work (dhcpd: failover: listener: no matching state) so both DHCP servers go into recover mode.
dhcpd.conf seems correct. the primary is identified as such with the proper ports assigned and so is the secondary.
From the MASTER box I can get to port 520 on the backup but from the backup I cannot get to port 519 on the MASTER.
from the master I can ping any host on the lan network
from the backup I can ping anything on the wan if but nothing on the lan unless the backup box becomes master (disconnecting the master from lan)

dhcpd on the master seems to be talking to the backup but dhcp on the master is unreachable from the backup

CARP is syncing settings and working otherwise ok

cmb

Sounds like you have a general problem with IP connectivity from the interface IP of the secondary on the internal network, an IP conflict on the interface IP possibly?

jjstecchino

@cmb:

Sounds like you have a general problem with IP connectivity from the interface IP of the secondary on the internal network, an IP conflict on the interface IP possibly?

As I keep testing I see I can pass any udp traffic out of the backup but not tcp.
This is why the secondary dhcpd is trying to serve Ip's but it cannot reach the master dhcpd on port tcp 519

if i bring down the master and the backup assumes master role then I can pass any traffic tcp, udp and all

from the master console if I do "nc -z backup 520" it succedes, however if from the backup I do "nc -z master 519" it fails but I can do "nc -u -z master 519" and it succedes.

from the backup I cannot ping anything on the lan subnet but the backup itself responds to ping.

It is driving me crazy.

The pf rules seems ok

I dont know where else I can look.

Any hints?

jjstecchino

Found!
It is missing an outbound nat rule to pass any out of lan.
added the rule in NAT=>outbound->manual nat rule to pass all out of nat and now it is ok.
Should this be an automatic rule with crp enabled?

jjstecchino

I believe it may be related to this bug:

https://redmine.pfsense.org/issues/2645

it is a function of filter.inc –> filter_process_carp_nat_rules

which is totally screwed up since it tries to get the carp ip from config['hasync'] instead of config['virtualip'].

As a result there is an error during boot: Warning: stristr(): Empty delimiter in /etc/inc/interfaces.inc on line …...

and the automatic nat rule for carp does not get set and you need to add it manually.

jimp

Should be fixed up on the next new snapshot (hopefully).