Verbinding tot s2s klantnetwerken vanuit engineeringnetwerk

[henkjan1995]

Ik ben momenteel met de onderstaande case bezig, waarbij ik er niet helemaal uitkom. Aangezien hier op Tweakers genoeg slimme mensen zitten, hoop ik daarom dat iemand mij hier verder mee kan helpen.

Het gaat om de volgende case:
Gebruikers (engineers) moeten op een veilige manier verbinding kunnen leggen met netwerken van klanten, voor het leveren van ondersteuning. Deze verbindingen naar klanten zijn IPSec site-to-site VPN-verbindingen die opgebouwd gaan worden vanuit een Fortigate (FortiOS 6.0+).

Nu klinkt dit in eerste instantie natuurlijk heel makkelijk om op te zetten, aangezien IPSec VPN-tunnels regelmatig gebruikt worden om bijvoorbeeld branch offices te koppelen aan een HQ.

Nu komt dan eigenlijk het lastigere vraagstuk (zie de tekening hieronder): de engineer zit verbonden op een LAN subnet (10.0.1.0/24) op FW2 (VDOM binnen Fortigate). FW2 heeft een koppeling met FW1 (ook een VDOM binnen Fortigate) over het 10.0.10.0/30 subnet. FW 1 heeft twee local subnets, (172.16.1.0/24 voor VPN A en 172.16.2.0/24 voor VPN B ) waar de IPSec-tunnel naar gelegd is. Deze subnets kunnen communicatie opzetten naar de remote subnets van de klanten (192.168.1.0/24 voor VPN A en 192.168.2.0/24 voor VPN B ).

De engineer moet nu vanuit zijn netwerk (10.0.1.0/24), in staat gesteld kunnen worden om een verbinding op te zetten naar het netwerk van VPN A (klant A), maar ook met VPN B (klant B ). Dit zal echter nooit gelijktijdig zijn, een engineer zal maar met 1 VPN-tunnel tegelijk verbinding moeten maken. De twee VPN netwerken van de klanten, mogen daarbij echter GEEN verbinding met elkaar kunnen maken.

Mijn vraag daarbij is dus: hoe kan ik dit het beste opzetten? Mijn eerste ingeving was om te kijken of het mogelijk was om een SSL VPN tunnel op te zetten, waarbij de engineer kan kiezen of deze verbinding wil opzetten met VPN A of met VPN B. Dit is echter binnen Fortigate helaas niet mogelijk (tenzij er gebruik gemaakt wordt van meerdere user accounts die voor iedere klant verschillend zijn, maar dat is niet gewenst).

Overigens heb ik daar nog een beperking bij: de klant kent alleen de routes naar de voor hem bekende remote subnets (die standaard opgebouwd zijn bij het opzetten van de S2S VPN). De routetabel ziet er daarbij als volgt uit:

Device - Network - Via gateway
Klant A - 172.16.1.0 - IPSec S2S VPN
Klant B - 172.16.2.0 - IPSec S2S VPN

FW 1 en FW 2 zijn in eigen beheer, waarbij alle benodigde routes aanwezig zijn.
Daar kom ik dus volgens mij ook al een probleem in tegen, aangezien er voor verkeer van source 10.0.1.0/24 in VPN A en VPN B geen route bekend is. Hierdoor lijkt het mij dus alleen mogelijk om vanuit het local subnet van VPN A (172.16.1.0/24) en VPN B (172.16.2.0/24) communicatie op te zetten. Klopt mijn redenatie hierbij? Misschien dat ik iets met NAT/VIP moet gaan doen om dit werkend te krijgen? In de configuratie hiervan heb ik echter bij Fortigate geen/weinig ervaring.

Heeft misschien iemand hier op Tweakers ervaring met een vergelijkbaar vraagstuk, of is er misschien iemand die mij hiermee verder kan helpen? Je bent er vrij in om andere voorstellen te doen in de netwerkopbouw, aangezien dit een nog niet bestaande situatie betreft (enige beperking is dat de engineer niet direct op FW1 mag inprikken, maar via FW2 moet gaan).

[Equator]

Wat wij deden, en dat is misschien niet de mooiste oplossing, was binnen elke VPN een 1 op 1 NAT te gebruiken met een totaal aparte IP reeks. Daarmee los je in ieder geval je routing issue op.

Het idee is dat een engineer dus geen verbinding maakt met IP 192.168.1.10 (bijvoorbeeld voor klant A) maar met 192.168.254.10 wat in de VPN verbinding wordt geNAT naar 192.168.1.10. Verkeer terug wordt weer ge source-NAT naar 192.168.253.10 waardoor het lijkt dat het daarvandaan komt.
Zo kan je per klant een eigen NAT subnet hanteren. Zolang je maar vanuit beide kanten de NAT goed inregelt.

Deze VPN verbindingen waren overigens always-on, maar dat zou je waarschijnlijk nog met een on demand oplossing kunnen oplossen.

[jvanhambelgium]

Wij hebben ook een erg omvangrijke setup draaien en hebben tijdens de project-uitrol voor deze monitoring & management diensten overleg met de klant en laten hem uit enkele ranges kiezen die zeker lokaal niet botsen en gebruiken ook een aantal systemen (virtueel "onsite" of centrall gehost bij ons) dewelke dual-homed zijn. 1 van die systemen is vb een Jumphost die dan 1 poot in een klanten-LAN heeft en de support mensen zullen hierop connecteren in geval van ondersteuning voor vb toestellen met HTTPS-interface oid. Andere VM's hebben voornamelijk de taak om events (snmp-pollings / snmp-traps) af te handelen, config-backups te nemen van klanten-devices (vb routers,switches,firewalls) en ook security-events te capteren (indien de klant SIEM diensten afneemt).

In jouw geval denk ik dat zo'n batterij aan "collectors" wat overkill gaat zijn en lijkt de VPN & NAT-piste wel gangbaar.