Re: Suspect fragmented packets.
Remi Locherer remi.locherer () relo ! ch The MSS field from your syn packages tells the other side what max package size you accept. I found this white paper helpful to understand MTU, PMTUD and MSS: You are apparently correct. This doesn't help: match in all scrub (no-df) This does help: match in all scrub (no-df max-mss 1440) Thanks for the link. Best wishes.
Re: Suspect fragmented packets.
Daniel Melameth daniel () melameth ! com What have you tried? MSS probably incorrectly. I had a 4.9 install I think with a lot of rules but I've started from scratch with 5.1 over the weekend and I think I've got it now. TCP negotiates MSS so a TCP session will never have an MSS higher than what one side can accept. Thanks. That makes sense. Interestingly this is the exact setup that ran with the previous ISP so presumably they handled all that within their network and passed on packets somewhat smaller than 1500 to me. I never had to reassemble packets or scrub them or negotiate size. There is no default block of ICMP. As a matter of fact, unlike some other poor firewall implementations that break PMTU (and this might be what you are experiencing with some hosts), you cannot configure pf to block ICMP for an existing state. Thanks. I was thinking of ICMP from internal clients which is obviously a different matter. Best wishes.
Re: Suspect fragmented packets.
On 2012-08-06, David Walker davidianwal...@gmail.com wrote: Interestingly this is the exact setup that ran with the previous ISP so presumably they handled all that within their network and passed on packets somewhat smaller than 1500 to me. I never had to reassemble packets or scrub them or negotiate size. Some (but not many) ISPs do ip tcp adjust-mss or similar on their side of the pppoe connection.
Suspect fragmented packets.
Hi. I've had a bridged modem and OpenBSD gateway setup for years on a particular Australian ISP. I've never re-assembled packets and worried over MTU or fragments. Everything just worked ... Recently one of the companies I work for changed ISP. I swapped the relevant details on the gateway, hostname.pppoe0 and whatnot, and it seems that a significant portion of the web is inaccessible, most websites are accessible but many are not. DNS resolution seems fine for all domains and of the sites that won't work some of them will display a title in a browser on an internal client and that's it. Some of them will send all the html but ultimately not display. Most simply time out ... I've tred re-assembling packets but it doesn't help. I suspect I'm being sent fragmented packets with don't fragment set. Does this sound right? If this is right, could I achieve anything by explicitly allowing ICMP (datagram too large messages) expecting that the upstream hosts will set path MTU accordingly or is this a wasted effort. Either way, should I start re-assembling packets and scrubbing incoming and ignoring the don't fragment bit with no-df ... match in all scrub (no-df) Best wishes.
Re: Suspect fragmented packets.
On Sun, Aug 5, 2012 at 7:50 AM, David Walker davidianwal...@gmail.com wrote: I've had a bridged modem and OpenBSD gateway setup for years on a particular Australian ISP. I've never re-assembled packets and worried over MTU or fragments. Everything just worked ... Recently one of the companies I work for changed ISP. I swapped the relevant details on the gateway, hostname.pppoe0 and whatnot, and it seems that a significant portion of the web is inaccessible, most websites are accessible but many are not. DNS resolution seems fine for all domains and of the sites that won't work some of them will display a title in a browser on an internal client and that's it. Some of them will send all the html but ultimately not display. Most simply time out ... I've tred re-assembling packets but it doesn't help. I suspect I'm being sent fragmented packets with don't fragment set. Does this sound right? If this is right, could I achieve anything by explicitly allowing ICMP (datagram too large messages) expecting that the upstream hosts will set path MTU accordingly or is this a wasted effort. Either way, should I start re-assembling packets and scrubbing incoming and ignoring the don't fragment bit with no-df ... match in all scrub (no-df) When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue.
Re: Suspect fragmented packets.
Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? Does setting MSS on PPP and therefore MTU affect this? Do I need to explicitly allow ICMP to enable this behaviour? Regardless, we're able to talk to the web in general and get good responses from almost everyone. I suspect some are sending ill-formed packets back which is the reason why pf has the no-df option. I haven't had to deal with it previously, my earlier ISP apparently scrubbed and waxed my packets for me. With Internode, I explicitly overturned the default 'set reassemble' to no and avoided MSS (and MTU) considerations and didn't worry about fragments and bad df bits ... Everything worked ... but that's Internode. Best wishes.
Re: Suspect fragmented packets.
On Mon, Aug 06, 2012 at 12:54:48AM +0930, David Walker wrote: Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? Does setting MSS on PPP and therefore MTU affect this? Do I need to explicitly allow ICMP to enable this behaviour? The MSS field from your syn packages tells the other side what max package size you accept. I found this white paper helpful to understand MTU, PMTUD and MSS: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml Remi
Re: Suspect fragmented packets.
On Sun, Aug 5, 2012 at 9:24 AM, David Walker davidianwal...@gmail.com wrote: Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. What have you tried? As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. TCP negotiates MSS so a TCP session will never have an MSS higher than what one side can accept. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? There is no default block of ICMP. As a matter of fact, unlike some other poor firewall implementations that break PMTU (and this might be what you are experiencing with some hosts), you cannot configure pf to block ICMP for an existing state. Does setting MSS on PPP and therefore MTU affect this? Setting a max-mss via pf has little to do with ICMP. Do I need to explicitly allow ICMP to enable this behaviour? No--see above.
