Welke informatie zou je willen hebben? wellicht dat ik je die kan geven.
Afdrukvoorbeeld
Heeft er toch alle schijn van dat de firewall de issue is. Probeer die ip's eens te whitelisten anders?
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
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 - - -
Hoe bedoel je precies want wellicht kan ik hier ook induiken.
- - - Updated - - -
Beide geprobeerd, echter zonder resultaat.
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.
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 .
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