[CentOS7] httpd/sshd niet te bereiken ondanks disabled fw

[RoRoo]

Ik ben op een Hyper-V machine (wellicht overbodige info, maar meld het maar) een CentOS 7 installatie aan het doen om een van onze webservers te gaan vervangen.

Ik heb een schone minimal install uitgevoerd en achteraf middels yum de httpd geinstalleerd.
Deze draait ook prima en zonder fouten.

Echter, als ik vanaf mijn werkstation naar de webpagina (Hello world) wil gaan, zoekt ie lang, en uiteindelijk krijg ik "De verbinding werd geherinitialiseerd".

Aangezien mijn werkstation in een ander subnet zit, dacht ik direct aan de firewall.

via firewall-cmd --add-service=http --permanent de http open gezet. Geen resultaat.
als test even de firewall gestopt. Geen resultaat.

Het stomme is, zodra ik een network restart uitvoer, ik heel even de pagina krijg maar bij een volgende reload weer dezelfde error.

Toen dacht ik aan selinux, deze ook uitgeschakeld en een reboot gedaan.. Geen resultaat
Zit ik op een machine binnen hetzelfde subnet, kom ik overal bij zoals verwacht.

Vanaf mijn werkstation kan ik de machine wel pingen.

Ik zoek me suf, maar kennelijk wordt er ergens toch iets geactiveerd bij het starten van mijn network service.

Iemand wat tips voor mij?

[ralfbosz]

niks in de logging van Apache (/var/log/httpd) ?!?!?

Sinds SELINUX uitstaat zou /var/log/audit/audit.log leeg moeten zijn (niks nieuws), anders even door audit2why halen...

En de /var/log/messages & /var/log/secure even doorspitten.

firewall-cmd --permanent altijd met een firewall-cmd reload opvolgen, anders is er nog niks actief. Als je gelijk actief wil hebben, moet je geen --permanent gebruiken (maar dan is ook alles na een reload weer weg ).

[RoRoo]

ralfbosz schreef op donderdag 02 juli 2015 @ 12:37:
niks in de logging van Apache (/var/log/httpd) ?!?!?

Niks

ralfbosz schreef op donderdag 02 juli 2015 @ 12:37:
Sinds SELINUX uitstaat zou /var/log/audit/audit.log leeg moeten zijn (niks nieuws), anders even door audit2why halen...

En de /var/log/messages & /var/log/secure even doorspitten.

Yep, ook gedaan. Niks nieuws/bijzonders.

ralfbosz schreef op donderdag 02 juli 2015 @ 12:37:
firewall-cmd --permanent altijd met een firewall-cmd reload opvolgen, anders is er nog niks actief. Als je gelijk actief wil hebben, moet je geen --permanent gebruiken (maar dan is ook alles na een reload weer weg ).

But ofcourse.. Was mijn eerste keer met firewall-cmd te werken, maar had duidelijke site gevonden. wordt snel vergeten even een reload te doen.

[Hero of Time]

Je geeft in de topictitel aan dat SSH ook niet werkt, maar meld daar in de TS verder niets over. Standaard wordt dat toegestaan in de firewall, pas bij block-all wordt dat tegengehouden. Heb je al met Telnet wat tests gedaan? Wat doet tcptraceroute? Iets op de Hyper-V host dat je nog moet doen?

[RoRoo]

SSH idd hetzelfde, maakt niet uit welke service ik gebruik.. geen (behalve ping) reactie.
Totdat ik "service network restart" doe, dan heb ik 1 minuut toegang tot mijn diensten (ssh/apache)

dat doet mij dus vermoeden dat er nog een actieve dienst is die roet in het eten gooit.

output van systemctl list-unit-files:

code:

[root@host ~]# systemctl list-unit-files |grep enabled

auditd.service                              enabled
crond.service                               enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service  enabled
getty@.service                              enabled
httpd.service                               enabled
irqbalance.service                          enabled
kdump.service                               enabled
lvm2-monitor.service                        enabled
microcode.service                           enabled
NetworkManager-dispatcher.service           enabled
NetworkManager.service                      enabled
postfix.service                             enabled
rsyslog.service                             enabled
sshd.service                                enabled
systemd-readahead-collect.service           enabled
systemd-readahead-drop.service              enabled
systemd-readahead-replay.service            enabled
tuned.service                               enabled
dm-event.socket                             enabled
lvm2-lvmetad.socket                         enabled
default.target                              enabled
multi-user.target                           enabled
remote-fs.target                            enabled

en nog een hele waslijst met static services...

tcptraceroute naar die machine geeft gewoon netjes mijn hops aan. zonder problemen.

tcping vanaf mijn bak geeft aan dat de poort wel open is.. Maar toch geen access (en niks in mijn logs)

code:

http Probing 10.250.2.60:80/tcp - Port is open - time=0.812ms
ssh Probing 10.250.2.60:22/tcp - Port is open - time=0.909ms

[ Voor 9% gewijzigd door RoRoo op 02-07-2015 14:13 ]

[Hero of Time]

En de uitvoer van arp laat ook het MAC adres van je VM zien? Zie je iets op de Hyper-V omgeving in de logs? Andere logs van de VM zelf, zoals /var/log/secure? Wat doet een ssh -vvv <vm>?

[0xDEADBEEF]

CentOS.. kijk eens in /etc/hosts.deny en /etc/hosts.allow

[ Voor 21% gewijzigd door 0xDEADBEEF op 02-07-2015 14:26 ]

[RoRoo]

ARP laat idd netjes het macadres zien van de de VM.

/var/log/secure:

code:

Jul  1 17:38:13 efd polkitd[760]: Loading rules from directory /etc/polkit-1/rules.d
Jul  1 17:38:13 efd polkitd[760]: Loading rules from directory /usr/share/polkit-1/rules.d
Jul  1 17:38:13 efd polkitd[760]: Finished loading, compiling and executing 2 rules
Jul  1 17:38:13 efd polkitd[760]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Jul  1 17:38:14 efd sshd[964]: Server listening on 0.0.0.0 port 22.
Jul  1 17:38:14 efd sshd[964]: Server listening on :: port 22.
Jul  2 12:25:33 efd login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=  user=root
Jul  2 12:25:33 efd login: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root"
Jul  2 12:25:34 efd login: FAILED LOGIN 1 FROM tty1 FOR root, Authentication failure
Jul  2 12:25:39 efd login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Jul  2 12:25:39 efd login: ROOT LOGIN ON tty1

Enkel lokaal inloggen met een typefout

ssh -vvv kan ik lokaal niet uitvoeren. windows bakje.
maar doe ik het op de machine zelf krijg ik alle encryptieniveaus etc te zien.

Hyper-V meldt helemaal niks mbt deze VM. algemene firewall staat daar ook al uit.. De overige 8 servers hierop (windows) hebben overigens deze problemen niet.

Ik blijf denken dat er ergens stiekem iets draait zoals bijv. de hosts.deny of .allow (die overigens leeg zijn)

edit:
And the plot thickens:

Collega's zojuist getest. Je kan eenmalig op de webserver/ssh komen, daarna niet meer

[ Voor 3% gewijzigd door RoRoo op 02-07-2015 16:21 ]

[0xDEADBEEF]

Not sure if this is relevant for you, but:

pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root"

[ Voor 20% gewijzigd door 0xDEADBEEF op 02-07-2015 16:25 ]

[RoRoo]

ssst

ik ga nu kijken met een snelle ubuntu installatie.. kijken wat ie daarmee doet..

snap er geen ajota meer van

Same sh*t, different OS.....
Iets met Hyper-V en Linux vm's dus.....

Back to the drawing board!

[ Voor 30% gewijzigd door RoRoo op 02-07-2015 17:06 ]

[CAPSLOCK2000]

RoRoo schreef op donderdag 02 juli 2015 @ 13:58:
SSH idd hetzelfde, maakt niet uit welke service ik gebruik.. geen (behalve ping) reactie.
Totdat ik "service network restart" doe, dan heb ik 1 minuut toegang tot mijn diensten (ssh/apache)

Dat is gek. Ik kan tweede dingen bedenken:
- De firewall wordt om wat voor reden dan ook niet goed opgeslagen en wordt na 1 minuut herstart. Ik weet niet genoeg van de CentOS firewall om te kunnen zeggen of dat mogelijk is. Je zou het kunnen testen door je firewall even helemaal te stoppen en te kijken of het dan blijft werken en/of de firewall zspontaan herstart.
- Er zijn twee verschillende netwerkconfiguraties actief. Er zou bv nog een DHCP-client actief zijn die na een minuut een ander IP-adres krijgt en daarmee de boel verpest.

[Hero of Time]

De firewall van CentOS 7, firewalld, zal nooit dit gedrag vertonen na een verse install. Er moet iets anders aan de hand zijn, zoals wat CL2K al aangeeft: andere DHCP server die een adres geeft. Maar je kan ook denken aan de netwerkkaart die vreemde dingen doet, bijvoorbeeld geen link meer hebben of de module crasht. IP conflict moet je uiteraard ook niet uitsluiten.

Doe daarom eens wat standaard netwerk troubleshooting. Ping vanaf die bak naar de host, probeer vanaf de host naar de VM te verbinden (telnet is zo geïnstalleerd) en meer van dat soort dingen.

[RoRoo]

Netwerk vanaf de host gaat zonder problemen. Géén ip conflict. Geen DHCP actief ivm fixed ip's
alle config 100% goed.

Ik ben er nu achter dat er op de onderliggende hypervisorlaag gewoon iets mis gaat. andere Linux installs geven éxact hetzelfde issue op deze bak.
Ik ga de servers daarop downen en de hele machine een schop geven, en wat updates installeren. wellicht dat deze iets fixen.

[Hero of Time]

Welke versie van HyperV draait er bij jullie? Een van de eerste versies, die met 2008R2 was meegeleverd, was niet direct compatible met Linux. Updates kan idd helpen.

[RoRoo]

2012 R2 - Deze zou goed en zonder al teveel problemen Linux moeten kunnen draaien.
Kan er geen touw aan vastknopen waarom deze zo vreemd doet.

Ik had al een paar P2V's gedaan van CentOS 4.9 en 6.4 machines maar deze hadden ook rare netwerk issues..
Dacht dat het aan hun versies lag, waarschijnlijk lag het aan de HV...

Ik meld me nog

Edit:
Updates gedraaid, geen verschil. Ben nu een 2e hyper-v machine aan het opbouwen om de VM naartoe te moven.
Kijken wat ie op andere HW doet.

Edit2:
VM naar een andere Hyper-V gemoved. Zelfde issue ook na resetten vNIC settings

Uitgesloten:

• VM - OS - CentOS en Ubuntu genereren zelfde issue
• Hardware - Op een fysiek andere machine blijft het probleem bestaan
• Geen firewall issue aangezien deze allemaal uitgeschakeld staan
• Connectiviteit - VM kan prima internet en andere hosts op het netwerk benaderen en is normaal pingbaar door derden.

Dan moet er toch iets zitten binnen Hyper-V dat ervoor zorgt dat je een Linux machine wat in een ander IP subnet zit.

Ik twijfel nog of het misschien in de router kan zitten, maar services op Windows virtuele machines in hetzelfde subnet als de Linux VM zijn wel gewoon bereikbaar vanuit het IP subnet van mijn PC.

Dan is het niet de router. (Zywall 110)

Edit3
Brainfart van een collega: Misschien is de MTU setting wel het probleem.
http://www.jofe.ch/the-co...e-and-mtu-size-and-linux/

Alleen zodra ik de MTU van de Linux VM lager dan 1500 zet, geeft ie een:SIOCSIFMTU: Invalid argument error.

indicates that the requested MTU was rejected by the kernel. Typically this would be due to it exceeding the maximum value supported by the interface hardware. In that case you must either reduce the MTU to a value that is supported or obtain more capable hardware.

1499 is kennelijk al verkeerd.

Volgens https://support.microsoft.com/en-us/kb/3021753 is dit al gefixed sinds 2014, dus ik vermoed dat ik deze fix ook al heb..

Ik heb de MTU van de Hyper-V NIC omhoog gegooid als tip van een andere site, maar dat hielp ook niet..

[ Voor 86% gewijzigd door RoRoo op 03-07-2015 13:45 ]

[daft_dutch]

Krijg je wel een "connection refused" als je de services uit heb staan?

[Hero of Time]

MTU gaat altijd in bepaalde waardes. 1410 zou een geldige waarde zijn geloof ik, maar 1499 iig niet. Het is ook afhankelijk van de netwerkdriver of een andere MTU wordt geaccepteerd. Ik denk niet dat het daar aan zal liggen.

Heb je al eens met Wireshark gekeken wat er gebeurt? Telnet had je het minimaal over, maar werkte dat nou wel of niet consistent? Zowel vanaf de host als een client, test het ook van een van de Windows VMs. Heb je nog keus voor een ander type NIC (al zou de standaard van het Linux template moeten werken)?

[RoRoo]

Wireshark nog niet getest. Telnet geeft zelfde issue. elke service welke ik activeer wordt binnen 30 sec. na starten van network service onbereikbaar..

poort is open en lijkt gewoon bereikbaar maar er reageert gewoon niks.
MTU heb ik al verschillende waardes gezet, maar de netwerkdriver accepteert deze niet en blijft stug op 1500 zitten.

Ik kan een V1 van de VM maken en een legacy kaart toevoegen, maar dat zal dan even na mijn vakantie moeten zijn
Ik hoorde alleen dat de performance van je netwerk dan lager ligt zodra je legacy gebruikt...
Nog 2 weekjes en dan ben ik weer op de zaak om het te proberen.

[Hero of Time]

Zoals in Hyper-V VM verliest netwerk connectiviteit een issue was, weet je zeker dat de VMs allemaal unieke MAC adressen hebben? Als het tevens 30 seconde is, vind ik 't wel erg toevallig. Als Spanning Tree op een switch aan staat, duurt het namelijk 30 seconde om een poort te 'leren' en wijzigingen in de infrastructuur (dus het inpluggen van een nieuw apparaat) heeft die tijd nodig om goed bekend te zijn.

Ga dus eens op een dieper netwerk niveau kijken waar het probleem kan liggen. Heeft de host bijvoorbeeld wel altijd verbinding met de VM op de specifieke poorten?

MTU die stug op 1500 blijft komt wel vaker voor bij VMs. De driver wil gewoon geen andere waarde omdat het dan op de Host niet goed gaat, of gewoonweg niet is geïmplementeerd.

[johnkeates]

Ik zou ook zeggen: wireshark ik!

Sommige hypervisors gebruiken een netwerkarchitectuur waarbij TCP checksums overgeslagen wordt in de virtuele offloader engine. Dat was met Linux voor zo ver ik weet nooit een probleem (FreeBSD was daar problematisch mee om dat die ongecalculeerde checksums niet leuk vind), maar je zou even kunnen kijken wat er gebeurt als je met ethtool alle fancy offloadings uitzet in de VM. Dit is ook te testen door UDP traffic vs. TCP traffic te testen. Dit probleem zorgt er voor dat pakketjes (of de eerste pakketjes) soms aan komen, maar even later niet meer.

[DSK]

Ooit hetzelfde gedrag gezien door een virusscanner.
Deze liet alleen toegang tot poorten toe waarop de host zelf ook aan het luisteren was. Andere poorten werden geblokkeerd voor de gebridgde (virtuele) machines.

Al lang niet meer in detail met Windows servers bezig geweest en al helemaal niet met Hyper-V maar het is de moeite om eens te bekijken op je host.

Het is eenvoudig te testen door op je host iets te laten luisteren (bijvoorbeeld op poort 80) en ssh tijdelijk te draaien op poort 80, bijvoorbeeld met:
$ sudo /usr/sbin/sshd -d -p80

[ Voor 20% gewijzigd door DSK op 14-07-2015 10:01 ]

[daft_dutch]

DSK schreef op dinsdag 14 juli 2015 @ 10:00:
Ooit hetzelfde gedrag gezien door een virusscanner.
Deze liet alleen toegang tot poorten toe waarop de host zelf ook aan het luisteren was. Andere poorten werden geblokkeerd voor de gebridgde (virtuele) machines.

zoals ik al zei; " Krijg je wel een "connection refused" als je de services uit heb staan?"

Service aan: connection open
service uit: connection refused

indien anders zit er iets tussen.

[lord4163]

Installeer netcat en type het volgende commando in de VM:

nc -l 0.0.0.0 1337

Daarna installeert u netcat op de computer waar de host niet mee kan verbinden en voert u dit commando uit:

nc <ip-adres-van-vm> 1337

Probeer vervolgens wat te typen (gevolgd door een enter), als het goed is ziet u dat bericht dan verschijnen in de VM.

Ik kijk uit naar het resultaat.

[ Voor 3% gewijzigd door lord4163 op 17-07-2015 15:04 ]

[RoRoo]

daft_dutch schreef op donderdag 16 juli 2015 @ 09:42:

zoals ik al zei; " Krijg je wel een "connection refused" als je de services uit heb staan?"

Service aan: connection open
service uit: connection refused

indien anders zit er iets tussen.

Service uit = geen connectie
Service aan = contact met de poort, maar geen service.

lord4163 schreef op vrijdag 17 juli 2015 @ 15:02:
Installeer netcat en type het volgende commando in de VM:

nc -l 0.0.0.0 1337

Daarna installeert u netcat op de computer waar de host niet mee kan verbinden en voert u dit commando uit:

nc <ip-adres-van-vm> 1337

Probeer vervolgens wat te typen (gevolgd door een enter), als het goed is ziet u dat bericht dan verschijnen in de VM.

Ik kijk uit naar het resultaat.

Kan doen wat ik wil.. geen reactie.

Wireshark output bij een verzoek vanaf mijn pc naar port 80 (192.168.2.128) naar de Linux VM (10.250.2.60):

code:

Capturing on 'eth0'
  1   0.000000 192.168.2.128 -> 10.250.2.60  TCP 66 61573 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1   2   0.000047  10.250.2.60 -> 192.168.2.128 TCP 66 http > 61573 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
2   3   1.411058  10.250.2.60 -> 192.168.2.128 TCP 66 [TCP Retransmission] http > 61573 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   4   3.415128  10.250.2.60 -> 192.168.2.128 TCP 66 [TCP Retransmission] http > 61573 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
4   5   7.423106  10.250.2.60 -> 192.168.2.128 TCP 66 [TCP Retransmission] http > 61573 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
5   6  15.443211  10.250.2.60 -> 192.168.2.128 TCP 66 [TCP Retransmission] http > 61573 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
6   7  18.905116 192.168.2.128 -> 10.250.2.60  TCP 60 61573 > http [RST, ACK] Seq=402 Ack=1 Win=0 Len=0

Uiteindelijk reinitialize error in de browser.

Stop ik Apache:

code:

Capturing on 'eth0'
  1   0.000000 192.168.2.128 -> 10.250.2.60  TCP 66 61605 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1   2   0.000043  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61605 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  3   0.252031 192.168.2.128 -> 10.250.2.60  TCP 66 61606 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  4   0.252076  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61606 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  5   0.503899 192.168.2.128 -> 10.250.2.60  TCP 66 [TCP Retransmission] 61605 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
5   6   0.503943  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61605 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  7   0.753237 192.168.2.128 -> 10.250.2.60  TCP 66 [TCP Retransmission] 61606 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  8   0.753281  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61606 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  9   1.003229 192.168.2.128 -> 10.250.2.60  TCP 62 [TCP Retransmission] 61605 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
9  10   1.003273  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61605 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 11   1.004162 192.168.2.128 -> 10.250.2.60  TCP 66 61607 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
 12   1.004175  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61607 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 13   1.253903 192.168.2.128 -> 10.250.2.60  TCP 62 [TCP Retransmission] 61606 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
 14   1.253975  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61606 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 15   1.254997 192.168.2.128 -> 10.250.2.60  TCP 66 61608 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
 16   1.255039  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 17   1.501281 192.168.2.128 -> 10.250.2.60  TCP 66 [TCP Retransmission] 61607 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
17  18   1.501315  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61607 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 19   1.759110 192.168.2.128 -> 10.250.2.60  TCP 66 [TCP Retransmission] 61608 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
 20   1.759149  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 21   2.013002 192.168.2.128 -> 10.250.2.60  TCP 62 [TCP Retransmission] 61607 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
21  22   2.013058  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61607 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 23   2.260573 192.168.2.128 -> 10.250.2.60  TCP 62 [TCP Retransmission] 61608 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
 24   2.260622  10.250.2.60 -> 192.168.2.128 TCP 54 http > 61608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Doe ik een verzoek vanaf een machine in hetzelfde IP subnet van de Linux bak:

code:

Capturing on 'eth0'
  1   0.000000  10.250.2.20 -> 10.250.2.60  TCP 66 51116 > http [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
  2   0.000049  10.250.2.60 -> 10.250.2.20  TCP 66 http > 51116 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
  3   0.003189  10.250.2.20 -> 10.250.2.60  TCP 54 51116 > http [ACK] Seq=1 Ack=1 Win=262144 Len=0

En ik krijg gewoon de web pagina te zien..

[ Voor 71% gewijzigd door RoRoo op 27-07-2015 17:12 ]

[GeeMoney]

Staan je IP-gegevens wel goed? (Denk aan netmask/gateway)
En hoe ziet je route tabel eruit?
Servers/werkstations in hetzelfde subnet blijven nu de pagina zien of is deze na 30seconden nog steeds weg?

[RoRoo]

GeeMoney schreef op dinsdag 28 juli 2015 @ 13:15:
Staan je IP-gegevens wel goed? (Denk aan netmask/gateway)
En hoe ziet je route tabel eruit?
Servers/werkstations in hetzelfde subnet blijven nu de pagina zien of is deze na 30seconden nog steeds weg?

Yep, router staat ook goed.
Windows VM's in hetzelfde subnet zijn wel bereikbaar voor machines uit het andere subnet.

Servers/Werkstations kunnen onbeperkt gebruik maken van de diensten van de Linux VM zolang ze maar in hetzelfde subnet zitten.

[RoRoo]

Kleine update:
Als test een versie 1 VM gemaakt.. Same issue
Ik word er knetter van. Je gaat op een gegeven moment van alles uit proberen.

Switch vervangen, router vervangen.. trés bizar!

[H@rry]

Misschien gek idee, maar tussen 2 VM's? Gaat het dan wel goed?

[Hero of Time]

RoRoo schreef op dinsdag 28 juli 2015 @ 16:18:
[...]


Yep, router staat ook goed.
Windows VM's in hetzelfde subnet zijn wel bereikbaar voor machines uit het andere subnet.

Servers/Werkstations kunnen onbeperkt gebruik maken van de diensten van de Linux VM zolang ze maar in hetzelfde subnet zitten.

Dan kan ik mij maar 1 ding bedenken: routering. Is er wel een default gateway ingesteld en klopt deze ook?

[RoRoo]

Yep..
Alles, maar dan ook echt alles werkt. behalve dat ding benaderen vanuit het 2e ip subnet.

Ik gooi hier de handdoek in de ring en laat het voor wat het is. Dit is sowieso een setup die over 2 mnd gewoon weg is.
Had gehoopt op een feature binnen Linux die ik nog niet kende...

[RoRoo]

Ik kon het niet laten en heb hier een groot deel van het netwerk omgegooid.
alles wat draaide op dat 2e subnet is nu een VLAN geworden.

lo and behold: geen issues en alles blijft werken.

Op de een of andere manier kan Linux iets niet met die pakketjes doen, waar een windows machine geen problemen ervaart..

Weet nu niet of ik dit als iets goeds moet aanmerken, maar het was natuurlijk al geen nette situatie en nu het netjes gemaakt is werkt alles naar behoren......

[clogie886]

Verkeerde reactie - aub verwijderen

[ Voor 90% gewijzigd door clogie886 op 11-08-2015 15:40 ]