Mogelijke oorzaken voor 'Connection Refused'?

[Spider.007]

Ik draai thuis een webserver waar iedereen op zou moeten kunnen. Nu kan ik er vanaf mijn werk echter niet bij. Ik krijg ik van de aldaar draaiende squid-proxy consistent een 'Connection Refused' (na een aantal minuten wachten). Het internetverkeer aldaar loopt via BBeyond; en mijn webserver hangt aan het XS4All netwerk.

Zowel de domeinnaam als het IP adres kan ik zonder problemen pingen of tracerouten. Ook een nmap geeft aan dat poort 80 netjes open staat. Telnetten er naartoe stopt ook bij het maken van de verbinding. tcpdump geeft weinig nuttige informatie. Wat zijn de mogelijke oorzaken dat een 'Connection Refused' optreedt? Uitgesloten zijn volgens mij:

• De webserver heeft het IP adres geblokkeerd (zou een Apache melding moeten opleveren)
• De router voor de webserver heeft het IP adres geblokkeerd (heb ik niet ingesteld)
• De Squid-proxy heeft het IP geblokkeerd (vanaf de proxy zelf werkt telnet ook niet; en zou ook een squid melding moeten opleveren 'blocked' oid)
• De provider (XS4All of BBeyond) blokkeert de toegang (dan zou een traceroute ook niet moeten werken)

Hebben jullie nog ideeen?

[neh]

Spider.007 schreef op zondag 03 juli 2005 @ 13:53:
• De provider (XS4All of BBeyond) blokkeert de toegang (dan zou een traceroute ook niet moeten werken)

Niet persé. XS4All kan ook bepaalde standaard poorten (zoals 80) blokkeren. Dan zou een traceroute prima werken.

Wat voor nmap opties heb je gebruikt? Als je een connect scan gebruikt, staat ie dan nog steeds op open?

Heb je een tcpdump dump?

[ Voor 18% gewijzigd door neh op 03-07-2005 13:59 ]

[Spider.007]

plork schreef op zondag 03 juli 2005 @ 13:57:
[...]


Niet persé. XS4All kan ook bepaalde standaard poorten (zoals 80) blokkeren. Dan zou een traceroute prima werken.

Uiteraard; de webserver is echter door iedereen probleemloos te benaderen; alleen 1 specifiek IP kan er niet bij.

Wat voor nmap opties heb je gebruikt? Als je een connect scan gebruikt, staat ie dan nog steeds op open?

De standaard nmap optie voor een non-root user is toch een connect scan? Hierop stond de poort gewoon als 'open' aangegeven

Heb je een tcpdump dump?

Nope; kan ik morgen evt wel maken

[neh]

Spider.007 schreef op zondag 03 juli 2005 @ 14:06:
[...]
De standaard nmap optie voor een non-root user is toch een connect scan? Hierop stond de poort gewoon als 'open' aangegeven

Die nmap, deed je die van de proxy machine of van een workstation erachter?

[...]

Nope; kan ik morgen evt wel maken

Dat zou wel interessant zijn ja. Heb je de mogelijkheid om de proxy uit te schakelen op je workstation eventueel?

[Spider.007]

plork schreef op zaterdag 09 juli 2005 @ 13:22:
[...]


Die nmap, deed je die van de proxy machine of van een workstation erachter?

Beiden gaven hetzelfde resultaat. Ook vanaf de proxy kon ik bijvoorbeeld geen wget doen

[...]


Dat zou wel interessant zijn ja. Heb je de mogelijkheid om de proxy uit te schakelen op je workstation eventueel?

Nope, het ding is transparant; maar als ik vanaf de proxy een wget uitvoer dan gaat dat al direct over het Internet; en niet meer via de proxy

[Koffie]

Wat voor inet pijp en hardware gebruik je precies ?
Dit komt mij namelijk zeeeer bekend voor, ook xs44all (fast) en een oude ST Home modem (tweaked), continue 404's terwijl er niets loos was, en ik keurig in een SSH verbinding bleef tussen dezelfde lijn.
Een vervanging van mijn modem loste al mijn probs in 1 keer op

edit:
Kom je er vanaf werk nu totaal nooit op, of met horten en stoten

[ Voor 11% gewijzigd door Koffie op 09-07-2005 20:48 ]

[Spider.007]

aan de kant van de server, mijn kant dus hang ik inderdaad aan een XS4All verbinding met standaard modem; aan de kant van de client gaat het over BBeyond. Ik heb consistent last van Connection Refused problemen op de 80-poort; andere poorten heb ik momenteel niet openstaan maar ik zou binnenkort eens SSH open kunnen gooien om te kijken of dat wel werkt.

[Koffie]

Kun je eens 2 tellen die B Beyond lijn in een laptoppie prikken en kijken wattie dan doet

[Spider.007]

Koffie schreef op zondag 10 juli 2005 @ 10:21:
Kun je eens 2 tellen die B Beyond lijn in een laptoppie prikken en kijken wattie dan doet

Gaan mijn collega's niet blij van worden denk ik Ik heb het al geprobeerd vanaf de gateway machine zelf (die dus ongefilterd aan de lijn hangt) en die gaf hetzelfde resultaat.

Ik gok er zelf nog steeds op dat BBeyond op één of andere manier het verkeer blokkeert; maar ik heb wel veel hits van bbeyond abonnees in mijn access_logs staan; dus het zou dan om een zeer selectieve blokkade gaan?

[elevator]

Spider.007 schreef op zondag 03 juli 2005 @ 13:53:
Telnetten er naartoe stopt ook bij het maken van de verbinding.

Je bedoelt hiermee dat na dat je 'telnet spider007.net' ingetypt hebt dat je blijft hangen op 'Trying ...' of krijg je daadwerkelijk een 'Connected to xx.xx.xx.xx' te zien?

[Spider.007]

elevator schreef op zondag 10 juli 2005 @ 10:46:
[...]

Je bedoelt hiermee dat na dat je 'telnet spider007.net' ingetypt hebt dat je blijft hangen op 'Trying ...' of krijg je daadwerkelijk een 'Connected to xx.xx.xx.xx' te zien?

Hij blijft hangen op het 'Connecting'; hij krijgt dus nooit een verbinding. Hetzelfde gebeurt de proxyserver die na 10 minuten een Connection Refused geeft (maar ook hij krijgt dus nooit een verbinding)

[GlowMouse]

Waarschijnlijk een foutje van elevator wat jij over het hoofd hebt gezien: 'telnet spider007.net' moet 'telnet spider007.net 80' zijn. Op poort 23 (telnet) zit niks.

[Spider.007]

GlowMouse schreef op zondag 10 juli 2005 @ 10:56:
Waarschijnlijk een foutje van elevator wat jij over het hoofd hebt gezien: 'telnet spider007.net' moet 'telnet spider007.net 80' zijn. Op poort 23 (telnet) zit niks.

Nee hoor; ik begreep perfect wat ele bedoelde en reageerde daarop. Uiteraard draait er bij mij geen telnetd; en heb ik een `telnet spider007.net 80` uitgevoerd

[elevator]

Gebruik jij toevallig een soort van 'IANA-reserved-ipaddr-list' filtering? Oftewel - heb je hele reeksen addressen in je filter staan die zogenaamd reserved zijn maar dat misschien tegenwoordig niet meer zijn?

[Spider.007]

elevator schreef op zondag 10 juli 2005 @ 23:42:
Gebruik jij toevallig een soort van 'IANA-reserved-ipaddr-list' filtering? Oftewel - heb je hele reeksen addressen in je filter staan die zogenaamd reserved zijn maar dat misschien tegenwoordig niet meer zijn?

voor zover ik weet pas ik geen enkele filtering toe op de toegang tot mijn webserver. Ieder IP adres of hostname zou deze zonder problemen moeten kunnen benaderen. Ook in mijn router heb ik dergelijke filteringen nooit toegepast

[Spider.007]

Goed; misschien zien jullie er nog wat bijzonders aan? Ik niet in ieder geval. SSH'en werkt wel zonder problemen trouwens

code:

traceroute to spider007.net (213.84.115.196) from *****, 30 hops max, 38 byte packets
 1  *****.static.bbeyond.nl (*****)  20.857 ms  1.166 ms  2.397 ms
 2  ***** (*****)  11.753 ms  58.766 ms  66.791 ms
 3  asdhem1rip01.bbned.nl (62.177.131.1)  19.155 ms  109.523 ms  66.324 ms
 4  asdhem1rtr01.bbned.nl (62.177.131.74)  67.888 ms  10.109 ms  11.537 ms
 5  asdtel1rtr01.bbned.nl (62.177.143.254)  99.418 ms  409.158 ms  11.180 ms
 6  ams-ix.tc2.xs4all.net (195.69.144.166)  19.455 ms *  15.510 ms
 7  0.so-7-0-0.xr1.d12.xs4all.net (194.109.5.9)  60.841 ms 0.so-7-0-0.xr2.d12.xs4all.net (194.109.5.13)  32.692 ms 0.so-7-0-0.xr1.d12.xs4all.net (194.109.5.9)  125.097 ms
 8  42.10ge11-0-0.pe10.fia.xs4all.net (194.109.5.42)  17.921 ms 42.10ge11-0-0.pe20.fia.xs4all.net (194.109.5.50)  14.295 ms 42.10ge11-0-0.pe10.fia.xs4all.net (194.109.5.42)  9.245 ms
 9  195.190.250.17 (195.190.250.17)  15.180 ms  63.235 ms  68.476 ms
10  spider007.net (213.84.115.196)  88.401 ms  124.616 ms  128.061 ms

code:

root@host:~# tcpdump -i eth1 host 213.84.115.196
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
17:22:59.792109 IP *****.static.bbeyond.nl.35266 > spider007.net.http: SWE 2426270868:2426270868(0) win 5840 <mss 1460,sackOK,timestamp 52070278 0,nop,wscale 0>
17:23:02.791956 IP *****.static.bbeyond.nl.35266 > spider007.net.http: SWE 2426270868:2426270868(0) win 5840 <mss 1460,sackOK,timestamp 52070578 0,nop,wscale 0>
17:23:08.791948 IP *****.static.bbeyond.nl.35266 > spider007.net.http: SWE 2426270868:2426270868(0) win 5840 <mss 1460,sackOK,timestamp 52071178 0,nop,wscale 0>

3 packets captured
3 packets received by filter
0 packets dropped by kernel

[neh]

Spider.007 schreef op maandag 11 juli 2005 @ 17:31:
Goed; misschien zien jullie er nog wat bijzonders aan? Ik niet in ieder geval. SSH'en werkt wel zonder problemen trouwens

3 keer wordt een SYN verstuurd, zonder dat jouw server wat voor soort response dan ook terugstuurt. Je weet 100% zeker dat aan geen van beide kanten packet filters oid actief zijn?

Wat een mogelijkheid is is dat bbeyond bepaalde packet filters actief heeft om (bv.) http toegang naar IP reeksen van ISP's te blokkeren waar klanten op zitten, ivm verspreiding van code red achtige wormen, etc. Misschien dat je contact met ze op kunt nemen om dat te checken?

Wat je kunt proberen is eens via de proxy van bbeyond verbinden met jouw site en kijken of dat werkt.

[Hans]

bbeyond heeft afaik geen proxy en blokkeert ook geen poorten

connect met spider007.net over de XS4ALL lijn die we hier ook hebben liggen resulteert in precies hetzelfde (nml niks ), dus het probleem ligt wmb 100% niet aan onze kant.

dikke pech spinnemans

[axis]

Spider.007 schreef op zondag 10 juli 2005 @ 10:37:
[...]
Gaan mijn collega's niet blij van worden denk ik Ik heb het al geprobeerd vanaf de gateway machine zelf (die dus ongefilterd aan de lijn hangt) en die gaf hetzelfde resultaat.

Enne, misschien een keer na werktijd dat kabeltje in je laptopje prikken?

[Spider.007]

Hans schreef op dinsdag 12 juli 2005 @ 13:22:
bbeyond heeft afaik geen proxy en blokkeert ook geen poorten

connect met spider007.net over de XS4ALL lijn die we hier ook hebben liggen resulteert in precies hetzelfde (nml niks ), dus het probleem ligt wmb 100% niet aan onze kant.

dikke pech spinnemans

Ik kan wel SSH'en; dat gaat ook over de XS4All lijn en dat gaat dus wel goed. Volgens mij was het niet gelukt HTTP verkeer over de XS4All lijn te sturen; dus dat is wmb nog redelijk ongetest Ik weet iig dat het probleem ook niet aan mijn kant ligt; dus dan blijven de providers ertussenin nog over als enige mogelijkheid

[ Voor 6% gewijzigd door Spider.007 op 19-07-2005 08:40 ]