Date: Tue, 31 Mar 2020 23:03:05 -0600 From: Gary Aitken <freebsd@dreamchaser.org> To: Norman Gray <norman.gray@glasgow.ac.uk> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: weird 403 (forbidden) website access issue Message-ID: <f3a7de61-162a-1196-eae1-16bd22124ebb@dreamchaser.org> In-Reply-To: <1f345a1d-f0c8-688c-c3e5-3a6b09ff1fa9@dreamchaser.org> References: <ba457b4a-3362-d9e0-4b8a-c6204937819d@dreamchaser.org> <B11EF1EF-FF36-4DD9-9996-2643B177CDA7@glasgow.ac.uk> <1f345a1d-f0c8-688c-c3e5-3a6b09ff1fa9@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/31/20 5:20 PM, Gary Aitken wrote: > On 3/31/20 3:12 PM, Norman Gray wrote: ... >> On 31 Mar 2020, at 21:33, Gary Aitken wrote: >> >>> The addr (www.ovandoschool.org) resolves to 69.175.87.226 >>> >>> If I type in 69.175.87.226 in the address bar, I get a 403 error with a note 69.175.87.226/cp_errordocument.shtml (port 80) Seems to >>> be accessible fine from windows machines going through the same fbsd 11.3-RELEASE-P6 gateway (not the same system as the one with >>> the browser having the problem). >>> >>> If I manually access from the failing fbsd system, it works: >>> >>> $ telnet 69.175.87.226 80 Trying 69.175.87.226... Connected to >>> chi-node42.websitehostserver.net. Escape character is '^]'. GET / >>> HTTP/1.1 Host: www.ovandoschool.org >> >> If you type the IP address in to the address bar, then the browser >> will either send that as the 'Host' request header, or won't send the >> header at all. Thus the server, presuming it's set up to serve >> multiple hosts, won't know which website to send back. > > Makes sense. ... > So the actual problem is the errors show up when the website url is > entered: http://www.ovandoschool.org/ > > I was using the IP to try to simplify the problem, but obviously that > won't work in this case. > > Since the site displays on windows machines when using the proper url, > but not on the fbsd machine, it feels like something messed up in my > fbsd environment. > > A tcpdump from the gateway for a successful (windows) access shows: > > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [S], seq 983728199, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], lengt > h 0 > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [S.], seq 4210427857, ack 983728200, win 29200, options [mss 1400,nop,nop,sackOK,no > p,wscale 7], length 0 > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [.], ack 1, win 16450, length 0 > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [P.], seq 1:375, ack 1, win 16450, length 374: HTTP: GET / HTTP/1.1 > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [.], ack 375, win 237, length 0 > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [.], seq 1:1401, ack 375, win 237, length 1400: HTTP: HTTP/1.1 200 OK > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [.], seq 1401:2801, ack 375, win 237, length 1400: HTTP > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [P.], seq 2801:2850, ack 375, win 237, length 49: HTTP > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [P.], seq 2850:3109, ack 375, win 237, length 259: HTTP > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [P.], seq 3109:3114, ack 375, win 237, length 5: HTTP > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [.], ack 3114, win 16450, length 0 > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [P.], seq 375:814, ack 3114, win 16450, length 439: HTTP: GET /wp-content/themes/tw > entythirteen/fonts/genericons.css?ver=2.09 HTTP/1.1 > > On the machine that fails, the tcpdump on the gateway shows: > > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [S], seq 1576349922, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 336582 > 5370 ecr 0], length 0 > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [S.], seq 4093820683, ack 1576349923, win 28960, options [mss 1400,sackOK,TS val 25 > 42931075 ecr 3365825370,nop,wscale 7], length 0 > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [.], ack 1, win 1028, options [nop,nop,TS val 3365825433 ecr 2542931075], length 0 > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [P.], seq 1:341, ack 1, win 1028, options [nop,nop,TS val 3365825523 ecr 2542931075 > ], length 340: HTTP: GET / HTTP/1.1 > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [.], ack 341, win 235, options [nop,nop,TS val 2542931231 ecr 3365825523], length 0 > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [P.], seq 1:1048, ack 341, win 235, options [nop,nop,TS val 2542931232 ecr 33658255 > 23], length 1047: HTTP: HTTP/1.1 403 Forbidden > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [.], ack 1048, win 1028, options [nop,nop,TS val 3365825697 ecr 2542931232], length > 0 > ... > I'm out of my depth here... > (Aside: What's with the incorrect checksum flags?) > Comparing the gateway dumps, the difference is in the first four lines. > I've interlaced them below, with the lines from the successful request first: > > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [S], seq 983728199, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [S], seq 1576349922, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3365825370 ecr 0], length 0 > > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [S.], seq 4210427857, ack 983728200, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0 > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [S.], seq 4093820683, ack 1576349923, win 28960, options [mss 1400,sackOK,TS val 2542931075 ecr 3365825370,nop,wscale 7], length 0 > > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [.], ack 1, win 16450, length 0 > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [.], ack 1, win 1028, options [nop,nop,TS val 3365825433 ecr 2542931075], length 0 > > IP 66.109.141.60.55271 > 69.175.87.226.80: Flags [P.], seq 1:375, ack 1, win 16450, length 374: HTTP: GET / HTTP/1.1 > IP 66.109.141.62.12350 > 69.175.87.226.80: Flags [P.], seq 1:341, ack 1, win 1028, options [nop,nop,TS val 3365825523 ecr 2542931075], length 340: HTTP: GET / HTTP/1.1 > > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [.], ack 375, win 237, length 0 > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [.], ack 341, win 235, options [nop,nop,TS val 2542931231 ecr 3365825523], length 0 > > IP 69.175.87.226.80 > 66.109.141.60.55271: Flags [.], seq 1:1401, ack 375, win 237, length 1400: HTTP: HTTP/1.1 200 OK > IP 69.175.87.226.80 > 66.109.141.62.12350: Flags [P.], seq 1:1048, ack 341, win 235, options [nop,nop,TS val 2542931232 ecr 3365825523], length 1047: HTTP: HTTP/1.1 403 Forbidden How likely is it that the small window size (1028) in the 4th pair (HTTP: GET request) is causing the server to refuse the request? If so, is this a firefox issue or an underlying tcp issue? Thanks, Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f3a7de61-162a-1196-eae1-16bd22124ebb>