From owner-freebsd-pf@FreeBSD.ORG Mon Apr 27 11:06:59 2009 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E1B1065670 for ; Mon, 27 Apr 2009 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7E48FC2B for ; Mon, 27 Apr 2009 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3RB6xU5002380 for ; Mon, 27 Apr 2009 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3RB6xMb002376 for freebsd-pf@FreeBSD.org; Mon, 27 Apr 2009 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Apr 2009 11:06:59 GMT Message-Id: <200904271106.n3RB6xMb002376@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Apr 29 08:49:09 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534B51065670 for ; Wed, 29 Apr 2009 08:49:09 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id 8A76F8FC1E for ; Wed, 29 Apr 2009 08:49:08 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 17498 invoked from network); 29 Apr 2009 08:49:07 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by 10.0.98.3 with SMTP; 29 Apr 2009 08:49:06 -0000 Message-ID: <49F81481.3020609@sebster.com> Date: Wed, 29 Apr 2009 10:49:05 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Max Laier References: <49EFF732.3010402@sebster.com> <200904231559.13059.max@love2party.net> <49F07D1A.9010302@sebster.com> In-Reply-To: <49F07D1A.9010302@sebster.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010708080900090704080508" Cc: freebsd-pf@freebsd.org Subject: Re: "BAD ICMP" message X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:49:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010708080900090704080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sebastiaan van Erk wrote: > Hi, > > Thanks for the reply. > > Max Laier wrote: >> On Thursday 23 April 2009 07:05:54 Sebastiaan van Erk wrote: >>> Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP >>> 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679 >>> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] >>> 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0 >>> Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150 >> ^ >> >> These are ICMP redirect messages. This clearly suggests that >> something is very wrong with your routing. I assume your netmasks are >> wrong. It looks like 10.0.80.77 thinks that 10.0.80.150 can reach >> 10.0.80.4 directly which is not the case - it needs to route through >> 10.0.80.77. Actually, I finally figured out what was wrong. I accidentally told OpenVPN to "push 10.0.80.0/24 10.0.80.77", in other words, the client machine 10.0.80.150 tried to route though 10.0.80.77 even though it can reach it directly (since it's a bridged network). After removing the offending line, everything works. Something was definitely wrong with the routing though. :-) Regards, Sebastiaan > Here's a list of the entire setup: > > em0: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:4b > inet 111.111.111.111 netmask 0xfffffff0 broadcast 212.61.136.79 > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8943 metric 0 > mtu 1500 > options=98 > ether 00:0c:29:61:2a:55 > inet 10.0.80.77 netmask 0xffffff00 broadcast 10.0.80.255 > media: Ethernet autoselect (1000baseTX ) > status: active > em2: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:5f > inet 10.0.81.77 netmask 0xffffff00 broadcast 10.0.81.255 > media: Ethernet autoselect (1000baseTX ) > status: active > em3: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:69 > inet 10.0.82.77 netmask 0xffffff00 broadcast 10.0.82.255 > media: Ethernet autoselect (1000baseTX ) > status: active > plip0: flags=108810 metric 0 > mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > bridge0: flags=8843 metric 0 mtu > 1500 > ether f2:f4:c1:45:e7:50 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 2000000 > member: em1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 20000 > tap0: flags=8943 metric > 0 mtu 1500 > ether 00:bd:96:02:00:00 > Opened by PID 1310 > carp0: flags=49 metric 0 mtu 1500 > inet 111.111.111.112 netmask 0xfffffff0 > carp: MASTER vhid 1 advbase 1 advskew 0 > carp1: flags=49 metric 0 mtu 1500 > inet 10.0.80.74 netmask 0xffffff00 > carp: MASTER vhid 2 advbase 1 advskew 0 > carp2: flags=49 metric 0 mtu 1500 > inet 10.0.81.74 netmask 0xffffff00 > carp: MASTER vhid 3 advbase 1 advskew 0 > carp3: flags=49 metric 0 mtu 1500 > inet 10.0.82.74 netmask 0xffffff00 > carp: MASTER vhid 4 advbase 1 advskew 0 > pflog0: flags=141 metric 0 mtu 33160 > > em0 is the external interface, em1 is the vpn interface, and em2 and em3 > have production machines on them... > > The tap0 is the interface used by openvpn. It is bridged in bridge0 to > the internal em1 network. Since it is bridged, my feeling says that the > two VPN clients (10.0.80.4 and 10.0.80.150) should be able to talk > directly to eachother. I have no idea why my linux box (10.0.80.150) > thinks it can't directly talk to the other vpn client and talks via the > gateway instead. I get a lot of these ICMP redirects on tap0: > > # tcpdump -ni tap0 icmp > tcpdump: WARNING: tap0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes > 16:32:51.719979 IP 10.0.80.77 > 10.0.80.150: ICMP redirect 10.0.80.4 to > host 10.0.80.4, length 60 > > I'm sure I'm doing something wrong somewhere, but I can't quite figure > it out. > > Regards, > Sebastiaan > --------------ms010708080900090704080508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyOTA4NDkwNVowIwYJKoZI hvcNAQkEMRYEFPbDXyzcZ1W3n+juQ7d29T9yI6lPMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEAm+XOEb9Q+JtcH2UM r8zX1w0xZiYQ7Lqj1k8n0Q81XmZcLnm1x+JUhvjin62U5U0NQAM3Es/1UIE/5ySPB6R82E7T CjnnBU8iJ9kQo6ndY2FlJI0hP36Sr1z4vroZXYKAteZHlXA/L2wRibCb7Ul9ZblXISlaxvgL zGs7Gk0oCILsztBkNXJ1sWgFp/kHUt4K/deqNBAb9qDABV6c2jzG8h6J7foW19Gk9Tu5vAll zlyU043ENIQoEaB4QKv/Ky0ymVfQ3jTxZV4L8cEJFne5cIRThkZdvu1TmWCszSh63EoxzhcI pn5al19br3SZOYSNB+TjiwdNCwEgwM2UBNQ0tAAAAAAAAA== --------------ms010708080900090704080508-- From owner-freebsd-pf@FreeBSD.ORG Fri May 1 08:39:28 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38EE31065676 for ; Fri, 1 May 2009 08:39:28 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by mx1.freebsd.org (Postfix) with ESMTP id EA8618FC14 for ; Fri, 1 May 2009 08:39:27 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by gxk11 with SMTP id 11so620827gxk.19 for ; Fri, 01 May 2009 01:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=y+O5vZrl90+R/0UGM61suKYVIdFCYlEro8zPoiCxpns=; b=LVtUVeBZPINLHxMSTUiJI6kX2McTls1AeRaUjjkYidlPQvxo1L6gJl8f4owpE7KDl6 j9MaUZFAeVfnhhXdu4tU0Gvo4IsPBxIWFcAnvwvVdmWyOSkPP6D/bqGITIcgO2IKdHdN xJ2BklitMmA8Quz15iUoFi+RhPkZvximlHxu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=GX6kno6pqsv5SJBUca2aBXls29nxkgp93wZA1bcxnkTM2Uj/LEinRbbGNp6hx0pXbv JDByURkMnCKNwaL5Zd0v7kuDtGOFzhyzqGFhd/jyYAe/oDxwEVfuiBCSXpxRVjDJo0DX dU1/xw8ho9xxD8qvo2QnF85aXMC1k0ZeDCrLo= MIME-Version: 1.0 Received: by 10.151.69.7 with SMTP id w7mr5379367ybk.10.1241166835249; Fri, 01 May 2009 01:33:55 -0700 (PDT) Date: Fri, 1 May 2009 18:33:55 +1000 Message-ID: <736c47cb0905010133l62859430u813ef04d754f7218@mail.gmail.com> From: Sam Wun To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: PF rules blocking incoming traffic originated from my port 25. - repost witih consistent IP address X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:39:28 -0000 Hi guys, OS: FreeBSD 6.2. I don't know what happened with my PF rules. I tried to send email from the webmail installed in this freebsd box. >From the log, it said my PF rule is blocking: tcpdump -n -e -ttt -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 2. 994216 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 971917 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 2. 229844 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 3. 197738 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 ... scrub in all fragment reassemble block drop in log on ! em0 inet from 1.2.3.200/29 to any block drop in log on ! em0 inet from 1.2.3.200/29 to any block drop in log inet from 1.2.3.202 to any block drop in log inet from 1.2.3.206 to any block drop in log all block drop in log quick on em0 inet from 127.0.0.0/8 to any block drop in log quick on em0 inet from 192.168.0.0/16 to any block drop in log quick on em0 inet from 172.16.0.0/12 to any block drop in log quick on em0 inet from 10.0.0.0/8 to any block drop in log quick on em0 inet from 169.254.0.0/16 to any block drop in log quick on em0 inet from 192.0.2.0/24 to any block drop in log quick on em0 inet from 0.0.0.0/8 to any block drop in log quick on em0 inet from 240.0.0.0/4 to any block drop out log quick on em0 inet from any to 127.0.0.0/8 block drop out log quick on em0 inet from any to 192.168.0.0/16 block drop out log quick on em0 inet from any to 172.16.0.0/12 block drop out log quick on em0 inet from any to 10.0.0.0/8 block drop out log quick on em0 inet from any to 169.254.0.0/16 block drop out log quick on em0 inet from any to 192.0.2.0/24 block drop out log quick on em0 inet from any to 0.0.0.0/8 block drop out log quick on em0 inet from any to 240.0.0.0/4 block drop in log quick on em0 from to any block drop out log quick on em0 from any to block drop in log quick on em0 from to any block drop out log quick on em0 from any to pass in on em0 inet proto tcp from any to 1.2.3.202 port = ssh keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = ssh keep state pass in on em0 inet proto tcp from any to 1.2.3.202 port = domain keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = domain keep state pass in on em0 inet proto tcp from any to 1.2.3.202 port = imap keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = imap keep state pass in on em0 inet proto tcp from any to 1.2.3.202 port = smtp keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = smtp keep state pass in on em0 inet proto tcp from any to 1.2.3.202 port = https keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = https keep state pass in on em0 inet proto udp from any to 1.2.3.202 port = domain pass in on em0 inet proto udp from any to 1.2.3.206 port = domain pass in on em0 inet proto tcp from any to 1.2.3.202 port = 8080 keep state pass in on em0 inet proto tcp from any to 1.2.3.206 port = 8080 keep state pass out on em0 proto tcp all keep state pass out on em0 proto udp all keep state pass out on em0 inet proto udp from any to any port 33433 >< 33626 keep state From owner-freebsd-pf@FreeBSD.ORG Fri May 1 08:59:23 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC27106566B for ; Fri, 1 May 2009 08:59:23 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by mx1.freebsd.org (Postfix) with ESMTP id 57A528FC15 for ; Fri, 1 May 2009 08:59:23 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by gxk11 with SMTP id 11so629180gxk.19 for ; Fri, 01 May 2009 01:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=57Z/3tgvGVBOVQhTO0x5wWKtfVCtNpE8WhtWnyPKvc0=; b=Qft8T3vOkLqKbq4vAKJ2EC2P53pmhDz6sJIRfwxOgLaZW1o1WPKWGbS4Fc8Lu7nGsP 95wVLE1bhwx7lIQjejCp8AAfw9qN/xY4mFLRAsDjAa+nOJwVwe1THbNnAB6CzxIittzU VBzU9ctvSELrKAWu4kY4lhdgSMvdGLuD03cNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=gMYck3gRiMZPh9hhSIZuzpUjxBr6Efe0u1y8MFmrJ+PlDpHvms3cYKbnrHkv6q2VSk vD1OheyU29xlwf7u2alTJ+N5g2hGaH6NXzk4Vq2ywIRsgVbXf87bgUcKLcM+TBr/AGD0 SaL93qqNEGCAbnoRK0c1mhCSKdrhonjoSWY/U= MIME-Version: 1.0 Received: by 10.151.136.4 with SMTP id o4mr5354581ybn.115.1241166545431; Fri, 01 May 2009 01:29:05 -0700 (PDT) Date: Fri, 1 May 2009 18:29:05 +1000 Message-ID: <736c47cb0905010129k18f834aex9f1484cbf1f7e02e@mail.gmail.com> From: Sam Wun To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: PF rules blocking incoming traffic originated from my port 25. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:59:23 -0000 Hi guys, OS: FreeBSD 6.2. I don't know what happened with my PF rules. I tried to send email from the webmail installed in this freebsd box. >From the log, it said my PF rule is blocking: tcpdump -n -e -ttt -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 2. 994216 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 971917 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 2. 229844 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 3. 197738 rule 4/0(match): block in on em0: 209.85.217.27.25 > 1.2.3.206.50725: S 1649853456:1649853456(0) ack 2736129674 win 5792 ... My PF rules shown as below: scrub in all fragment reassemble block drop in log on ! em0 inet from 1.2.3.4/29 to any block drop in log on ! em0 inet from 1.2.3.6/29 to any block drop in log inet from 1.2.3.4 to any block drop in log inet from 1.2.3.6 to any block drop in log all block drop in log quick on em0 inet from 127.0.0.0/8 to any block drop in log quick on em0 inet from 192.168.0.0/16 to any block drop in log quick on em0 inet from 172.16.0.0/12 to any block drop in log quick on em0 inet from 10.0.0.0/8 to any block drop in log quick on em0 inet from 169.254.0.0/16 to any block drop in log quick on em0 inet from 192.0.2.0/24 to any block drop in log quick on em0 inet from 0.0.0.0/8 to any block drop in log quick on em0 inet from 240.0.0.0/4 to any block drop out log quick on em0 inet from any to 127.0.0.0/8 block drop out log quick on em0 inet from any to 192.168.0.0/16 block drop out log quick on em0 inet from any to 172.16.0.0/12 block drop out log quick on em0 inet from any to 10.0.0.0/8 block drop out log quick on em0 inet from any to 169.254.0.0/16 block drop out log quick on em0 inet from any to 192.0.2.0/24 block drop out log quick on em0 inet from any to 0.0.0.0/8 block drop out log quick on em0 inet from any to 240.0.0.0/4 block drop in log quick on em0 from to any block drop out log quick on em0 from any to block drop in log quick on em0 from to any block drop out log quick on em0 from any to pass in on em0 inet proto tcp from any to 125.255.112.202 port = ssh keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = ssh keep state pass in on em0 inet proto tcp from any to 125.255.112.202 port = domain keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = domain keep state pass in on em0 inet proto tcp from any to 125.255.112.202 port = imap keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = imap keep state pass in on em0 inet proto tcp from any to 125.255.112.202 port = smtp keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = smtp keep state pass in on em0 inet proto tcp from any to 125.255.112.202 port = https keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = https keep state pass in on em0 inet proto udp from any to 125.255.112.202 port = domain pass in on em0 inet proto udp from any to 125.255.112.206 port = domain pass in on em0 inet proto tcp from any to 125.255.112.202 port = 8080 keep state pass in on em0 inet proto tcp from any to 125.255.112.206 port = 8080 keep state pass out on em0 proto tcp all keep state pass out on em0 proto udp all keep state pass out on em0 inet proto udp from any to any port 33433 >< 33626 keep state Can anybody please shed some lights on this problem? Thanks