Vigor 2960 Site To Site VPN met een tweede gateway in LAN

[Verwijderd]

Hoi,

Ik ben bezig met het opzetten van een Site-To-Site VPN verbinding tussen ons kantoor en ons data-center locatie. In het data-center hebben wij een Juniper firewall draaien die de verbinding het internet verzorgt. 2 weken terug hebben wij een DrayTek Vigor firewall erbij geplaatst met een eigen internet verbinding. Wij willen ons VPN netwerk gescheiden houden, vandaar een tweede firewall.

De situatie is als volgt:
https://drive.google.com/...K4xSMQzMtQzlCUlY2SnM/view

Vanuit ons kantoor kan ik pingen naar 10.1.0.253 wat dus de DrayTek local LAN is. Pingen naar 10.1.1.8 werkt niet. De DrayTek links kan wel naar 10.1.1.8 pingen. Lijkt alsof de route vanuit ons kantoor via de tunnel verder in het LAN links niet wordt begrepen. Ik heb dus een verbinding tussen de twee DrayTek's en ik kan tot aan de LAN van DrayTek links wel pingen, maar niet verder.

Alle firewall rules staan verder uit. Vanuit de DrayTek links kan ik wel pingen tot 192.168.0.1 en niet verder. Moet ik toch bepaalde firewall rules instellen om het verkeer toe te staan?

De server 10.1.1.8 gaat op internet via de 10.1.0.1 firewall. Dat is zijn gateway. Ik probeer dus vanuit ons kantoor via een andere verbinding op de server te komen wat in hetzelfde LAN netwerk zit.

Suggesties zijn welkom. Ik post binnenkort nog verder configuratieschermen als dat nodig is.

Groeten,
SKO85

[ Voor 7% gewijzigd door Verwijderd op 14-06-2016 20:51 ]

[DiedX]

Heb je op je 10.1.1.8 wel een route staan naar je officenet?

[Verwijderd]

Ik probeer vanuit de DrayTek (192.168.0.1) te pingen naar 10.1.1.8. Dat werkt ook niet. De DrayTek's kunnen elkaars LAN-IP wel pingen, maar niet verder in beide netwerken.

De 10.1.1.8 servers gateway is 10.1.0.1 voor internet verkeer. Die hoeft niet naar het 192.168.0.0 netwerk te kijken. Ik probeer juist vanuit de office-kant naar 10.1.1.8 te komen, maar aangezien de DrayTek's niet eens elkaars netwerken kunnen pingen, lijkt het mij een probleem in deroutering van de IPSec tunnel. De Remote IP is ingesteld op subnet /16. Dus aan de ene kant 192.16.0.0/16 en de andere kant 10.1.0.0/16.

[DiedX]

Maar kan je vanuit de DrayTek in het datacenter wel bij de Webserver?

[Verwijderd]

Ja, de DrayTek links in het Data-Center kan wel pingen naar 10.1.1.8. Hij kan dus alle systemen in het LAN netwerk gewoon benaderen. De andere DrayTek rechts kan dus niet pingen naar 10.1.1.8, maar wel tot de LAN van de DrayTek links (10.1.0.253).

[BluRay]

Staat je tunnel in route of NAT mode? (Als je deze optie hebt op je Dray's)

[Verwijderd]

Ik heb beide mode's getest. NAT mode geeft niet eens een PING tussen de DrayTek's onderling. In ROUTE mode werkt dat wel. Dus van een DrayTek kan ik op de LAN van een ander DrayTek dan pingen, maar niet verder.

De Gateway van de server 10.1.1.8 is niet de DrayTek zelf. Ik kan me voorstel dat het pakketje van een PING verzoek daarom niet terug gaat naar de DrayTek, maar via de Juniper firewall weer naar buiten. Is het mogelijk om de route naar 10.1.1.8 dan via 10.1.0.1 te laten lopen zodat het pakketje via die weg terug komt naar de DrayTek? Moet ik dan ook iets in de Juniper toevoegen? Een static route naar 192.168.0.0 via 10.1.0.253?

Hieronder wat meer info. DrayTek links kan pingen naar 10.1.1.8

code:

PING 10.1.1.8 (10.1.1.8) from 10.1.0.253: 56 data bytes
64 bytes from 10.1.1.8: icmp_seq=0 ttl=127 time=14.5 ms
64 bytes from 10.1.1.8: icmp_seq=1 ttl=127 time=1.7 ms
64 bytes from 10.1.1.8: icmp_seq=2 ttl=127 time=1.5 ms
64 bytes from 10.1.1.8: icmp_seq=3 ttl=127 time=1.6 ms
64 bytes from 10.1.1.8: icmp_seq=4 ttl=127 time=1.4 ms

--- 10.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.4/4.1/14.5 ms
Send ICMP ECHO_REQUEST packets done.

Ik heb zitten spelen met de route via de Juniper (10.1.0.1). Static route toegevoegd in de linke DrayTek van 10.1.0.0/16 via gateway 10.1.0.1. De Tracert ziet er dan zo uit.

code:

1 10.1.0.1 (10.1.0.1) 1.164 ms 1.123 ms 0.959 ms
 2 10.1.1.8 (10.1.1.8) 1.515 ms * 1.609 ms
Traceroute done.

Je kan zien dat de DrayTek links de response dan via de Juniper krijgt. De DrayTek rechts (office) kan wel pingen naar 10.1.0.253 (De linke DrayTek).

code:

PING 10.1.0.253 (10.1.0.253) from 192.168.1.1: 56 data bytes
64 bytes from 10.1.0.253: icmp_seq=0 ttl=64 time=7.1 ms
64 bytes from 10.1.0.253: icmp_seq=1 ttl=64 time=6.9 ms
64 bytes from 10.1.0.253: icmp_seq=2 ttl=64 time=6.6 ms
64 bytes from 10.1.0.253: icmp_seq=3 ttl=64 time=6.7 ms
64 bytes from 10.1.0.253: icmp_seq=4 ttl=64 time=6.7 ms

--- 10.1.0.253 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 6.6/6.8/7.1 ms
Send ICMP ECHO_REQUEST packets done.

Als ik dan probeer te pingen naar 10.1.1.8 van rechts dan zie ik geen reply.

code:

PING 10.1.1.8 (10.1.1.8) from 192.168.1.1: 56 data bytes

--- 10.1.1.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
Send ICMP ECHO_REQUEST packets done.

En de Tracert van de DrayTek rechts naar de server (uiteindelijk een timeout):

code:

1 10.1.0.253 (10.1.0.253) 6.864 ms 11.575 ms 6.452 ms
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 6 * * *
 7 * * *
 8 * * *

Groeten,
SKO85

[Verwijderd]

Ok, de oplossing is gevonden. De oplossing moet op twee plekken ingesteld worden. Het zat in de routering van de DrayTek en de Juniper aan de linker kant.

In mijn geval heb ik een extra static route moeten toevoegen in de linker DrayTek om alle 10.1.0.0/16 verkeer via de Juniper (10.1.0.1) router te halen. Metric heb ik op 1 staan.

Daarmee ben je er niet. De Juniper moet ook weten dat alle responses naar 192.168.0.0 net-werk via de DrayTek moeten. In de Juniper heb ik dus ook een static route toegevoegd 192.168.0.0 naar gateway 10.1.0.253.

• Op deze manier krijg je een verzoek vanuit de DrayTek rechts (ping naar 10.1.1.8)
• Het verzoek komt links in de DrayTek.
• De DrayTek links gaat het verzoek doorsturen naar de Juniper
• De Juniper stuurt het door naar de juiste server
• De server geeft een reply terug aan de Juniper
• De Juniper geeft een reply aan de DrayTek links
• De DrayTek links geeft het dan door aan de DrayTek rechts etc.

Achteraf is het altijd vrij logisch Ik hoop dat iemand anders hier wat aan heeft en niet lang hoeft te puzzelen