DHCP Failover with CARP pfsense 2.0
-
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… ???
