Vraagje ivm firewall redirecting

[ITnetadmin]

Ik zit hier met een Fortigate te werken momenteel.
Het probleem bestaat hem hierin:
We hebben een multihomed netwerk, Belgacom en Telenet.
Bij Telenet hebben we een fixed IP, over deze lijn gaan standaard alle connecties naar buiten toe.
Bij Belgacom hebben we een IP pack met een aantal fixed IPs.

Users die van buitenaf op het intranet willen, surfen naar een URL die geredirect wordt naar een van de IP adressen in onze Belgacom pool.
Van daaruit stuurt de firewall hen naar het fixed IP van de webserver die het intranet afhandelt. Het gaat hem om een Sharepoint.
Dit werkt.

Van binnenuit echter slaagt niemand erin om via die (externe) URL op het intranet te geraken. Er werd eerst gedacht aan een DNS issue. De DNS bleek problemen te hebben, maar een snelle test via IP wees uit dat de situatie zich ook voordoet wanneer men op IP adres surft: van buitenaf geraakt men er, van binnenuit niet.

Ik denk dat de firewall de redirect gewoon niet uitvoert, omdat de connection policy wan2>internal zegt, en de unit gewoon de internal>internal verbinding niet redirect, ook al wordt er op de externe URL gesurft.
Een lokale DNS redirect met een apart intern IP werkt niet fatsoenlijk. Dit zou mogelijk komen omdat een aantal links op de sharepoint via de externe URL of IP gecode zijn, en het spul weer hangt op het moment dat hij met deze geconfronteerd wordt.
Momenteel geraak ik niet op de sharepoint ingelogd als admin dus kan ik het niet verder testen.

De makkelijkste oplossing zou zijn erin slagen om de Fortigate (waar volgens mij nog altijd het probleem ligt) redirect issue op te lossen.
Any ideas?

[meon]

Ik neem aan dat iemand met netwerkkennis hierbij kan helpen, maar mocht dat niet lukken:
Welke versie van SharePoint? Ik heb al vaker met split DNS, aangepaste AAM-settings in SharePoint en een rewrite-rule in IIS dingen uiteindelijk toch aan de praat gekregen...

[ITnetadmin]

No clue; ik beheer de sharepoint niet en heb geen toegang momenteel; enkel een domain admin account en een admin account voor de fortigate.
Enne, ik ben hier effe de de facto netwerkbeheerder. Het is niet mijn netwerk, dus blijven bepaalde activiteiten/toestellen een "fog of war" hebben ivm hun configuratie; dat maakt het er niet makkelijker op.

Als ik een interne DNS redirect doe LIJKT het bij mij opgelost, want ik krijg een login/pwd request; maar de users klagen dat die request blijft terugkomen, enfin dat ze er niet ingeraken.
Voor mij zou het leuk zijn als ik de fortigate zo kan instellen dat ie de request gewoon juist forward.

Wanneer je naar een URL surft, surf je (na DNS resolution) gewoon naar een IP adres. Probleem is dat dat de IP is van de fortigate zelf; dus de connectie lijkt van binnenaf te komen, maar eerste pogingen slagen er niet in om de fortigate wijs te maken dat ie de requests vanop de internal interface moet behandelen op dezelfde manier als wanneer ze op het juiste IP terechtkomen op de wan2 interface.

Denk dat ik sebiet ns ga zien of ik de switch zover krijg om een mirrorke op te stellen en ns wireshark los te laten op de data die daaruit vloeit.

Als ik collega's had hier zou ik nu ns brainstormen, maar als je er alleen staat moet je af en toe ns de mening van anderen inroepen, kwestie van geen stommiteiten te missen.

[meon]

Mja, sharepoint 2010 gaat sowieso moeilijk doen als je URL's gebruikt die niet als AAM geregistreerd staat. SharePoint en IIS is beetje can't live with or without eachother. Het is niet omdat IIS een bepaalde URL als binding heeft dat SharePoint daar goed mee gaat werken (zeker zaken als authenticatie en alles uit de _layouts-virtual directory), en andersom gaat het nog minder werken...
Met ShP 2013 hebben ze het nog wat eenvoudiger en ingewikkelder gemaakt tegelijk, vandaar m'n vraag naar versie

[UBremoved9108]

U heeft 2 locaties zegt u. Uw SharePoint server staat op één van die locaties neem ik aan? Indien u lokaal op die plaats naar de sharepoint IP surft, gaat dit verkeer toch nooit via de fortigate?
Indien u een lokaal IP benaderd, gaat dit toch nooit langs de standaardgateway, uw switch bepaald toch op basis van ARP entries naar waar uw request gaat?

Dan kan het toch nooit aan uw firewall liggen, of zie ik iets over het hoofd?

[ITnetadmin]

@meon: ik ben idd bang dat sharepoint daar een beetje moeilijk over doet; nu ben ik daar geen grote fan van in kleine omgevingen wegens overkill, maja, als het er staat...
Vandaar dat het me beter leek de redirect proberen op te lossen bij de Fortigate.

@cyber: sorry; ik kan me niet herinneren gezegd te hebben dat we 2 locaties hebben?

Intussen dit teruggevonden:
http://kb.fortinet.com/kb/documentLink. ... ID=FD33976
Nu ns zien of we dat in GUI inputs kunnen vertalen.

[UBremoved9108]

Te snel gelezen. Ik trok conclusie twee sites en vpn daartussen omdat je term multihomed gebruikte.

[ITnetadmin]

Sorry: multihomed is de term voor loadbalance/failover over meerdere lijnen, maar zonder te specifieren of je al dan niet aan loadbalance of failover doet. Je kan evengoed incoming over 1 lijn en outgoing over een andere doen, of nog andere configs.

Hier is wel een secondary site die met een fortigate via ip-sec is gekoppeld, maar dat is apart en maakt geen deel uit van deze problematiek. De servers staan wel degelijk in dezelfde locatie/subnet als waar ik test.

[UBremoved9108]

Als uw servers in hetzelfde subnet staan als uw clients, hoe kan dan uw verkeer de Fortigate passeren als je op lokaal IP surft?

Ik neem aan dat uw fortigate standaardgateway is voor al uw netwerkdevices?
Als een client naar u sharepoint server surft, passeert ie dan toch nooit de fortigate? Uw switchen en arp zorgen er dan voor dat uw request op de juiste ethernet poort toekomt?
Uw fortigate zit hier toch nergens tussen?

[ITnetadmin]

Nee, de gebruikers surfen naar een URL, een subdomein hier; dat domein staat geassigned op een van de belgacom IPs.
Aangezien DNS dat domein moet resolven naar dat extern IP, en dat IP bij de Fortigate hoort, moet de verbinding normaal gezien toch onze Fortigate passeren?

Onze clients weten niet dat ze intern surfen op dat moment, neem ik aan.
Als je in de interne DNS een aparte shortcut maakt, krijgen ze nl wel reactie van de webserver, maar geraken ze naar het schijnt niet ingelogd (dat zou dan weer een sharepoint issue kunnen zijn).

[ubremoved_539]

Van binnenuit echter slaagt niemand erin om via die (externe) URL op het intranet te geraken.

Dit is je echte probleem volgens mij... en is een klassiek probleem.

Google maar eens op "hairpin firewall".

[ITnetadmin]

Thx r2504; direct ns checken; btw, de link die ik eerder postte is eigenlijk het exacte probleem dat we hebben.
http://kb.fortinet.com/kb/documentLink. ... ID=FD33976

Normaal zou ik zoiets oplossen door gewoon een interne redirect in de DNS te steken (een cname), maar dat werkt dan weer niet met de externe url links die op intranet staan, en sharepoint doet er ook moeilijk over blijkbaar). Dat heb je met intranets die zowel intern als extern dienst doen.

[ubremoved_2964]

de interface op die firewall die de initiële request van je intranet binnenkrijgt tcpdumpen en ook de interface waar de sharepoint aan hangt, en kijken of de firewall de packets correct nat en of het verkeer in de andere richting terug gaat

was dat een linux firewall, dan was dat op 1-2-3 klaar daar moet je zelfs geen port mirroren, gewoon op de firewall zelf tcpdumpen

geen idee of dat met fortinet kan, ben geen fan van paid firewalls gezien er genoeg deftig opensource spul out there is

[ubremoved_2964]

die hairpinning in linux is vrij simpel ....

gewoon de masquerade regel toepassen op de uitgaande interface die aan publiek internet hangt, bvb in geval van eth0 de internet interface is:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

al het intern->intern (bvb eth1, eth2, .... ) verkeer zelfs over meerdere subnetten/netwerkinterfaces wordt dan niet genat

[ubremoved_539]

Normaal zou ik zoiets oplossen door gewoon een interne redirect in de DNS te steken (een cname), maar dat werkt dan weer niet met de externe url links die op intranet staan, en sharepoint doet er ook moeilijk over blijkbaar). Dat heb je met intranets die zowel intern als extern dienst doen.

Split DNS gebruiken.

[didi79]

Bij Palo Alto heet dat een U-turn NAT denk ik... Dat gebruiken wij althans om interne webservers op dezelfde (externe) dns naam beschikbaar voor interne clients.

Los daarvan: Is het hier niet gewoon de webserver die enkel naar een specifieke host header luistert ? Als je dan op ip of een andere naam connecteert gaat die gewoon niet reageren.