pfSense "freezed" al mijn VMware Consoles

[oxyle]

Beste Tweakers,

Inmiddels ben ik echt ten einde raad.

Ik heb thuis twee netwerken:
- 10, voor gebruikers;
- 15, voor m'n homelab met domein controllers.

Tussen beide netwerken wordt gerouteerd door een pfSense virtuele machine. Vanwege het troubleshooten staat de firewall op de pfSense op 'allow any any' tussen beide netwerken. Het probleem dat ik op dit moment blijf houden is namelijk het volgende:

- Op het moment dat ik vanuit netwerk 10 verbinding maak met een van beide ESX hosts en vraag een VMware console op. Dan kan ik daar prima in, alles werkt zoals het zou moeten. Maar na het (bijvoorbeeld) het openen van een browser, of file explorer dan bevriest de console. Als ik gelijktijdig meekijk in vCenter over de HTML5 console dan blijft alles naar mijn verbazing soepel doorlopen. Het zelfde geld voor een RDP sessie, die blijft net zoals de HTML5 sessie werken zonder hapering of iets wat daarop lijkt.

In Wireshark zie ik op het moment dat dit fenomeen zich voordoet ook een aantal TCP retransmissions verschijnen. Maar daar wordt ik zelf niet veel wijzer van.
Voorbeeld: http://imgur.com/a/BS4B4

Wat heb ik gedaan, en geen effect heeft gehad:
- Firewall op allow any any gezet;
- VMware Tools is de laatste versie;
- ESX reboot, update, reinstall;
- pfSense reboot, adapters vervangen (E1000, naar VMX3);
- Connectie limieten in pfSense opgehoogd en op 'conservative' gezet waardoor sessies langer open blijven.

Nu is het vreemde dat als ik m'n oude Sophos VM weer aan zwengel (en pfSense dus uitzet) en het zelfde probeer dat ik totaal geen problemen heb. Daarin tegen kan ik ook vanuit mijn 10 netwerk een VPN open zetten naar pfSense en dat heb ik het probleem ook niet.

Op dit moment zit ik echt helemaal vast, ik wil gewoon dat het werk... Want op deze manier kan ik dus ook geen .ISO files aansluiten aangezien de hele console vast blijft lopen. Het probleem lijkt (mij in iedergeval) in pfSense te zitten. Maar ik durf niet te zeggen waar het precies ligt, Reddit en de pfSense forums zijn helaas ook niet zo actief op dit gebied. Wellicht dat Tweakers te hulp kan schieten?

[Yariva]

Helpt het om met deze instellingen te spelen?

http://www.monster.com.tw...30a988ad401d605afe440.png

[oxyle]

Yariva schreef op maandag 12 juni 2017 @ 14:42:
Helpt het om met deze instellingen te spelen?

http://www.monster.com.tw...30a988ad401d605afe440.png

Helaas, heb alle mogelijkheden gehad... Maar ik blijf een bevroren console hebben (met inmiddels 14 sessies):

[ Voor 5% gewijzigd door oxyle op 12-06-2017 15:20 ]

[Question Mark]

In welk netwerk staat de service console van de ESX hosts?

En wat zegt de logging van PFsense (enable logging eens op je "Any - Any" rule)... En op welke adapter staat je rule? Staat op het pad terug ook Any-Any open?

[oxyle]

Question Mark schreef op maandag 12 juni 2017 @ 15:20:
In welk netwerk staat de service console van de ESX hosts?

En wat zegt de logging van PFsense (enable logging eens op je "Any - Any" rule)... En op welke adapter staat je rule? Staat op het pad terug ook Any-Any open?

Mijn werkplek waar ik een verbinding mee opzet staat in een 192.168.10.0/24 netwerk. Beide ESX hosts en vCenter staan in 192.168.11.0/24. pfSense heeft een eigen adapter voor elk netwerk er is geen spraken van een "router on a stick".

In de logbestanden staan geen entries die naar een van beide ESX servers gaan.

De any-any regel produceert geen afwijkingen in de log-bestanden. En het 192.168.11.0/24 netwerk heeft ook een any-any regel voor de terugweg naar 192.168.10.0/24. De Firewall regel is op beide adapters toegepast en zijn elkaars omgekeerde (10 > 15, 15 > 10: Any-any).

[ Voor 6% gewijzigd door oxyle op 12-06-2017 15:31 ]

[Question Mark]

oxyle schreef op maandag 12 juni 2017 @ 15:29:
[...]
In de logbestanden staan geen entries die naar een van beide ESX servers gaan.

En logging staat wel enabled voor de rules? Dat staat default uit, vandaar dat ik er naar vroeg...

Dat moet logging opleveren (status - system logs - firewall).... Je zou dan een "allow" voorbij moeten zien komen.. Dan kun je in elk geval terug zien hoe er gecommuniceerd wordt.

[oxyle]

Ah sorry, alleen de errors stonden aan inderdaad:

Alles lijkt volgens mij prima te verlopen, op mijn probleem na dus... haha

443, is volgensmij authenticatie
902, is al het verkeer voor de remote console als het goed is...

Foto:
http://i.imgur.com/AZ4YU4g.png

[ Voor 53% gewijzigd door oxyle op 12-06-2017 16:06 ]

[Vorkie]

En het is ook fysiek gescheiden? Of virtueel via vlans? Zijn deze vlans ook benoemd in pfsense?

Gateways staan ook allemaal juist?

Zijn de netwerkkaarten met vtd ingesteld of virtueel via vswitches?

[oxyle]

Vorkie schreef op maandag 12 juni 2017 @ 16:30:
En het is ook fysiek gescheiden? Of virtueel via vlans? Zijn deze vlans ook benoemd in pfsense?

Gateways staan ook allemaal juist?

Zijn de netwerkkaarten met vtd ingesteld of virtueel via vswitches?

Ieder VLAN heeft echt een aparte fysieke poort op beide ESX machines. De switch erachter heeft meerdere VLAN's (10, 15) en alle poorten staan in access modus. Verder maak ik dus gebruik van vSwitches, elke switch aangesloten op een enkele fysieke adapter die zich maar in een enkel VLAN bevindt.

pfSense doet verder niets met VLAN's aangezien alle poorten in access modus staan hoef ik nergens tags mee te geven.

[ik222]

Het klinkt als een mogelijk MTU issue, heb je ergens afwijkende MTU waardes geconfigureerd in het pad?

[oxyle]

ik222 schreef op maandag 12 juni 2017 @ 20:20:
Het klinkt als een mogelijk MTU issue, heb je ergens afwijkende MTU waardes geconfigureerd in het pad?

Zal zo eens kijken voor de zekerheid, maar de enigste afwijkende waarde die ik uit me hoofd weet is de link tussen de ESX hosts, voor vMotion. En die zijn direct op elkaar aangesloten zonder switch...

[Thralas]

ik222 schreef op maandag 12 juni 2017 @ 20:20:
Het klinkt als een mogelijk MTU issue, heb je ergens afwijkende MTU waardes geconfigureerd in het pad?

Lijkt me ook niet geheel onwaarschijlijk.

Ook in het plaatje te zien, enkel retransmissions voor grote packets. Wat ik daar ook niet aan snap is dat de retransmission in eerste instantie een andere TCP payload size heeft?

Anyhow, als TS retransmissions aan de ene kant ziet dan zou ik het pad volgen (met tcpdump/Wireshark) tot je de packets ergens kwijtbent.

Of filter in de any-any-situatie eens op ICMP. Als het een MTU-probleem is zou je PMTU discovery moeten zien plaatsvinden..

[Snake]

Wissel eens de drivers op pfSense, van VMX3 naar de Intel.

[oxyle]

Thralas schreef op maandag 12 juni 2017 @ 21:42:
[...]


Lijkt me ook niet geheel onwaarschijlijk.

Ook in het plaatje te zien, enkel retransmissions voor grote packets. Wat ik daar ook niet aan snap is dat de retransmission in eerste instantie een andere TCP payload size heeft?

Anyhow, als TS retransmissions aan de ene kant ziet dan zou ik het pad volgen (met tcpdump/Wireshark) tot je de packets ergens kwijtbent.

Of filter in de any-any-situatie eens op ICMP. Als het een MTU-probleem is zou je PMTU discovery moeten zien plaatsvinden..

Geen PMTU discoveries te vinden als ik een trace start op pfSense (of mijn computer) zelf en ik dezelfde fout opnieuw genereer. Heb alle MTU's nagelopen, de enigste die afwijkt is m'n PPPoE sessie naar het internet toe, die is 1492. Maar dat lijkt me sterk, als ik die ophoog naar 1500 klapt ons internet weg :-)

Snake schreef op maandag 12 juni 2017 @ 23:19:
Wissel eens de drivers op pfSense, van VMX3 naar de Intel.

Heb beide al een keer gehad, ben begonnen met E1000 NIC's, inmiddels al een weekje over op VMX3 en dat maakt vrijwel geen verschil. Op dit moment zit ik weer op de E1000's.

Edit 13-6-2017:
- Flow control aan/uit (zowel op switch, pfsense als PC): Geen effect gehad.
- Intel NIC drivers geupdate op m'n werkplek, geen effect...
- Andere netwerk adapter geprobeerd, geen effect
- Wireless/Wired, ook geen effect

Wat ik vreemd blijf vinden, als ik voor de grap eens een VPN verbinding opzet (vanuit 10 netwerk) naar m'n pfSense en dan een sessie opzet naar m'n ESX hosts. Dan heb ik nergens last van

[ Voor 14% gewijzigd door oxyle op 13-06-2017 12:39 ]

[oxyle]

Update: Zelfs na het volledig herinstalleren van een nieuwe virtuele machine. En het terugzetten van de configuratie blijft dit probleem zich voor doen...

Wellicht maar een keer volledig vanaf scratch opnieuw opbouwen dan maar...

[RedShift]

Op wat staat de NAT sessie timeout ingesteld in pfsense?

[oxyle]

RedShift schreef op donderdag 22 juni 2017 @ 21:17:
Op wat staat de NAT sessie timeout ingesteld in pfsense?

Als je de "Firewall Optimization Options" bedoeld? Die staat op conservative.

[BluRay]

Schakel "Disable hardware large receive offload" eens uit. En maak het liefst gebruik van VMXNET3 Adapters.
Heb je ook VMware Tools geinstalleerd in PfSense?

[oxyle]

BluRay schreef op zaterdag 24 juni 2017 @ 10:59:
Schakel "Disable hardware large receive offload" eens uit. En maak het liefst gebruik van VMXNET3 Adapters.
Heb je ook VMware Tools geinstalleerd in PfSense?

VMXNET3, en E1000 geprobeert en OpenVM-Tools packagese zijn binnen pfSense ook geïnstalleerd. Zal straks met hardware large receive offload spelen. Maar voor alsnog maakt dat niet veel uit bij mij. Console sessies blijven wegvallen.

[BluRay]

oxyle schreef op zaterdag 24 juni 2017 @ 20:47:
[...]


VMXNET3, en E1000 geprobeert en OpenVM-Tools packagese zijn binnen pfSense ook geïnstalleerd. Zal straks met hardware large receive offload spelen. Maar voor alsnog maakt dat niet veel uit bij mij. Console sessies blijven wegvallen.

Heb je dit nog weten op te lossen?
Heeft het uitschakelen van de optie geholpen?
Curious!

[oxyle]

BluRay schreef op dinsdag 27 juni 2017 @ 18:42:
[...]


Heb je dit nog weten op te lossen?
Heeft het uitschakelen van de optie geholpen?
Curious!

Helaas niet, ik ga aankomend weekend waarschijnlijk m'n lab opnieuw inrichten. En wellicht nog even kijken naar andere hypervisors. Misschien dat dat helpt (lijkt me niet, dat het aan ESX ligt)... Maar wellicht helpt het. Heb ook met alle opties in dezelfde lijst gespeeld, geen van allen lijken te helpen...

[BluRay]

Je zou ook eens kunnen kijken of een andere vRouter dit probleem ook heeft.
Bijvoorbeeld: VyOS of Sophos.

[oxyle]

BluRay schreef op dinsdag 27 juni 2017 @ 18:49:
Je zou ook eens kunnen kijken of een andere vRouter dit probleem ook heeft.
Bijvoorbeeld: VyOS of Sophos.

Ja dat is hem dus, ik heb het zelfde geprobeerd met Sophos XG (daar kom ik van af), en die had helemaal geen problemen. Ben er echter van af gestapt i.v.m. matige IPv6 support over PPPoE...

[oxyle]

Toch nog even een kleine bump voor hulp:

Inmiddels meerdere dingen geprobeerd:

1. Aantal functies in de BIOS van m'n DL380 G7's aangepast.
2. Een volledige herinstallatie/configuratie van VMware ESXi.
3. Het ontkoppelen van de vCenter machine, en daarmee de host(s) beide onafhankelijk laten draaien.
4. Er is zelfs een nieuwe Dell server (R210 II) aangeschaft, nieuwe installatie van pfSense op gezet (opnieuw geconfigureerd, geen backup terug gezet van configuratie).

Geen van de bovenstaande oplossingen heeft geholpen... En dat maakt het alleen maar vreemder voor mij, "zelfs" een fysieke pfSense machine lost het probleem niet op. En dat sluit wellicht ESXi uit als mogelijke oorzaak, maar ik heb geen idee waar ik nu verder moet kijken in pfSense.

VLAN10 = computers
VLAN11 = servers
pfSense heeft aparte interfaces (Quad-port PRO1000/VT) voor beide netwerken, er is geen sprake van tagging o.i.d.
Het zelfde geld voor de ESXi machines, allemaal aparte poorten voor elk VLAN.
Een Cisco switch met alle poorten in "access" modus handelt de scheiding tussen verschillende VLAN's af.

Nog even samenvattend:
Volledig schone installatie pfSense;
Verkeer tussen mijn computer(netwerk) en het servernetwerk wordt volledig toegestaan (van en naar!);
ESXi heeft mede door dit probleem twee management poorten (VLAN10 en 11). Alle sessies die ik met de viClient opzet naar de hypervisor (en VM's) gaan prima. Echter vanuit VLAN11 loopt alles spaak en krijg ik allemaal TCP retransmissions/duplicates.

Wireshark output:
https://i.imgur.com/YKUz1DA.png

Tot slot: Met Sophos XG (virtueel) doet dit probleem zich helemaal niet voor, maar ben niet zo een fan van de nieuwe interface... En uiteindelijk wil ik wel gewoon pfSense blijven gebruiken.

Uiteraard alle bovenstaande tips ook al (tevergeefs) uitgeprobeerd...

[ Voor 7% gewijzigd door oxyle op 02-11-2017 15:43 ]

[Question Mark]

oxyle schreef op maandag 12 juni 2017 @ 16:34:
[...]


Ieder VLAN heeft echt een aparte fysieke poort op beide ESX machines. De switch erachter heeft meerdere VLAN's (10, 15) en alle poorten staan in access modus. Verder maak ik dus gebruik van vSwitches, elke switch aangesloten op een enkele fysieke adapter die zich maar in een enkel VLAN bevindt.

pfSense doet verder niets met VLAN's aangezien alle poorten in access modus staan hoef ik nergens tags mee te geven.

Er zitten dus ook geen fysieke switches tussen beide VSphere hosts, waar nog iets met vlan (tagging) en/of routering fout ingesteld kan staan?

Als er wel een fysieke switch tussen staat, zul je daar wel degelijk je vlan's op moeten aanmaken, en de juiste vlan tags op de access interface moeten taggen. Anders is je scheiding tussen je netwerken immers weg.

[oxyle]

Question Mark schreef op donderdag 2 november 2017 @ 15:39:
[...]

Er zitten dus ook geen fysieke switches tussen beide VSphere hosts, waar nog iets met vlan (tagging) en/of routering fout ingesteld kan staan?

Als er wel een fysieke switch tussen staat, zul je daar wel degelijk je vlan's op moeten aanmaken, en de juiste vlan tags op de access interface moeten taggen. Anders is je scheiding tussen je netwerken immers weg.

Excuus je hebt gelijk,

Er zit een enkele (Cisco SG200-26) tussen die inderdaad als enigste VLAN's opsplitst. Alle poorten staan hiervoor in access modus, er gaan geen trunklijnen van/naar pfSense of ESXi.

[oxyle]

Nou het is eindelijk opgelost denk ik nu zeker te weten.

M'n ESXi machines hadden i.v.m. een virtuele pfSense in het verleden een tweede management IP in m'n computer netwerk. Dat IP is nu verwijderd, en alles draait weer zoals van ouds. Terwijl de tweede adapter geen gateway heeft ingesteld gekregen, blijkbaar doet ESX dan toch iets anders dan ik had gedacht.

Thanks iedereen!