Re: [pfSense] Strange problem after auto update
Hi, Just to let you know that this 2.1 snapshot : FreeBSD 8.3-RELEASE-p4 #1: Thu Nov 8 11:35:37 EST 2012 Fixes my problem. Now the slave can ping and do DNS queries at will, as expected (at least as I expected). bye, and thanks for your work guys ! -- Jérôme Alet - jerome.a...@univ-nc.nc - Direction du Système d'Information Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX Tél : +687 290081 Fax : +687 254829 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Hi, I was able to do the upgrade just now, finally... and no luck. From: Chris Buechler c...@pfsense.org Sent: Tue Nov 06 17:17:02 NCT 2012 To: pfSense support and discussion list@lists.pfsense.org Subject: Re: [pfSense] Strange problem after auto update You can try either upgrading to a November 6 or newer snapshot, or just removing the line containing Done. This doesn't change the situation unfortunately... set state-policy if-bound from /etc/inc/filter.inc and reloading the filter rules under StatusFilter reload. See if that changes anything. That line isn't even present in /etc/inc/* : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc/inc(8): grep state-policy * [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc/inc(9): [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc/inc(10): grep if-bound * [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc/inc(11): I'm restoring again right now. Any other idea ? bye, and thanks so much again for your time -- Jerome Alet ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Hi, According to the details it looks like Ichmp echo is blocked. Does it do the same pinging to google etc? Sincerely yours, Mikey van der Worp -- Utelisys Communications B.V. Op 5 nov. 2012 om 04:23 heeft Jerome Alet jerome.a...@univ-nc.nc het volgende geschreven: Hi, We've got two pfsense 2.1-BETA0 snapshots running on AMD64 as a failover cluster. Each of these two Dell R610 has two Intel quad ports Gigabit Ethernet (igb) and one (integrated) Broadcom (bce) quad ports Gigabit Ethernet cards. Both were running 8.3-RELEASE-p4 #1: Thu Sep 27 14:06:33 EDT 2012 just fine. This morning, I've updated the slave to 8.3-RELEASE-p4 #1: Sat Nov 3 16:04:02 EDT 2012. Fortunately I haven't updated the master for now. Since this upgrade, all syslog from the slave host logs to our central syslog server as the CARP VIP address of the LAN. Before, it went to the central syslog server as its own LAN address, just like the master host. This is a really big change and I don't really understand why it would happen or even be a good idea. Finally, the slave host does seem to have big connectivity problems, causing at least DNS to fail : One of our DNS server's IP address is 10.10.0.3, on the LAN. The master's IP address is 10.10.3.252, the slave is 10.10.3.253 and the CARP virtual IP is 10.10.3.254. The network mask is 255.255.252.0 Now here's a ping from our DNS server to the slave : awa:~ # ping pfsense2 PING pfsense2-intra.univ-nc.nc (10.10.3.253) 56(84) bytes of data. 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=1 ttl=64 time=0.267 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=2 ttl=64 time=0.205 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=3 ttl=64 time=0.215 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=4 ttl=64 time=0.243 ms --- pfsense2-intra.univ-nc.nc ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3012ms rtt min/avg/max/mdev = 0.205/0.232/0.267/0.028 ms The other way around, from the slave to DNS : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(13): ping 10.10.0.3 PING 10.10.0.3 (10.10.0.3): 56 data bytes ^C --- 10.10.0.3 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss So this way all packets are lost, but traceroute works fine : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(20): traceroute -n 10.10.0.3 traceroute to 10.10.0.3 (10.10.0.3), 64 hops max, 52 byte packets 1 10.10.0.3 0.276 ms 0.308 ms 0.221 ms If I do a full restore (I did a full backup before the slave update), then all works fine again. Any idea of what could be wrong with our setup ? Thanks so much in advance -- Jérôme Alet - jerome.a...@univ-nc.nc - Direction du Système d'Information Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX Tél : +687 290081 Fax : +687 254829 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Hi, According to the details it looks like Ichmp echo is blocked. Does it do the same pinging to google etc? Sincerely yours, Mikey van der Worp -- Utelisys Communications B.V. Op 5 nov. 2012 om 04:23 heeft Jerome Alet jerome.a...@univ-nc.nc het volgende geschreven: Hi, We've got two pfsense 2.1-BETA0 snapshots running on AMD64 as a failover cluster. Each of these two Dell R610 has two Intel quad ports Gigabit Ethernet (igb) and one (integrated) Broadcom (bce) quad ports Gigabit Ethernet cards. Both were running 8.3-RELEASE-p4 #1: Thu Sep 27 14:06:33 EDT 2012 just fine. This morning, I've updated the slave to 8.3-RELEASE-p4 #1: Sat Nov 3 16:04:02 EDT 2012. Fortunately I haven't updated the master for now. Since this upgrade, all syslog from the slave host logs to our central syslog server as the CARP VIP address of the LAN. Before, it went to the central syslog server as its own LAN address, just like the master host. This is a really big change and I don't really understand why it would happen or even be a good idea. Finally, the slave host does seem to have big connectivity problems, causing at least DNS to fail : One of our DNS server's IP address is 10.10.0.3, on the LAN. The master's IP address is 10.10.3.252, the slave is 10.10.3.253 and the CARP virtual IP is 10.10.3.254. The network mask is 255.255.252.0 Now here's a ping from our DNS server to the slave : awa:~ # ping pfsense2 PING pfsense2-intra.univ-nc.nc (10.10.3.253) 56(84) bytes of data. 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=1 ttl=64 time=0.267 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=2 ttl=64 time=0.205 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=3 ttl=64 time=0.215 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=4 ttl=64 time=0.243 ms --- pfsense2-intra.univ-nc.nc ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3012ms rtt min/avg/max/mdev = 0.205/0.232/0.267/0.028 ms The other way around, from the slave to DNS : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(13): ping 10.10.0.3 PING 10.10.0.3 (10.10.0.3): 56 data bytes ^C --- 10.10.0.3 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss So this way all packets are lost, but traceroute works fine : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(20): traceroute -n 10.10.0.3 traceroute to 10.10.0.3 (10.10.0.3), 64 hops max, 52 byte packets 1 10.10.0.3 0.276 ms 0.308 ms 0.221 ms If I do a full restore (I did a full backup before the slave update), then all works fine again. Any idea of what could be wrong with our setup ? Thanks so much in advance -- Jérôme Alet - jerome.a...@univ-nc.nc - Direction du Système d'Information Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX Tél : +687 290081 Fax : +687 254829 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Hi, From: Mikey van der Worp mvdw...@utelisys.com Sent: Mon Nov 05 15:29:04 NCT 2012 To: pfSense support and discussion list@lists.pfsense.org Subject: Re: [pfSense] Strange problem after auto update According to the details it looks like Ichmp echo is blocked. Does it do the same pinging to google etc? Sorry, forgot to add that I don't see any rejected packet in our central syslog server, for any of these two pfSense boxes. As far as pinging google is concerned, DNS doesn't work either, so I don't think ICMP echo is particular, I mentioned this to expose the connectivity problem. BTW since our DNS server is on the LAN interface, and the default rule in pfSense (IIRC) is to allow all from LAN (and we kept this default rule active), the DNS queries should just work, and they don't. What is strange though is that both the web interface and the ssh server work, even when connecting from LAN. Could this be a misconfiguration on our part, being exposed only because of the update ? Thanks in advance for any hint -- Jerome Alet ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Me, again :-) I've noticed something that might be helpful... When I have upgraded the slave member of my pfSense cluster, the version number of the configuration file changes from 9.0 to 9.1 So I've got two members of the cluster with different versions, since I've not upgraded the master yet, and I'm not sure I want to do it before knowing the source of my problem. So master is still in 9.0 and slave is in 9.1. Could this be the cause of my problem ? I mean, when the master tries to sync its configuration to the slave, doesn't it break the slave's configuration ? Is the proper way to upgrade by upgrading the master first ??? Does this mean that if I upgrade the master now, all will be fine again ? Thanks (again) in advance for any answer. -- Jérôme Alet - jerome.a...@univ-nc.nc - Direction du Système d'Information Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX Tél : +687 290081 Fax : +687 254829 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
On Mon, Nov 5, 2012 at 1:41 PM, Jerome Alet jerome.a...@univ-nc.nc wrote: Me, again :-) I've noticed something that might be helpful... When I have upgraded the slave member of my pfSense cluster, the version number of the configuration file changes from 9.0 to 9.1 So I've got two members of the cluster with different versions, since I've not upgraded the master yet, and I'm not sure I want to do it before knowing the source of my problem. So master is still in 9.0 and slave is in 9.1. Could this be the cause of my problem ? I mean, when the master tries to sync its configuration to the slave, doesn't it break the slave's configuration ? Is the proper way to upgrade by upgrading the master first ??? Does this mean that if I upgrade the master now, all will be fine again ? Everything you did was fine as you did it, it's preferable to upgrade the secondary first, test it by disabling CARP on the primary, and if successful then upgrade the secondary. Doesn't really matter which order you do it in, but doing the secondary first makes it easier to keep traffic off of it should something go wrong with the upgrade (as the primary will always want to take over CARP, the secondary won't unless you take the primary down). You're running into some kind of regression and I'm not exactly sure what. I have a suspicion it's related to the various problems with if-bound states, but not sure. You can try either upgrading to a November 6 or newer snapshot, or just removing the line containing set state-policy if-bound from /etc/inc/filter.inc and reloading the filter rules under StatusFilter reload. See if that changes anything. Keep doing that only on the secondary and don't upgrade the primary until the secondary is fixed as it's almost certain it'll break too. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Strange problem after auto update
Hi, From: Chris Buechler c...@pfsense.org Sent: Tue Nov 06 17:17:02 NCT 2012 To: pfSense support and discussion list@lists.pfsense.org Subject: Re: [pfSense] Strange problem after auto update You're running into some kind of regression and I'm not exactly sure what. I have a suspicion it's related to the various problems with if-bound states, but not sure. You can try either upgrading to a November 6 or newer snapshot, or just removing the line containing set state-policy if-bound from /etc/inc/filter.inc and reloading the filter rules under StatusFilter reload. See if that changes anything. Keep doing that only on the secondary and don't upgrade the primary until the secondary is fixed as it's almost certain it'll break too. Unfortunately I won't be able to test this until Thursday, but I'll let you know how it goes. bye, and thanks a lot for your help -- Jerome Alet ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] Strange problem after auto update
Hi, We've got two pfsense 2.1-BETA0 snapshots running on AMD64 as a failover cluster. Each of these two Dell R610 has two Intel quad ports Gigabit Ethernet (igb) and one (integrated) Broadcom (bce) quad ports Gigabit Ethernet cards. Both were running 8.3-RELEASE-p4 #1: Thu Sep 27 14:06:33 EDT 2012 just fine. This morning, I've updated the slave to 8.3-RELEASE-p4 #1: Sat Nov 3 16:04:02 EDT 2012. Fortunately I haven't updated the master for now. Since this upgrade, all syslog from the slave host logs to our central syslog server as the CARP VIP address of the LAN. Before, it went to the central syslog server as its own LAN address, just like the master host. This is a really big change and I don't really understand why it would happen or even be a good idea. Finally, the slave host does seem to have big connectivity problems, causing at least DNS to fail : One of our DNS server's IP address is 10.10.0.3, on the LAN. The master's IP address is 10.10.3.252, the slave is 10.10.3.253 and the CARP virtual IP is 10.10.3.254. The network mask is 255.255.252.0 Now here's a ping from our DNS server to the slave : awa:~ # ping pfsense2 PING pfsense2-intra.univ-nc.nc (10.10.3.253) 56(84) bytes of data. 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=1 ttl=64 time=0.267 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=2 ttl=64 time=0.205 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=3 ttl=64 time=0.215 ms 64 bytes from pfsense2-intra.univ-nc.nc (10.10.3.253): icmp_seq=4 ttl=64 time=0.243 ms --- pfsense2-intra.univ-nc.nc ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3012ms rtt min/avg/max/mdev = 0.205/0.232/0.267/0.028 ms The other way around, from the slave to DNS : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(13): ping 10.10.0.3 PING 10.10.0.3 (10.10.0.3): 56 data bytes ^C --- 10.10.0.3 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss So this way all packets are lost, but traceroute works fine : [2.1-BETA0][r...@pfsense2.univ-nc.nc]/etc(20): traceroute -n 10.10.0.3 traceroute to 10.10.0.3 (10.10.0.3), 64 hops max, 52 byte packets 1 10.10.0.3 0.276 ms 0.308 ms 0.221 ms If I do a full restore (I did a full backup before the slave update), then all works fine again. Any idea of what could be wrong with our setup ? Thanks so much in advance -- Jérôme Alet - jerome.a...@univ-nc.nc - Direction du Système d'Information Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX Tél : +687 290081 Fax : +687 254829 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
