Date: Wed, 07 May 2008 19:43:02 -0400 From: Jon Radel <jon@radel.com> To: Jille <jille@quis.cx>, Ansar Mohammed <ansarm@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: UDP weirdness Message-ID: <48223E86.5010603@radel.com> In-Reply-To: <482215F4.1080806@quis.cx> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms050804050306030104010406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jille wrote: > > > > Ansar Mohammed schreef: >> Ok, so adding the line as you suggested worked. Thanks Kevin. >> >> But why do I need to have both entries in for >> pass in proto udp from any to any port 53 >> pass out proto udp from any to any port 53 >> >> what makes UDP so special? > UDP is stateless, > With TCP you've got an connection (identified by: local host:port and > remote host:port) > With UDP, well, you just trow the packages over the line, and hope the > is (still) someone on the other end. > > So the is (almost) no way to detect whether packets are responses to > eachother Other than looking at local host:port and remote host:port and matching things up.... Which PF does just fine ordinarily. (Only exception I can think of right now is if you're using a TFTP server which actually implements the RFC rather than breaking it to make firewalls work....) Current versions also match ICMP up with other traffic with which it is associated. But this has already been addressed in another reply. I have reread this thread and can't find any indication of which version of PF is running. This makes it rather hard to comment on whether a "keep state" would make things better, though I suspect you're using FreeBSD 7.x. So what follows are some thoughts which may or may not apply to your implementation. (Somebody else has already pointed out when the default for keep state changed.) pass in proto udp from any to any port 53 pass out proto udp from any to any port 53 can be combined into pass proto udp from any to any port 53 If the rule set is complete as presented: > > ext_if="le0" > > int_if="le1" > > int_net="192.168.3.0/24" > > ext_net="192.168.2.0/24" > > int_addr="192.168.3.1" > > ext_addr="192.168.2.2" > > scrub on $ext_if all reassemble tcp > > scrub on $int_if all reassemble tcp > > block in log all > > pass in proto icmp from any to any > > pass in proto udp from any to any port 53 > > pass in on $ext_if inet proto tcp from any to any port 3389 then you're making use of the default action of "pass" on all outbound traffic. I wouldn't recommend doing that, particularly on a firewall. To be specific, my firewall rulesets tend to start with block log all If you do that, then you need to do something such as pass in on $int_if proto udp from any to any port 53 [keep state] pass out on $ext_if proto udp all [keep state] if you want machines on the inside to initiate DNS queries, which are allowed to pass in on the internal interface and then out on the external interface. If you want DNS queries to be allowed in both directions (you have an authoritative DNS server on the inside, or something...) you'd want something like pass in proto udp from any to any port 53 [keep state] pass out proto udp all [keep state] and that would cover both directions. In writing this I am struck by an interesting question: Is there a possibility that what you're running into is a difference in the default keep state behavior in the default pass rule between UDP and TCP. The documentation I've looked at has been silent on whether the default pass rule is expected to establish state (for versions of PF recent enough), and I'm not quite curious enough to build a testbed right now. If anyone knows the answer to this one, please do share. :-) --Jon Radel --------------ms050804050306030104010406 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA1MDcyMzQzMDJaMCMGCSqGSIb3DQEJBDEWBBSxwB0T93R9sKOsATLaaKk2nC6aZzBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAxxqE IuMAu4dnNtdd3G7V46eCEYtyosKIJ2iCV7SE3uFtGGFOMHbxdgt8qi44hORrOQ5t0pD5dblk Dpxa2/nD19RCciS403SjbWI3GgAExCBSBm/jaZzsN9qPp2X1cEalyHKuJEplcxs5tCHvjoE6 dmfEVDiU8G+0BMSHKnORTIMkp9GZ2xti3+jYavYK6mfFnO0FJeWGpXpjtMtQkHowmLtAhblk 0XMV1CQx4NmKzHIdeLKb/UXkNWNRZMGfFFe3ep8ZmzjvWlNwSFEDgeTHVbgpfT5pi8Nhv7NQ s3xZf+okuRCi50KOCgt1znP+nF59kkPP/j/7/8PuIrmv2oz5hAAAAAAAAA== --------------ms050804050306030104010406--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48223E86.5010603>