Onderwerp: Webserver niet bereikbaar vanaf klant en public wifi datacenter

Oorspronkelijk geplaatst door visser

Met de gegeven informatie ligt dat voor de hand, inderdaad.
Maar als de bereikbare en onbereikbare servers in een ander netwerk segment zitten is een routing issue natuurlijk niet uitgesloten.

Maar als TS niet meer informatie wil geven duurt het alleen maar langer om wat te gokken naar de oorzaak. Afijn, zijn probleem.

Welke informatie zou je willen hebben? wellicht dat ik je die kan geven.

Heeft er toch alle schijn van dat de firewall de issue is. Probeer die ip's eens te whitelisten anders?

Oorspronkelijk geplaatst door Exqua

Welke informatie zou je willen hebben? wellicht dat ik je die kan geven.

Wat zou helpen zijn
ip,subnetmask,gateway van hosts achter de firewall
ip,subnetmask,gateway van de host 'buiten' de firewall

ip,subnetmask,gateway van een wifi client die de gefirewallde hosts niet kan bereiken

traceroute vanaf wifi client naar gefirewallde en niet gefirewallde (werkende) host

Er zijn een aantal netwerk structuren te verzinnen bij je omschrijving, en de plek waar het probleem kan zitten verschilt afhankelijk van wat het is.

Als werkende en gefirewallde hosts in een heel ander subnet zitten, kan het hele pad (inclusief een routing of firewall issue in het datacenter domein) anders zijn.
Als het wifi net eventueel een (centrale) NAT /firewall gebruikt en er toevallig verkeer naar de niet-werkende setup voordien al 'ontsnapt' (met rfc1918 source ) wat dan (terecht) tegengehouden wordt.
Om maar iets te noemen.

Met een beeld van de topologie kun je gericht zoeken (cq - kan ik, of iemand) gericht suggesties geven waar te zoeken in plaats van met hagel te schieten naar duizend en één manieren waarop iets in elkaar zou kunnen zitten.

Wat soms ook nog wel eens wil voorkomen dat je DNS servers niet sync met elkaar zijn hierdoor kan het gebeuren dat de ene provider bijvoorbeeld NS1 gebruikt en een andere provider NS2. Even met dig/nslookup direct bij je nameservers controleren welke antwoorden ze geven.

Ip whithlisten of je firewall kort bypassen en dan checken of t wel lukt


Verzonden vanaf mijn iPhone met behulp van webhostingtalk

Oorspronkelijk geplaatst door Exqua

Ipv6 maken we geen gebruik van op dit moment.

Dat dacht ik ook. Maar de DNS had daar een ander idee over...

Oorspronkelijk geplaatst door visser

Wat zou helpen zijn
ip,subnetmask,gateway van hosts achter de firewall
ip,subnetmask,gateway van de host 'buiten' de firewall

ip,subnetmask,gateway van een wifi client die de gefirewallde hosts niet kan bereiken

traceroute vanaf wifi client naar gefirewallde en niet gefirewallde (werkende) host

Er zijn een aantal netwerk structuren te verzinnen bij je omschrijving, en de plek waar het probleem kan zitten verschilt afhankelijk van wat het is.

Als werkende en gefirewallde hosts in een heel ander subnet zitten, kan het hele pad (inclusief een routing of firewall issue in het datacenter domein) anders zijn.
Als het wifi net eventueel een (centrale) NAT /firewall gebruikt en er toevallig verkeer naar de niet-werkende setup voordien al 'ontsnapt' (met rfc1918 source ) wat dan (terecht) tegengehouden wordt.
Om maar iets te noemen.

Met een beeld van de topologie kun je gericht zoeken (cq - kan ik, of iemand) gericht suggesties geven waar te zoeken in plaats van met hagel te schieten naar duizend en één manieren waarop iets in elkaar zou kunnen zitten.

Bedankt voor de heldere informatie.

Hosts achter de firewall:
IP's Intern: 192.168.1.10 tot 192.168.1.50
Netmask intern: 255.255.255.0
Gateway intern:192.168.1.1

webserver ip: 80.69.84.144 (buitenkant)
webserver ip: intern een adres binnen de reeks hierboven
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66

Host buiten de firewall:
IP: 80.69.84.142
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66

Ik hoop dat ik het zo goed heb beschreven.
Voor de overige informatie zal ik in deze dagen even naar het datacenter moeten.
Ik heb eventueel wel een traceroute van mijn firewall server naar de klant maar weet niet of dat relevant is.

Traceroute output for 80.56.89.38:

1 v984.router1.dcg.transip.net (80.69.84.221) 54.429 ms 0.310 ms 0.440 ms
2 ibgp.router2.dcga.ams.transip.net (87.253.141.250) 0.437 ms 0.270 ms 0.346 ms
3 transip.customer.openpeering.nl (82.150.154.57) 9.374 ms 0.569 ms 0.691 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.836 ms 0.936 ms 0.788 ms
5 84.116.136.29 (84.116.136.29) 5.681 ms
84.116.134.114 (84.116.134.114) 5.509 ms 5.696 ms
6 84.116.244.70 (84.116.244.70) 6.495 ms 6.169 ms 6.225 ms
7 212.142.56.230 (212.142.56.230) 7.682 ms 7.607 ms 7.676 ms
8 * * *
9 * * *
10 * * *
11 * * *

Voor de vergelijking staat hieronder een traceroute naar mijn eigen huis (ook UPC)

Traceroute output for 89.99.215.171:

1 v984.router1.dcg.transip.net (80.69.84.221) 0.316 ms 0.265 ms 0.262 ms
2 ibgp.router2.dcga.ams.transip.net (87.253.141.250) 0.411 ms 0.265 ms 0.267 ms
3 transip.customer.openpeering.nl (82.150.154.57) 0.683 ms 0.759 ms 0.794 ms
4 openpeering-10g.upc.nl (82.150.153.114) 1.856 ms 0.769 ms 0.754 ms
5 84.116.135.201 (84.116.135.201) 10.526 ms 3.860 ms
84.116.135.181 (84.116.135.181) 3.903 ms
6 84.116.244.22 (84.116.244.22) 4.583 ms 4.268 ms 4.666 ms
7 212.142.55.230 (212.142.55.230) 6.534 ms 6.518 ms 6.428 ms
8 dhcp-089-099-215-171.chello.nl (89.99.215.171) 17.763 ms 11.652 ms 11.769 ms


- - - Updated - - -

Oorspronkelijk geplaatst door cyrano

Dat dacht ik ook. Maar de DNS had daar een ander idee over...

Hoe bedoel je precies want wellicht kan ik hier ook induiken.

- - - Updated - - -

Oorspronkelijk geplaatst door DB Service

Ip whithlisten of je firewall kort bypassen en dan checken of t wel lukt


Verzonden vanaf mijn iPhone met behulp van webhostingtalk

Beide geprobeerd, echter zonder resultaat.

Oorspronkelijk geplaatst door Exqua

Hoe bedoel je precies want wellicht kan ik hier ook induiken.

Ik dacht dat ipV6 geen rol speelde, omdat het om een oudere server zonder ipV6 ging. Ik was echter vergeten dat het control panel daar wel iets voor invult in de web interface. En de DNS was wel ipV6 klaar. Het werkte wel met OpenDNS en Google DNS, maar SOMS niet met die van de ISP.

Waarom het in dat specifiek geval misging met een ipV4 naar ipV4 verbinding is me verder een raadsel.

Oorspronkelijk geplaatst door cyrano

Ik dacht dat ipV6 geen rol speelde, omdat het om een oudere server zonder ipV6 ging. Ik was echter vergeten dat het control panel daar wel iets voor invult in de web interface. En de DNS was wel ipV6 klaar. Het werkte wel met OpenDNS en Google DNS, maar SOMS niet met die van de ISP.

Waarom het in dat specifiek geval misging met een ipV4 naar ipV4 verbinding is me verder een raadsel.

Bedankt voor je reactie, ik ga hier eens naar kijken.
Is er iemand die dit kan ophelderen?

Oorspronkelijk geplaatst door Exqua

Bedankt voor de heldere informatie.

Hosts achter de firewall:
IP's Intern: 192.168.1.10 tot 192.168.1.50
Netmask intern: 255.255.255.0
Gateway intern:192.168.1.1

webserver ip: 80.69.84.144 (buitenkant)
webserver ip: intern een adres binnen de reeks hierboven
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66

Host buiten de firewall:
IP: 80.69.84.142
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66

Ik hoop dat ik het zo goed heb beschreven.
Voor de overige informatie zal ik in deze dagen even naar het datacenter moeten.
Ik heb eventueel wel een traceroute van mijn firewall server naar de klant maar weet niet of dat relevant is.

[knip]

Ok, dank.
Nu is in elk geval duidelijk dat firewall buitenkant en werkende host in hetzelfde subnet zitten, en dat maakt het erg waarschijnlijk dat routing tussen Wifi en hosts hetzelfde pad en dezelfde componenten (wifi nat ?, firewall voor wifi net) passeert.

Volgende stap is dan de traceroute vanaf een wifi client, en vooral met tcpdump kijken op de ontvangende host of verkeer ook aankomt.

Ik zou op de werkende host even controleren welk source IP je vanaf Wifi krijgt (wordt dat genat naar buiten toe ?), en dan met tcpdump kijken op de firewall.

Op een Linux gebaseerde firewall kijkt tcpdump 'voor' de firewall regels, dwz, je ziet nog steeds packets die de firewall later zal droppen.

De vraag is of verkeer vanaf het wifi net wel aankomt aan de buitenkant van je firewall - zo ja, dan moet je harder zoeken in de rules .

Oorspronkelijk geplaatst door visser

Ok, dank.
Nu is in elk geval duidelijk dat firewall buitenkant en werkende host in hetzelfde subnet zitten, en dat maakt het erg waarschijnlijk dat routing tussen Wifi en hosts hetzelfde pad en dezelfde componenten (wifi nat ?, firewall voor wifi net) passeert.

Volgende stap is dan de traceroute vanaf een wifi client, en vooral met tcpdump kijken op de ontvangende host of verkeer ook aankomt.

Ik zou op de werkende host even controleren welk source IP je vanaf Wifi krijgt (wordt dat genat naar buiten toe ?), en dan met tcpdump kijken op de firewall.

Op een Linux gebaseerde firewall kijkt tcpdump 'voor' de firewall regels, dwz, je ziet nog steeds packets die de firewall later zal droppen.

De vraag is of verkeer vanaf het wifi net wel aankomt aan de buitenkant van je firewall - zo ja, dan moet je harder zoeken in de rules .

Probleem is verholpen.
Ik heb 2 netwerkkaarten in de firewall server zitten en ik verander van kaart en alles werkt naar behoren. net de klant nog aan de lijn gehad en deze kan alles benaderen.

Oorspronkelijk geplaatst door Exqua

Probleem is verholpen.
Ik heb 2 netwerkkaarten in de firewall server zitten en ik verander van kaart en alles werkt naar behoren. net de klant nog aan de lijn gehad en deze kan alles benaderen.

Ik kan inderdaad ook alles benaderen. Misschien zelfs iets te veel ;-)

Code:

PORT     STATE  SERVICE
21/tcp   open   ftp
25/tcp   open   smtp
80/tcp   open   http
110/tcp  open   pop3
143/tcp  open   imap
389/tcp  closed ldap
443/tcp  open   https
465/tcp  open   smtps
993/tcp  open   imaps
995/tcp  open   pop3s
2222/tcp open   EtherNet/IP-1