headers
David Walker | 5 Aug 2012 15:50
Picon

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.
Permalink | Reply |
headers
Daniel Melameth | 5 Aug 2012 16:14

Re: Suspect fragmented packets.

On Sun, Aug 5, 2012 at 7:50 AM, David Walker <davidianwalker <at> 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.
(Continue reading)

Permalink | Reply |
headers
David Walker | 5 Aug 2012 17:24
Picon

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.
Permalink | Reply |
headers
Remi Locherer | 5 Aug 2012 21:36
Picon

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
Permalink | Reply |
headers
Daniel Melameth | 6 Aug 2012 02:36

Re: Suspect fragmented packets.

On Sun, Aug 5, 2012 at 9:24 AM, David Walker <davidianwalker <at> 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.
(Continue reading)

Permalink | Reply |
headers
David Walker | 6 Aug 2012 10:12
Picon

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.
Permalink | Reply |
headers
David Walker | 6 Aug 2012 10:19
Picon

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.
Permalink | Reply |
headers
Stuart Henderson | 6 Aug 2012 10:45
Favicon
Gravatar

Re: Suspect fragmented packets.

On 2012-08-06, David Walker <davidianwalker <at> 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.
Permalink | Reply |

Gmane