DHCP Failover with CARP pfsense 2.0
-
DHCP failover with carp would set both pfsense as 'primary' for dhcp0 pool in /var/dhcpd/etc/dhcpd.conf
pfsense1:
LAN: 192.168.11.2DHCP failover IP: 192.168.11.4
pfsense2:
LAN: 192.168.11.4DHCP failover IP: 192.168.11.2
Carp IP: 192.168.11.1
pfsense2 is CARP master.
The DHCPD sync is working great but the resulting file would have "primary" on both machines. Resulting in both DHCP servers not serving DHCP requests.
LOG FROM 192.168.11.4:
Jan 28 09:31:12 dhcpd: Listening on BPF/em0/00:30:48:73:78:1d/192.168.11.0/24
Jan 28 09:31:12 dhcpd: Sending on BPF/em0/00:30:48:73:78:1d/192.168.11.0/24
Jan 28 09:31:12 dhcpd: Sending on Socket/fallback/fallback-net
Jan 28 09:31:12 dhcpd: failover peer dhcp0: I move from recover to startup
Jan 28 09:31:27 dhcpd: failover peer dhcp0: I move from startup to recover
Jan 28 09:32:09 dhcpd: DHCPREQUEST for 192.168.11.210 from 00:25:11:71:f3:2c via em0: not responding (recovering)
Jan 28 09:32:13 dhcpd: DHCPREQUEST for 192.168.11.210 from 00:25:11:71:f3:2c via em0: not responding (recovering)
Jan 28 09:32:20 dhcpd: DHCPREQUEST for 192.168.11.210 from 00:25:11:71:f3:2c via em0: not responding (recovering)LOG FROM 192.168.11.2
Jan 28 09:31:16 dhcpd: Listening on BPF/em1/00:0c:29:7e:41:47/192.168.11.0/24
Jan 28 09:31:16 dhcpd: Sending on BPF/em1/00:0c:29:7e:41:47/192.168.11.0/24
Jan 28 09:31:16 dhcpd: Sending on Socket/fallback/fallback-net
Jan 28 09:31:16 dhcpd: failover peer dhcp0: I move from recover to startup
Jan 28 09:31:31 dhcpd: failover peer dhcp0: I move from startup to recoverdhcpd.conf from 192.168.11.4:
option ldap-server code 95 = text;
option domain-search-list code 119 = text;default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
primary;
address 192.168.11.4;
port 519;
peer address 192.168.11.2;
peer port 520;
max-response-delay 10;
max-unacked-updates 10;
split 128;
mclt 600;load balance max seconds 3;
}DHCP CONFIG FROM 192.168.11.2:
option ldap-server code 95 = text;
option domain-search-list code 119 = text;default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
primary;
address 192.168.11.2;
port 519;
peer address 192.168.11.4;
peer port 520;
max-response-delay 10;
max-unacked-updates 10;
split 128;
mclt 600;load balance max seconds 3;
} -
Running:
2.0-BETA5 (i386)
built on Thu Jan 27 07:01:20 EST 2011 -
That might be an issue of the sync code that has to handle this.
Can you please send me your config privately to verify it? eri at pfsense dot org -
any news on this? If I enable the failover peer on the dhcp server I get that state on both systems.
Failover Group My State Since Peer State Since
"dhcp0" recover 2011/02/15 17:27:21 unknown-state 2011/02/15 17:27:21Do I need any firewall rules for it to work? thanks
-
I'm seeing the same as DISA on my test boxes.
I remember there was an issue with this about a year ago, and that a manual adjustment to one of the config files fixed the issue, but I don't remember what that was at this point. If I find it before somebody else does I'll post.
-
Uhm, on the logs I see a lot of:
dhcpd: DHCPDISCOVER from 00:23:7d:2d:e2:ea via em0: peer holds all free leases
and no leases are given :-)
maybe the problem is in the config file:
master:```
default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 10.0.10.11;
port 520;
peer address 10.0.10.12;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}slave:default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 10.0.10.12;
port 520;
peer address 10.0.10.11;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}uhm…I've put the LAN other peer ip address and now the config looks correct: master:efault-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
primary;
address 192.168.0.11;
port 519;
peer address 192.168.0.12;
peer port 520;
max-response-delay 10;
max-unacked-updates 10;
split 128;
mclt 600;load balance max seconds 3;
}slave:default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 192.168.0.12;
port 520;
peer address 192.168.0.11;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}but I still have "dhcpd: DHCPDISCOVER from e0:cb:4e:c7:a0:0c via em0: not responding (recovering)" in my logs andd the state isFailover Group My State Since Peer State Since
"dhcp0" recover 2011/02/16 09:04:12 unknown-state 2011/02/16 09:04:12for both of them Maybe I need to open port 519/520 in the lan firewall rules? I'll try later and will let you know :-) -
Adding a firewall rules for dest port 519/520 solved it! Shouldn't this be stated somewhere?
This is what I can now see on the logs
primary:Feb 16 11:13:52 dhcpd: DHCPACK to 192.168.0.198 (00:30:18:a3:3e:74) via em0 Feb 16 11:13:52 dhcpd: DHCPINFORM from 192.168.0.198 via em0 Feb 16 11:12:50 dhcpd: DHCPACK to 192.168.0.128 (00:23:7d:2d:e2:ea) via em0 Feb 16 11:12:50 dhcpd: DHCPINFORM from 192.168.0.128 via em0 Feb 16 11:11:02 dhcpd: DHCPACK to 192.168.0.103 (18:a9:05:a0:11:2b) via em0 Feb 16 11:11:02 dhcpd: DHCPINFORM from 192.168.0.103 via em0 Feb 16 11:10:13 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:13 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:10:10 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:10 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:06:49 dhcpd: Sending updates to dhcp0. Feb 16 11:06:49 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 30 backup 30 lts 0 max-misbal 9 Feb 16 11:06:49 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 33 backup 27 lts 3 max-own (+/-)6 Feb 16 11:06:49 dhcpd: failover peer dhcp0: I move from communications-interrupted to normal Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from normal to normal Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from normal to communications-interrupted Feb 16 11:06:44 dhcpd: peer dhcp0: disconnected Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover-done to normal Feb 16 11:06:44 dhcpd: Sending updates to dhcp0. Feb 16 11:06:44 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 30 backup 30 lts 0 max-misbal 9 Feb 16 11:06:44 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts 30 max-own (+/-)6 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover-done to normal Feb 16 11:06:44 dhcpd: Both servers have entered recover-done! Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer update completed. Feb 16 11:06:44 dhcpd: Sent update done message to dhcp0 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.197 from dhcp0 rejected: 192.168.0.197: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.196 from dhcp0 rejected: 192.168.0.196: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.194 from dhcp0 rejected: 192.168.0.194: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.193 from dhcp0 rejected: 192.168.0.193: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.191 from dhcp0 rejected: 192.168.0.191: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.190 from dhcp0 rejected: 192.168.0.190: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.189 from dhcp0 rejected: 192.168.0.189: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.187 from dhcp0 rejected: 192.168.0.187: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.184 from dhcp0 rejected: 192.168.0.184: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.161 from dhcp0 rejected: 192.168.0.161: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.141 from dhcp0 rejected: 192.168.0.141: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.140 from dhcp0 rejected: 192.168.0.140: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.139 from dhcp0 rejected: 192.168.0.139: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.138 from dhcp0 rejected: 192.168.0.138: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.137 from dhcp0 rejected: 192.168.0.137: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.132 from dhcp0 rejected: 192.168.0.132: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.131 from dhcp0 rejected: 192.168.0.131: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.128 from dhcp0 rejected: 192.168.0.128: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.127 from dhcp0 rejected: 192.168.0.127: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.126 from dhcp0 rejected: 192.168.0.126: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.123 from dhcp0 rejected: 192.168.0.123: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.122 from dhcp0 rejected: 192.168.0.122: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.121 from dhcp0 rejected: 192.168.0.121: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.120 from dhcp0 rejected: 192.168.0.120: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.119 from dhcp0 rejected: 192.168.0.119: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.118 from dhcp0 rejected: 192.168.0.118: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.117 from dhcp0 rejected: 192.168.0.117: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.115 from dhcp0 rejected: 192.168.0.115: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.114 from dhcp0 rejected: 192.168.0.114: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.113 from dhcp0 rejected: 192.168.0.113: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.112 from dhcp0 rejected: 192.168.0.112: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.111 from dhcp0 rejected: 192.168.0.111: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.108 from dhcp0 rejected: 192.168.0.108: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.107 from dhcp0 rejected: 192.168.0.107: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.106 from dhcp0 rejected: 192.168.0.106: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.105 from dhcp0 rejected: 192.168.0.105: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.104 from dhcp0 rejected: 192.168.0.104: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.103 from dhcp0 rejected: 192.168.0.103: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.101 from dhcp0 rejected: 192.168.0.101: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.100 from dhcp0 rejected: 192.168.0.100: invalid state transition: active to free Feb 16 11:06:44 dhcpd: Update request all from dhcp0: sending update Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover Feb 16 11:06:44 dhcpd: Sent update request all message to dhcp0 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from startup to recover Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from unknown-state to recoversecondary:
Feb 16 11:12:50 dhcpd: DHCPACK to 192.168.0.128 (00:23:7d:2d:e2:ea) via em0 Feb 16 11:12:50 dhcpd: DHCPINFORM from 192.168.0.128 via em0 Feb 16 11:11:02 dhcpd: DHCPACK to 192.168.0.103 (18:a9:05:a0:11:2b) via em0 Feb 16 11:11:02 dhcpd: DHCPINFORM from 192.168.0.103 via em0 Feb 16 11:10:13 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:13 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:10:10 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:10 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from communications-interrupted to normal Feb 16 11:06:49 dhcpd: Sending updates to dhcp0. Feb 16 11:06:49 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 34 backup 26 lts -4 max-misbal 9 Feb 16 11:06:49 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 33 backup 27 lts -3 max-own (+/-)6 Feb 16 11:06:49 dhcpd: failover peer dhcp0: I move from startup to normal Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from normal to communications-interrupted Feb 16 11:06:45 dhcpd: failover peer dhcp0: I move from normal to startup Feb 16 11:06:45 dhcpd: Sending on Socket/fallback/fallback-net Feb 16 11:06:45 dhcpd: Sending on BPF/em0/00:10:f3:1c:4b:1e/192.168.0.0/24 Feb 16 11:06:45 dhcpd: Listening on BPF/em0/00:10:f3:1c:4b:1e/192.168.0.0/24 Feb 16 11:06:45 dhcpd: Wrote 80 leases to leases file. Feb 16 11:06:45 dhcpd: Wrote 0 new dynamic host decls to leases file. Feb 16 11:06:45 dhcpd: Wrote 0 deleted host decls to leases file. Feb 16 11:06:45 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Feb 16 11:06:45 dhcpd: All rights reserved. Feb 16 11:06:45 dhcpd: Copyright 2004-2010 Internet Systems Consortium. Feb 16 11:06:45 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.185 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.129 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.110 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.125 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover-done to normal Feb 16 11:06:44 dhcpd: Sending updates to dhcp0. Feb 16 11:06:44 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts -30 max-misbal 9 Feb 16 11:06:44 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts -30 max-own (+/-)6 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover-done to normal Feb 16 11:06:44 dhcpd: Both servers have entered recover-done! Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer update completed. Feb 16 11:06:44 dhcpd: Sent update done message to dhcp0 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.179 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.178 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.177 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.176 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.175 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.169 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.168 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.167 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.166 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.165 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.164 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.116 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.102 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: Update request all from dhcp0: sending update Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover Feb 16 11:06:44 dhcpd: Sent update request all message to dhcp0 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from startup to recover Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from unknown-state to recoverDoes everything looks on now? Thanks
-
Give this a shot:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/72377228a61220f1dbe62afb81e0dc7757868ea5
Should make its way into snaps soon.
-
ehehe, I'm definitely going to try it tomorrow :-D
thanks! -
I've upgrade both the systems to 2.0-BETA5 (amd64) built on Wed Feb 16 23:27:05 EST 2011 and the rule has been added!
grep DHCP /tmp/rules.debug # allow access to DHCP server on LAN pass in on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server" pass in on $LAN proto udp from any port = 68 to 192.168.0.11 port = 67 label "allow access to DHCP server" pass out on $LAN proto udp from 192.168.0.11 port = 67 to any port = 68 label "allow access to DHCP server" # allow access to DHCP failover on LAN from 192.168.0.12 pass in on $LAN proto udp from 192.168.0.12 to 192.168.0.11 port = 519 label "allow access to DHCP failover" pass in on $LAN proto udp from 192.168.0.12 to 192.168.0.11 port = 520 label "allow access to DHCP failover"So now the dhcp failover works out of the box! :-)
I have 2 more questions:
- shouldn't be a way for the user to see all those "hidden" rules?
- when I deleted the rules from the master, it synced to the slave, and on the gui the rules was deleted, but if I check /tmp/rules.debug of the slave system, that rule is still there. I've also added a new test rule to the primary and it appeared on the secondary gui, but not in /tmp/rules.debug. Is this normal? Isn't this the file generated by the gui and then read by pfctl?
thanks
-
Hi Guys
Have a look at my post: http://forum.pfsense.org/index.php/topic,33403.0.html
for a possible solution…Kind regards
Aubrey -
we are speaking about dhcp firewall rules, not panics :-)
-
Hi DISA
Yes, I understand, but looking at the full discription on the topic you will see I found as part of the DHCP call info regarding MTU…
Kind regards
Aubrey -
I have 2 more questions:
- shouldn't be a way for the user to see all those "hidden" rules?
- when I deleted the rules from the master, it synced to the slave, and on the gui the rules was deleted, but if I check /tmp/rules.debug of the slave system, that rule is still there. I've also added a new test rule to the primary and it appeared on the secondary gui, but not in /tmp/rules.debug. Is this normal? Isn't this the file generated by the gui and then read by pfctl?
- It's been discussed before, but there's no easy way to do it in the GUI, if someone really wants to know they can look at the rules.debug file
- It should be kicking off a filter reload after the sync… Check the system log on both to see what it says around the time of the sync.
-
- It should be kicking off a filter reload after the sync… Check the system log on both to see what it says around the time of the sync.
yes, I can find it on the logs "check_reload_status: reloading filter" but on /tmp all files are from this morning reboot (after upgrade):
ls -lh /tmp/ total 184 -rw-r--r-- 1 root wheel 316B Feb 17 14:46 apinger.status -rw-r--r-- 1 root wheel 89B Feb 17 09:19 bootup_messages -rw-r--r-- 1 root wheel 0B Feb 17 09:18 captiveportal.lock -rw-r--r-- 1 root wheel 80K Feb 17 12:47 config.cache -rw-r--r-- 1 root wheel 0B Feb 17 12:47 config.lock -rw-r--r-- 1 root wheel 393B Feb 17 12:47 dhcpd.sh -rw-r--r-- 1 root wheel 13B Feb 17 12:47 em1_defaultgw -rw-r--r-- 1 root wheel 0B Feb 17 09:18 filter.lock drwxr-xr-x 3 root wheel 512B Feb 17 10:36 lighttpdcompress drwxr-xr-x 3 root wheel 512B Feb 17 09:18 mnt -rw-r--r-- 1 root wheel 11B Feb 17 12:47 ovpns1_router -rw-r--r-- 1 root wheel 0B Feb 17 12:47 ovpns1up -rw-r--r-- 1 root wheel 11B Feb 17 12:47 ovpns2_router -rw-r--r-- 1 root wheel 0B Feb 17 12:47 ovpns2up -rw-r--r-- 1 root wheel 29B Feb 17 09:57 pfSense_version -rw-r--r-- 1 root wheel 1.7K Feb 17 14:45 pfctl_si_out -rw-r--r-- 1 root wheel 44K Feb 17 14:45 pfctl_ss_out srwxr-xr-x 1 root wheel 0B Feb 17 09:18 php-fastcgi.socket-0 srwxr-xr-x 1 root wheel 0B Feb 17 09:18 php-fastcgi.socket-1 -rw-r--r-- 1 root wheel 82B Feb 17 09:18 pkg_delete_errors.txt -rw-r--r-- 1 root wheel 107B Feb 17 09:18 rules.boot -rw-r--r-- 1 root wheel 14K Feb 17 09:18 rules.debug -rw-r--r-- 1 root wheel 14K Feb 17 09:18 rules.debug.old -rw-r--r-- 1 root wheel 0B Feb 17 14:43 tmpHOSTS drwxrwxrwx 2 root wheel 512B Feb 17 09:17 uploadbar -
What happens if you go to Status > Filter Reload, what does the status show? What happens if you press the "Reload Filter" button?
-
I see "End of portal.pfsense.org configuration backup (success)…."
If i click on "reload filter" in the logs I see "check_reload_status: reloading filter", but on the status page I still have "End of portal.pfsense.org configuration backup (success)...." with a rotating spinner
Those are the latest restore I can see from the autobackup page:
2011-02-17 06:47:55 (system): Merged in config (system sections) from XMLRPC client.
2011-02-17 06:47:52 (system): Merged in config (filter,nat,aliases,dhcpd,wol,l7shaper,staticroutes,gateways,virtualip,load_balancer,ipsec,openvpn,cert,ca,crl,dnsmasq,schedules sections) from XMLRPC client.
2011-02-17 06:47:13 (system): Merged in config (system sections) from XMLRPC client.
2011-02-17 06:47:09 (system): Merged in config (filter,nat,aliases,dhcpd,wol,l7shaper,staticroutes,gateways,virtualip,load_balancer,ipsec,openvpn,cert,ca,crl,dnsmasq,schedules sections) from XMLRPC client.
2011-02-17 05:06:47 (system): Merged in config (system sections) from XMLRPC client. -
Hmm, ok. I haven't tried CARP sync with the Auto Config Backup on. There may be some kind of interaction there. It looks like it's saving the config OK though.
-
I setup ACB on my CARP cluster and I can't make it stick there. Rules delete OK, the filter reload shows the backup happen and then proceeds quickly to 'done'.
-
today, after an update to 2.0-BETA5 (amd64) built on Fri Feb 18 05:19:03 EST 2011 the relus.debug is updated as expected… ???
