Hallo all, I have one more question about other PF problem. I have installed OpenBSD in fail-over configuration using carp for shared IPs and pfsync for state synchronization to fail-over node. Now, we have big problems because openbsd does not allow some packets immediately as they come but after some time.
OpenBSD ignores ICMP ping requests from monitoring and it generates false alarms. The packet comes to internal interface em1 and PF blocks it, although this packet is allowed. Openbsd blocks 1-5 packets and then let the next packet without any problem. This happens only sometimes, more often go all packets correctly through PF without any problem. In the following output you can see the problem. The log contains only the first (state creating) packets. ====================================================================== 08:32:38.643316 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:32:38.643347 rule 58/(match) pass out on em0: XX.YY.0.5 > AA.B.CCC.177: icmp: echo request (DF) 08:36:09.217535 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:36:09.217556 rule 58/(match) pass out on em0: XX.YY.0.5 > AA.B.CCC.177: icmp: echo request (DF) 08:40:53.116908 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:40:54.118601 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:40:55.118546 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:40:55.118567 rule 58/(match) pass out on em0: XX.YY.0.5 > AA.B.CCC.177: icmp: echo request (DF) 08:42:31.705351 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:42:31.705384 rule 58/(match) pass out on em0: XX.YY.0.5 > AA.B.CCC.177: icmp: echo request (DF) 08:46:30.438276 rule 58/(match) pass in on em1: 172.16.2.5 > AA.B.CCC.177: icmp: echo request (DF) 08:46:30.438294 rule 58/(match) pass out on em0: XX.YY.0.5 > AA.B.CCC.177: icmp: echo request (DF) ====================================================================== At 8:32:38 and 8:36:09 you can see the first packets from monitoring host comming on em1 and going out on em0 to destination host. At 8:40:53 and 8:40:54 you can see the first two packets from monitoring. These packets are comming on em1 and passed, but they do not leave. The packet, which goes through firewall and leave on em0 to destination host is the third packet at 8:40:55. The ICMP ping request is allowed using following rule: pass log quick inet proto icmp all icmp-type echoreq code 0 keep state label "RULE 0 -- ACCEPT " -------------------------------------------------- The second problem is with DNS. On some hosts sudo starts periodically and it resolves own hostname. The hosts send DNS requests but they do not come to DNS server. Originaly there was named on openbsd at IP 4.1 and it should works as dns server for hosts. But having these problems I thought the named on openbsd has problem and I have tried to move dns to other host 0.68 and make only redirection to the other named. But the problem is packet processing: ====================================================================== 08:04:57.657659 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.57271 > XX.YY.4.1.53: 51755+[|domain] (DF) 08:04:57.657694 rule 101.PolicyOutLAN.55/(match) pass out on em1: XX.YY.4.176.57271 > XX.YY.0.68.53: 51755+[|domain] (DF) 08:04:57.658177 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.35531 > XX.YY.0.68.53: 51014+ A? svn.domain.dom. (31) (DF) 08:04:57.658200 rule 101.PolicyOutLAN.55/(match) pass out on em1: XX.YY.4.176.35531 > XX.YY.0.68.53: 51014+ A? svn.domain.dom. (31) (DF) 08:04:57.911547 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.3382 > XX.YY.4.1.53: 62520+ [1au][|domain] (DF) 08:04:57.986542 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.49725 > XX.YY.4.1.53: 43549+ [1au][|domain] (DF) 08:04:58.051437 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.1227 > XX.YY.4.1.53: 21298+ [1au][|domain] (DF) 08:04:58.091863 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.7085 > XX.YY.4.1.53: 23217+ [1au][|domain] (DF) 08:04:58.353628 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.49636 > XX.YY.4.1.53: 34944+ [1au][|domain] (DF) 08:04:58.753188 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.54615 > XX.YY.0.68.53: 42752+ AAAA? svn.domain.dom. (31) (DF) 08:04:58.760550 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.60889 > XX.YY.0.68.53: 4280+ AAAA? svn.domain.dom. (31) (DF) 08:04:58.775974 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.42772 > XX.YY.0.68.53: 5990+ AAAA? svn.domain.dom. (31) (DF) 08:04:58.916926 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.40753 > XX.YY.4.1.53: 47433+[|domain] (DF) 08:04:58.936084 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.39862 > XX.YY.0.68.53: 65288+ AAAA? svn.domain.dom. (31) (DF) 08:04:58.988921 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.36666 > XX.YY.4.1.53: 65105+[|domain] (DF) 08:04:59.052965 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.44080 > XX.YY.4.1.53: 11214+[|domain] (DF) 08:04:59.092940 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.54549 > XX.YY.4.1.53: 38346+[|domain] (DF) 08:04:59.356935 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.36381 > XX.YY.4.1.53: 28287+[|domain] (DF) 08:04:59.754646 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.54615 > XX.YY.0.68.53: 42752+ AAAA? svn.domain.dom. (31) (DF) 08:04:59.762656 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.60889 > XX.YY.0.68.53: 4280+ AAAA? svn.domain.dom. (31) (DF) 08:04:59.778621 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.42772 > XX.YY.0.68.53: 5990+ AAAA? svn.domain.dom. (31) (DF) 08:04:59.913190 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.25583 > XX.YY.4.1.53: 17634+ [1au][|domain] (DF) 08:04:59.938644 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.176.39862 > XX.YY.0.68.53: 65288+ AAAA? svn.domain.dom. (31) (DF) 08:04:59.985030 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.1703 > 193.0.9.3.53: 7887 [1au][|domain] (DF) 08:04:59.985081 rule 101.PolicyOutLAN.55/(match) pass out on em1: XX.YY.4.142.1703 > XX.YY.0.68.53: 7887 [1au][|domain] (DF) 08:04:59.985931 rule 92.PolicyInDMZ.21/(match) pass in on vlan30: XX.YY.4.142.1573 > 194.146.106.106.53: 37993 [1au][|domain] (DF) 08:04:59.985957 rule 101.PolicyOutLAN.55/(match) pass out on em1: XX.YY.4.142.1573 > XX.YY.0.68.53: 37993 [1au][|domain] (DF) ====================================================================== As you can see, at 8:04:57 host 4.176 sends dns request to GW IP 4.1 on vlan30. PF does redirect to host 0.68 and sends to em1. Connection is open. Then at 08:04:57.911547 other host 4.142 sends dns request and a bit later again host 4.176 too and there are no pass out on em1 records. It takes 2 seconds till the communication is again allowed. Probably the other lost packets are not so much visible because TCP tries many times to open connection and many UDP services sends more the one packet, but also some other users notify about connection problems. Do you have some idea, what could be the problem? Could it be some configuration of PF state timeouts? Thank you very much for your answers. Regards, Robert Wolf.
