Routerings probleem?

[de echte flush]

Hey Tweakers,

Heb hier een redelijk ingewikkeld probleem (of allesinds voor mij )

"Probleem":

Ik wil vanaf VLAN 4 (192.168.4.5) pingen naar het firewall IP in VLAN 1 (192.168.2.254) deze ping komt aan op de firewall maar krijg geen antwoord terug, wat is hier de logische verklaring voor?
(pingen naar 192.168.4.254 gaat uiterraad wel).

Pakketje op de firewall (passeert dus via de L3 switch):
28024.0: trust(i) len=74:d07e28a3aa40->00121ebd8aa2/0800
192.168.4.5 -> 192.168.2.254/1
vhl=45, tos=00, id=5447, frag=0000, ttl=127 tlen=60
icmp:type=8, code=0


Pakketje op de firewall als de client zijn gateway wordt ingesteld op 192.168.4.254 (passeert niet via L3 switch)

32695.0: trust(i) len=78:000c29f5f1c0->00121ebd8aa2/8100/0800, tag 4
192.168.4.86 -> 192.168.2.254/1
vhl=45, tos=00, id=11669, frag=0000, ttl=128 tlen=60
icmp:type=8, code=0
(Het is dus als geen security regel in de firewall)

Waarschijnlijk een gerelateerd probleem:
Vanaf dezelfde client (192.168.4.5) kan ik pingen naar een AP (192.168.2.251) maar kan niet op de mgmt pagina, zelfde met bv. de NAS enkel pingen maar geen webpagina !? verander ik de gateway op de nas of de AP van .253 naar .254 kan ik nog steeds pingen maar ook op de beheer pagina...


een schets met wat extra uitleg vind je hier:
http://tweakers.net/ext/f/nVz0ieEqf8JZkvOVJgfx6vWp/full.jpg


topic is enkel om het probleem te begrijpen/bij te leren. Het is inderdaad niet echt de bedoeling dat de gewone gebruikers vlan naar het mgmt van de firewall kan. (Al kan ik dat ook blocken met ACL)

Bedankt voor het meedenken!

(Als ik iets vergeten ben/extra moet duiden hoor ik het wel).

[DukeBox]

Je denkt een routerings probleem te hebben maar nergens heb je ook maar enige info m.b.t. (default) gateways en hops.

Je geeft aan dat je switch de routering doet dus mag ik aannemen dat deze je default gateway is op je clients en op je firewall voor de betreffende ranges ? En vervolgens de switch de default naar je firewall staat ?

Hoe dan ook zie ik het nut van 2 ip's op je firewall nu niet als je op je switch routeerd (buiten je guest ip).

[ Voor 7% gewijzigd door DukeBox op 27-09-2014 18:39 ]

[de echte flush]

Hey DukeBox,

Thanks voor de reply. Ja ben blijkbaar een paar zaakjes vergeten

Vroeger deed de firewall alle routering maar aangezien de performance niet optimaal is (van vlan 4 naar 2) heb ik dit door de switch laten doen. Op de switch een dhcp relay agent gemaakt, maar toen botste ik op het probleem dat de firewall enkel dhcp server kan zijn voor een gekende interface (Kon dus niet meerdere scopes aanmaken zonder een interface in de betreffende vlan). Dat is de enige reden dat de firewall ook een 4.254 IP heeft.

De clients hebben inderdaad de switch als default gateway (enkel vlan6 heeft de firewall als gateway).

Routering is vrij simpel:
op de switch een 0.0.0.0/0 naar 192.168.2.254 (FW) via vlan 1

De firewall heeft geen routering terug naar de switch aangezien hij directe routes heeft naar de vlans. Een route naar de switch wordt dus ook niet actief bij hetzelfde subnet. Heb als test wel een route bijgemaakt:
192.168.4.5/32 192.168.2.253 --> die wel actief wordt (ander subnet) maar dit helpt niet.

Titel is misschien niet al te best gekozen. L2/L3 probleem is misschien beter maar tis me niet duidelijk waar het probleem te zoeken

[3DDude]

de echte flush schreef op zaterdag 27 september 2014 @ 19:14:
Hey DukeBox,

Thanks voor de reply. Ja ben blijkbaar een paar zaakjes vergeten

Vroeger deed de firewall alle routering maar aangezien de performance niet optimaal is (van vlan 4 naar 2) heb ik dit door de switch laten doen. Op de switch een dhcp relay agent gemaakt, maar toen botste ik op het probleem dat de firewall enkel dhcp server kan zijn voor een gekende interface (Kon dus niet meerdere scopes aanmaken zonder een interface in de betreffende vlan). Dat is de enige reden dat de firewall ook een 4.254 IP heeft.

De clients hebben inderdaad de switch als default gateway (enkel vlan6 heeft de firewall als gateway).

Routering is vrij simpel:
op de switch een 0.0.0.0/0 naar 192.168.2.254 (FW) via vlan 1

De firewall heeft geen routering terug naar de switch aangezien hij directe routes heeft naar de vlans. Een route naar de switch wordt dus ook niet actief bij hetzelfde subnet. Heb als test wel een route bijgemaakt:
192.168.4.5/32 192.168.2.253 --> die wel actief wordt (ander subnet) maar dit helpt niet.

Titel is misschien niet al te best gekozen. L2/L3 probleem is misschien beter maar tis me niet duidelijk waar het probleem te zoeken

Die ene entry in je routeringstabel is voor alles naar 192.168.2.254. (dus stel ik wil naar 'buiten maakt niet uit waar naar toe --> ga via 192.168.2.254 als gateway).
Maar omdat die andere VLAN's een andere subnet hebben kunnen ze die 192.168.2.254 niet vinden (denk ik).

Je zult dus aan moeten maken dat ze per vlan een route hebben naar de router ( als gateway) die alle netwerken kent.
Heb je een tekening hoe het in elkaar zit nu precies?

En wat routeert er ? de Firewall? de Switch? beiden?

Je moet de routes toevoegen op het apparaat wat de routering doet.
Doet de switch dat? Voeg daar dan die netwerken die je eraan knoopt toe.

Doe je static routes overigens of gebruik je een routerings protocol?

[ Voor 4% gewijzigd door 3DDude op 27-09-2014 19:51 ]

[_-= Erikje =-_]

Async routing? Reverse path kan dan nog roet in het eten gooien, zeker gezien je aparte set-up

[de echte flush]

@3DDude:
Een schetsje zit in de eerste post. Een client in vlan 4 die naar internet wil komt inderdaad op de switch uit via 192.168.4.253 de switch heeft een weg naar .2.254 via hier komt het op de firewall terecht welke op zijn beurt een weg naar buiten heeft. (Surfen etc gaat trouwens perfect vanaf alle vlans).

Beide doen dus een deel routering, het zijn wel static routes.

@Erik, ik denk ook aan zoiets vreemds, wat onbedoeld door de opzet wel mogelijk is geworden.


Edit: probleempje is van de baan al is niet 100% duidelijk waarom.

Er zat een foutje in een van de routeringsregel naar de switch (zie men 2de post). Had met de route een verkeerde interface meegegeven (een standaard niet gebruikte interface).

Pakketje van VLAN4 voor zijn VLAN1-IP komt aan op de firewall, hij heeft een directe route naar VLAN4 (door de extra interface in deze VLAN). Maar blijkbaar gebruikt ie deze route niet (omdat het verkeer binnen is gekomen via VLAN 1 en niet via VLAN4?).

* 192.168.4.0/24 trust.4 --> Dit is de automatische (connected) route
* 192.168.4.0/25 192.168.2.253 trust --> Dit is de door mij aangemaakte waar het foutje inzat.


Het 2de issue heeft daar ook half mee te maken: ?

ping vanaf VLAN4 naar bv. NAS/AP gaat (NAS/AP staan bewust foutief ingesteld op gw .2.254 firewall ipv switch):

maar vanaf VLAN4 naar mgmt pagina van AP gaat niet!

Verkeer komt binnen via switch op AP, device antwoord via de FW welke het routeert naar de client in VLAN4. Maar waarom enkel de ping antwoord en de webserver niet geen idee?
Zou zeggen omdat het verkeer niet via dezelfde weg gaat maar dat is voor zowel de ping als het http verkeer zo...

Ik zoek nog verder


edit2:

Iemand goed thuis in de wereld van tcp?

Zie het pakketje op de firewall passeren


aanvraag op de client:


Blokkeert de firewall het verkeer omdat hij een "statefull" is? (ookal is er een any allow regel)
--> er is een sessie geopend (via de switch) maar de reply komt via de firewall maar omdat deze geen benul heeft van de open sessie blokeert ie het?

(Op ICMP zal ie geen check doen, en laat ie het gwn door. De fireawall ziet enkel de reply niet de request (die via de switch kwam)

[ Voor 94% gewijzigd door de echte flush op 28-09-2014 14:46 ]

[de echte flush]

Iemand die bovenstaande kan bevestigen?

[Joshuax8]

de echte flush schreef op maandag 29 september 2014 @ 17:59:
Iemand die bovenstaande kan bevestigen?

Als al het verkeer alleen op de terugweg via de firewall gaat en het is een statefull firewall dan zal dat niet werken (zelfs niet met ping). Een oplossing zou zijn om de L3 switch ook de route terug af te laten handelen (zonder het via de firewall te sturen).

[de echte flush]

Dat dacht ik ook, maar ping doet het wel Heb ondertussen ontdekt vanwaar het komt:

In bovenstaande capture uit de firewall zien we:

code:

38034.0: trust(i) len=66:90f652400c96->00121ebd8aa2/0800
              192.168.2.251 -> 192.168.4.2/6
              vhl=45, tos=00, id=0, frag=4000, ttl=64 tlen=52
              tcp:ports 80->49313, seq=4018285314, ack=2756469398, flag=8012/SYN/ACK

38034.0: trust(o) len=60:00121ebd8aa2->90f652400c96/0800
              192.168.4.2 -> 192.168.2.251/6
              vhl=45, tos=00, id=4989, frag=0000, ttl=64 tlen=40
              tcp:ports 49313->80, seq=2756469398, ack=4018285315, flag=5004/RST

Pakketje van device in vlan 2 stuurt het naar de firewall voor vlan 4 --> firewall doet zich voor als het ontvangende device in VLAN 4 en stuurt een 5004/RST naar het device in vlan2 terug (het src mac is dat van de firewall).

Op het device in VLAN4 zag ik ook enkel verkeer naar vlan2 maar nooit iets terug komen.

Uiteindelijk opgelost door in de firewall de optie tcp-syn-check uit te schakelen en nu werkt het wel. (kwam dus door de asymmetric routing -> het pakketje is opgezet vanuit een andere router en de firewall reset de connectie dan. Bij een ping gebeurd dit niet).


thanks allen voor de replys maar deze is dus opgelost