2 gateways in één netwerk

[Verwijderd]

Aangezien Sonicwall niet echt met een zinnig antwoord komt, plaats
ik mijn vraag toch even hier op het forum.

Ik heb namelijk een netwerk met een aantal servers in de 192.168.1.0 range.
Daarnaast heb ik een balancer/gateway op IP 192.168.1.100

Hierbij heb ik een Sonicwall geplaatst, deze Sonicwall dient puur voor het opzetten van een VPN verbinding naar dit netwerk en daarna wil ik de servers overnemen middels RDP. (hiervoor gebruikte we een Draytek dat ging goed, echter nu met de Sonicwall niet)
De Sonicwall heeft het IP 192.168.1.200

Wat is het geval, ik zet een VPN verbinding op met de Sonicwall dit gaat allemaal perfect.
Echter wil ik dan een van de servers overnemen, dan dien ik eerst op de server de gateway 192.168.1.200 in te stellen, echter is de server dan niet meer zichtbaar voor de users die naar 192.168.1.100 kijken. (de balancer, en veel zwaardere gateway)
Ik zou dus graag willen dat de server gewoon netjes naar 192.168.1.100 blijft kijken, en dat ik deze gewoon kan overnemen middels de VPN.
Ik heb ook geprobeerd 2 gateways in te stellen, echter was er dan niets meer bereikbaar, ofwel niet de gewenste situatie. Het is ook niet ideaal alle servers bijvoorbeeld 2 netwerkkaarten te geven of een gateway toe te voegen of daar met routing rules te gaan werken.
Ik wil dus het liefst dat alles wat verbinding maakt met de Sonicwall gelijk wordt doorgerouteerd naar de andere gateway. Hoe zou ik dit het beste kunnen aanpakken?

Sonicwall zei hierover het volgende:

I have been examining your case and as conclusion .- the way you have your topology designed, your sonicwall UTM absolutely do not impact or influence for the connection type you are trying to achieve.

In fact connection as you have it through the sonicwall works as should be.

The ideal procedure, in your case, is creating Nat Policies in the server itself for the Gateway desired.

Information has been provided, for this reason I will put the status of this SR to pending closed. Should any problem occur, you can still update the request within 5 days after this post. After that amount of time, our system will shut down the request permanently. Please mind that you can use this SR number, as a reference for future support requests.
We look forward to supporting you in the future

[Rolfie]

Waarschijnlijk gebruik je een aparte IP range voor je VPN clients?

Dan gewoon een static route op je balancer/gateway invullen dat hij die IP range kan vinden bij de 192.168.1.200. Dit zou voldoende moeten zijn om het te laten werken.

[CyBeR]

Dat, of je VPN gateway laten NATten.

[Verwijderd]

Ik gebruik inderdaad een andere IP range voor de VPN clients.
Moet ik dit ook doen in geval van VPN tunnels?

Hoe zou ik exact mijn VPN gateway moeten natten?
Een rule met een from ip range vpn user, naar balancer/gateway?

[Dennism]

Waarom gebruik je eigenlijk voor dit soort zaken niet een sonicwall SSL-VPN appliance, deze zijn hiervoor gemaakt. Je lijkt nu (als ik de supportcall goed begrijp) een sonicwall security appliance hiervoor te gebruiken welke eigenlijk bedoeld zijn als gateway/UTM device en het opzetten van non site-to-site verbindingen eigenlijk als secundaire taak heeft.

[Zoetjuh]

Als je VPN-client in een ander subnet komt, moet alles gerouteerd worden.
Dan is het niet vreemd dat je server er niet gaat komen.

Immers: Server -> Loadbalancer -> ??

Je zou op je loadbalancer een route kunnen plaatsen voor het VPN-client subnet naar de VPN-appliance, maar ook dat is vragen om problemen (je krijgt dan zo'n leuk driehoekje: je server stuurt naar de load balancer, die stuurt 't door naar de VPN-appliance, maar terugkerend verkeer gaat direct vanaf de VPN-appliance naar de server.. en je server verwacht een pakket vanaf het MAC van de load balancer).

Oplossing zou kunnen zijn:
- Aan de andere kant van je Loadbalancer de VPN-appliance plaatsen
- Een volledige NAT waarbij je VPN-client 1:1 geNAT worden met één of meerdere IP's in je subnet waar je server zit (als je appliance dat ondersteund)
- Je VPN-clients een IP laten krijgen in het zelfde subnet (als je appliance dat ondersteund)

Althans, als je het mij zou vragen.

[Verwijderd]

Ik heb niet voor een SSL appliance gekozen, omdat ik toch nog regelmatig zie dat er lekken gevonden worden in de SSL vpn verbindingen. Tevens zijn daar geen tunnels mee op te zetten naar anders appliances.
Tevens dit voor de Security Suite, om zo al het verkeer ook virussen te scannen.

Ik zal tevens een tekening toevoegen waarin te zien is hoe het nu is.
De Sonicwall heeft ook een ander extern IP als de andere router.
Volgens mij staat hij dat dus dan al.

Overigens maak ik in de Sonicwall altijd een aparte zone aan met een aparte vlan meestal onder de X0 en gebruik dan de interne DHCP voor VPN clients, dit omdat het vaak in de eigen IP range niet lekker werkt.
Echter zijn alle clients dan altijd toegangkelijk. Jullie zeggen dat dit niet kan.
Maar ook de huidige servers zijn wel toegangkelijk als ik maar de gateway aanpas naar die van de Sonicwall.

[Dennism]

Hoe bouw je nu een VPN op dan naar de sonicwall, een tunnel of met de Global VPN client denk ik, aangezien je SSL-VPN niet lijkt te vertrouwen en daar gaat nu ws iets fout in de routering of de firewall rules van de sonicwall.

Waarom kies je er niet voor de loadbalancer achter de Sonicwall te plaatsen, zodat je de sonicwall kan gebruiken waar die primair voor bedoeld is, Gateway en UTM met als bijkomstigheid dat je VPN's ook direct zullen werken omdat de sonicwall dan gateway is voor je hele netwerk.

[Verwijderd]

Ik bouw een VPN op met de Sonicwall middels de Sonicwall Global VPN Client.
Vervolgens wil ik ook vanaf bepaalde locaties een vaste tunnel gaan opzetten met de Sonicwall vanaf een andere Sonicwall.

Dit omdat er enorm veel verkeer is op de servers achter de balancer, dit verkeer trekt de Sonicwall nooit.
Deze kan er dus helaas niet achter.
Echter nu werken we met een Draytek, als vervanging daarvan moest de Sonicwall komen.
Maar die werkt wel perfect. Deze heeft ook ook een andere gateway.

Hoe is dat dan mogelijk?

[Dennism]

hoe stond de draytek qua netwerk e.d. ingesteld? Neem dat eens 1 op 1 over in de sonicwall.

Wat voor sonicwall heb je trouwens, afhankelijk van het model kunnen deze aardig wat traffic handelen hoor, zeker als je voor de zones die het niet nodig hebben de UTM features beperkt of uitzet. Heb diverse implementaties gezien met sonicwalls voor een loadbalancer. Als je een basis model hebt zal dit uiteraard wel lastig zijn.

[Brahiewahiewa]

Verwijderd schreef op vrijdag 19 juli 2013 @ 18:46:
...Echter nu werken we met een Draytek, als vervanging daarvan moest de Sonicwall komen.
Maar die werkt wel perfect. Deze heeft ook ook een andere gateway.

Hoe is dat dan mogelijk?

Begin eens met de Sonicwall het IP-adres van de Draytek te geven.
(en de Draytek los te koppelen, anders gaan zowel de Draytek als de Sonicwall piepen)

[Verwijderd]

Het is een TZ250M en die kan het verkeer echt niet aan.
De Sonicwall die het gewenste verkeer aan kan begint met een prijs van 6000 euro.
En deze wil ik dan tevens ook redundant. En het is alleen voor VPN connectie.

Overigens zou ik niet weten wat je daar mee wilt Brahiewahiewa, het zal echt niet spontaan gaan werken als ik de Sonicwall het zelfde IP geef als de Draytek. Dat slaat nergens op.
Hij zit in het zelfde netwerk het is allemaal gelijkwaardig ingericht, en het conflicteert ook niet.

[pablo_p]

Ik zie drie opties hiervoor, de eerste twee zijn al genoemd:

1. NAT overload op de Sonicwall, zodat verkeer vanuit de VPN tunnel dmv een NAT overload geNAT worden achter het IP adres 192.168.1.200
2. Op de betreffende servers statische routes maken (persistent!), om het VPN subnet naar 192.168.1.200 te routeren
3. De Sonicwall VPN connectie op een aparte interface termineren van de firewall/gateway. Effectief betekent dat dat je een interconnectie VLAN aanmaakt, waarop alleen de sonic firewall en de huidge gateway zitten. Op je Huidige gateway maken je daarna statische routering aan rvoor het VPN subnet richting de sonic wall. Op de Sonicwall routeer je 192.168.1.0/24 naar de gateway. Op de gateway heb je daarna de mogelijkheid om verkeer te filteren, zodat je daar ook (extra) kan bepalen welk verkeer de richting de sonicwall en vanuit de sonicwall is toegestaan.

De verschillende oplossingen hebben voor- en nadelen.

Persoonlijk houd ik er niet van om extra routering op servers te plaatsen. (optie 2). Ik vind dat het netwerk de routering moet regelen, niet servers. Maar daarmee kom je om een smaak/stijl discussie. En optie 1 heeft als nadele dat je op de servers niet meer kan zien welke client er connect.

Het voordeel van de 3e oplossing is, dat als je later ook VPN connectie richting andere netwerken wilt maken, dat je dat geoon kan toevoegen. In de omgevingen waar ik werk, worden dit soort koppeling altijd in een interconnectie netwerk getermineerd, achter een firewall... en nooit in een segment waar ook servers zijn aangesloten.

[Brahiewahiewa]

Zoals je zelf al gezien hebt, werkt VPN wel als de default gateway op de client machines naar de Sonicwall verwijzen, maar dan heb je op die machines geen internet (of andere IPverbingen buiten het subnet). Verklaring: d'r staat in je router/loadbalancer ongetwijfeld wèl een statische route naar de Draytek en niet naar je Sonicwall. Omdat je niet de indruk geeft dat je de route tabel van de router/loadbalancer zelf kunt wijzigen, is mijn voorstel om de Sonicwall tijdelijk het IP-adres van de Draytek te geven; als het dan wel werkt, weet je wat je aan moet (laten) passen.

[Verwijderd]

Ik kan wanneer nodig gewoon de routetable van de router/loadbalancer aanpassen.
Hier staan geen rules in voor de Draytek. Tevens heb ik gekeken naar de settings van de Draytek, deze zijn allemaal standaard. Er staan geen speciale dingen in. Geen routers, geen NAT rules.

Toch vreemd dat dit wel werkt..
Ik ben er nog niet helemaal uit hoe ik de routering in de Sonicwall moet opzetten.
De volgende items moet ik opgeven: (ik zet eronder zoals deze mij lijkt te zijn)

Source Destination Service Gateway Interface Metric Priority Probe

VPN Zone 192.168.1.100 ANY 0.0.0.0 X1 20 1

[Verwijderd]

Ik heb het gevonden :-)
Met de volgende NAT rule werkt het perfect:

Source:
Original: VPN
Translated: X0 IP

Destination:
Original: Any
Translated: Original

Service:
Original: Any
Translated: Original

Interface:
Inbound: Any
Outboud: X0

Priority: 11

Ik moet deze regel alleen wel voor elk VPN tunnel maken.
(en eentje voor de VLAN van de VPN clients)
En dan kies ik bij source telkens het network van de andere zijde van de VPN.
Bijv. 192.168.3.0/255.255.255.0

Ik weet niet of jullie nog opmerkingen over deze methode hebben?
Maar hij lijkt nu goed te werken!

[Pauwl]

Dat kan, daarmee stel je inderdaad in dat al het VPN verkeer genat wordt achter het interne adres van de sonicwall, 192.168.1.200
Verkeer van de server terug naar de vpn source zal gaan omdat het verkeer van 192.168.1.200 afkomstig is.
Wil je echter verkeer initieren vanaf een server naar een vpn source toe, dan werkt dit niet omdat er dan geen nat translatie actief is.
Is dat niet nodig, dan werkt dit verder prima, zoals ook al door andere mensen aangegeven.
Is dat wel nodig, dan zou ik in dat geval opteren voor optie 3 zoals aangegeven door pablo_p.
Ik ben zelf ook niet echt fan van meerdere gatways binnen 1 segment, je moet dan toch vaak met statische routes op hosts werken of NAT truukjes toepassen.