Fortinet policy werkt niet

[Verwijderd]

Hallo,

Na overstappen van internetprovider icm VOIP krijg ik geen externe gesprekken meer binnen.
De nieuwe situatie werkt met een softclient op de PC.
Uitbellen werkt prima, alleen inkomende gesprekken werken niet.

Ik heb inmiddels weten te achterhalen dat de Fortigate firewall de inkomende gesprekken blokkeert en geprobeerd deze dmv een policy door te laten maar helaas nog zonder succes.

De nieuwe telefooncentrale wordt gehost door de provider (KPN) en staat dus extern.
De firewall zit achter een router van de provider welke een VPN maakt met hun eigen site.

Ik heb een policy aangemaakt in de fortigate welke verkeer van het IP van de telefooncentrale door zou moeten laten naar het interne LAN. (zie afbeelding)
KPN SBC is de externe telefooncentrale, ik heb het IP onleesbaar gemaakt maar het komt overeen met het IP in de logging.

Als ik in de logging kijk zie ik het verkeer binnenkomen maar wordt het allemaal denied (zie 2e afbeelding)
Het destination IP 10.4.7.1 zoals te zien in de afbeelding is het IP van de WAN verbinding.

Het lijkt mij dat het verkeer niet goed gerouteerd wordt maar ik kan niet achterhalen waarom niet.
Kan iemand me in de juiste richting wijzen?

De firewall is een fortigate 60D met FortiOS 5.4

[ Voor 0% gewijzigd door Verwijderd op 04-04-2017 15:15 . Reden: plaatje aangepast; typo ]

[Yariva]

Hoi,

De Foritgate doet gewoon stateful inspection, de regel van buiten naar binnen werkt niet en is ook overbodig.

Ik denk dat je het probleem eerder moet bekijken in de extra web filters / applicatie profielen die je op die policy heb staan.

Staat er meer informatie in de security logs?

[ Voor 8% gewijzigd door Yariva op 04-04-2017 15:11 ]

[Verwijderd]

Yariva schreef op dinsdag 4 april 2017 @ 15:11:
Hoi,

De Foritgate doet gewoon stateful inspection, de regel van buiten naar binnen werkt niet en is ook overbodig.

Ik denk dat je het probleem eerder moet bekijken in de extra web filters / applicatie profielen die je op die policy heb staan.

Staat er meer informatie in de security logs?

De regel is wel nodig omdat er een implicit deny regel in staat, ik heb het plaatje aangepast zodat alle policy regels zichtbaar zijn.
De deny regel is ook de reden dat de inkomende gesprekken geblokkeerd worden, ik kan deze helaas niet weghalen omdat de firewall dan helemaal open staat.

[Yariva]

Verwijderd schreef op dinsdag 4 april 2017 @ 15:18:
[...]


De regel is wel nodig omdat er een implicit deny regel in staat, ik heb het plaatje aangepast zodat alle policy regels zichtbaar zijn.
De deny regel is ook de reden dat de inkomende gesprekken geblokkeerd worden, ik kan deze helaas niet weghalen omdat de firewall dan helemaal open staat.

Maar het verkeer hit die implicit deny policy toch nooit omdat het wordt gegenereerd vanuit je internal LAN en de FW dit bijhoudt? Als ik het fout heb hoor ik het ook graag van andere Tweakers, maar volgens mij is de policy op sequence nummer 2 overbodig.

Overigens klopt het dat de policy's hierna wel goed staan ingesteld, maar die gaan (zo te zien) naar VIP's

Het lijkt mij toch dat je moet kijken naar de profielen, zeker met die severity op high.

Overigens om twijfel weg te halen zou je de policy op sequence nummer 2 kunnen verwijderen. Kan je nog steeds het internet op? Dan deed hij vrij weinig

[toxict]

Check hier en dan het stukje over Flow...
Daarin moet je het zoeken denk ik.
Dan zie je als het goed is op een gegeven moment vanzelf waar het precies op stuk loopt:

https://blog.webernetz.ne...ting-fortigate-firewalls/

[Verwijderd]

Yariva schreef op dinsdag 4 april 2017 @ 15:37:
[...]


Maar het verkeer hit die implicit deny policy toch nooit omdat het wordt gegenereerd vanuit je internal LAN en de FW dit bijhoudt? Als ik het fout heb hoor ik het ook graag van andere Tweakers, maar volgens mij is de policy op sequence nummer 2 overbodig.

Overigens klopt het dat de policy's hierna wel goed staan ingesteld, maar die gaan (zo te zien) naar VIP's

Het lijkt mij toch dat je moet kijken naar de profielen, zeker met die severity op high.

Overigens om twijfel weg te halen zou je de policy op sequence nummer 2 kunnen verwijderen. Kan je nog steeds het internet op? Dan deed hij vrij weinig

Het gaat om de inkomende gesprekken dus van WAN -> LAN, uitgaande gesprekken werken prima.
In het log detail zie je bij ACTION ook DENY staan door policy regel 0 welke de implicit deny regel is.
Dus op de een of andere manier raakt hij toch die regel.

De VIP regels werken inderdaad prima en dit zou hetzelfde principe moeten zijn alleen dan van 1 extern IP naar het interne subnet.

[ChaserBoZ_]

De Fortigate heeft een ALG voor bepaalde protocollen, check deze link eens; http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

[Verwijderd]

ChaserBoZ_ schreef op dinsdag 4 april 2017 @ 16:11:
De Fortigate heeft een ALG voor bepaalde protocollen, check deze link eens; http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

Op aanraden van de provider heb ik SIP ALG helemaal uitgeschakeld, dit geeft blijkbaar meer problemen dan voordelen.

[ChaserBoZ_]

Verwijderd schreef op dinsdag 4 april 2017 @ 16:13:
[...]


Op aanraden van de provider heb ik SIP ALG helemaal uitgeschakeld, dit geeft blijkbaar meer problemen dan voordelen.

Klopt, in veel situaties. Ook dat biedt geen oplossing ?

[KennieNL]

Je KPN Voice regel gaat niets doen, zoals je zelf al ziet aan het aantal bytes.
De firewall weet namelijk niet waar het verkeer heen moet i.v.m. NAT.

Je toestellen zullen naar KPN een verbinding op zetten, en een tabel in de FortiGate houd dit bij en laat dan terugkerend verkeer door.
Er zijn meerdere 'session helpers' in de FortiGate aanwezig welke problemen kunnen veroorzaken, beste kun je met 'flow' het probleem achterhalen.

diagnose debug reset
diagnose debug enable
diagnose debug flow show console enable
diagnose debug flow filter saddr ip.van.kpn
diagnose debug flow trace start 10

De 'trace start 10' zal de 10 eerste matchende pakketjes laten zien, dit moet je dus aanzetten en dan een inkomend gesprek testen. Je kunt dit ook meerdere keren uitvoeren.

Je krijgt dan logging te zien wat precies met het pakketje gebeurd, als hier een session helper voorbij komt kan dit het probleem zijn.
Onder 'config system session-helper' staan de helpers.

[Verwijderd]

KennieNL schreef op dinsdag 4 april 2017 @ 16:23:
Je KPN Voice regel gaat niets doen, zoals je zelf al ziet aan het aantal bytes.
De firewall weet namelijk niet waar het verkeer heen moet i.v.m. NAT.

Je toestellen zullen naar KPN een verbinding op zetten, en een tabel in de FortiGate houd dit bij en laat dan terugkerend verkeer door.
Er zijn meerdere 'session helpers' in de FortiGate aanwezig welke problemen kunnen veroorzaken, beste kun je met 'flow' het probleem achterhalen.

diagnose debug reset
diagnose debug enable
diagnose debug flow show console enable
diagnose debug flow filter saddr ip.van.kpn
diagnose debug flow trace start 10

De 'trace start 10' zal de 10 eerste matchende pakketjes laten zien, dit moet je dus aanzetten en dan een inkomend gesprek testen. Je kunt dit ook meerdere keren uitvoeren.

Je krijgt dan logging te zien wat precies met het pakketje gebeurd, als hier een session helper voorbij komt kan dit het probleem zijn.
Onder 'config system session-helper' staan de helpers.

Dankje voor de tip, dit heb ik geprobeerd en vreemd genoeg zie ik hier geen enkele regel voorbij komen met het source adres van KPN als ik bel naar een van de beschikbare nummers.
Als ik dit doe met het destination adres ingesteld op de KPN server dan krijg ik wel resultaten van de uitgaande gesprekken.

De log details die ik gepost had komen uit de Local traffic log, ik begin me af te vragen of ik wel op juiste plek aan het kijken ben.
De source heeft wel het juiste IP in de details maar in de lijst laat hij het mac adres van de fortigate zien.

[KennieNL]

Sorry idd moest daddr zijn ipv saddr, gezien je client de verbinding naar KPN opbouwt.
Dus op dat moment zie je bij inkomende gesprekken niets? Zou ik eigenlijk zeer vreemd vinden

Normaal bouwt je telefoon via 5060 of 5061 (mits afwijkende poorten) een connectie op met de telefooncentrale. Inkomende of uitgaande gesprekken gaan over deze sessie heen en zou volgens mij geen verschil mogen maken. Spraak kan wat lastiger zijn.

Wie is de 10.4.7.1? Wordt er in de router welke ervoor staat nog iets met NAT gedaan?

[Verwijderd]

KennieNL schreef op dinsdag 4 april 2017 @ 18:02:
Sorry idd moest daddr zijn ipv saddr, gezien je client de verbinding naar KPN opbouwt.
Dus op dat moment zie je bij inkomende gesprekken niets? Zou ik eigenlijk zeer vreemd vinden

Normaal bouwt je telefoon via 5060 of 5061 (mits afwijkende poorten) een connectie op met de telefooncentrale. Inkomende of uitgaande gesprekken gaan over deze sessie heen en zou volgens mij geen verschil mogen maken. Spraak kan wat lastiger zijn.

Wie is de 10.4.7.1? Wordt er in de router welke ervoor staat nog iets met NAT gedaan?

Het vreemde is dat uitgaand bellen prima werkt en de geluidskwaliteit ook goed is.
Het zijn softclients op de PC's en deze maken inderdaad verbinding via 5060.
In het log zoals in de screenshot te zien is, is de source het KPN IP op poort 5060 en de destination het fortigate WAN IP op poort 36279 wat ik al vreemd vind.

10.4.7.1 is het IP van de WAN interface op de fortigate.
Volgens de partij die de router geleverd en ingesteld heeft doen ze geen NAT op de router.

[KennieNL]

Tjah... 10.4.7.1 is geen public IP adres en daar wordt dus ook ergens NAT uitgevoerd als het KPN IP een public IP is en er geen andere constructie is (bijv. VPN voor VoIP of aparte VLAN etc.).

Je zou eens kunnen testen om een PC/laptop aan die router aan te sluiten en kijken of je het probleem ook hebt. Zo kun je eventueel uitsluiten of het de FortiGate is of niet.

[ Voor 6% gewijzigd door KennieNL op 04-04-2017 19:34 ]

[Verwijderd]

We hebben een aantal toestellen met een switch op de router aangesloten en die zijn wel gewoon bereikbaar.
Het lijkt dus toch in de fortigate te zitten.

[BluRay]

Probeer eens IPS, AV en al die security features van je rule af te halen. Of maak een aparte rule voor je telefoons en plaats die boven de bestaande rule. Ik heb (nog) geen ervaring met 5.4. Wij draaien zelf 5.2.x op verschillende FG's (van 30D's tot 800c's). Kijk ook eens in de release notes en probeer desnoods een downgrade. Belangrijk is om ALG en SIP-helper uit te schakelen, maar je gaf aan dat al te hebben gedaan.

[ Voor 47% gewijzigd door BluRay op 05-04-2017 19:42 ]

[ik222]

Heb je de fortigate ook herstart na het uitschakelen van SIP ALG? Meen me te herinneren dat bij een Fortigate alleen dan deze setting echt uit komt te staan.

[Verwijderd]

De ALG en de SIP helper zijn inderdaad uitgeschakeld en ik heb de FortiGate daarna een reboot gegeven.

Sinds vanochtend komen er opeens wel gesprekken binnen terwijl er sinds gisteren niks meer gewijzigd is in de fortigate.
Alleen lijkt de audio nu one-way te zijn, de bellende partij hoort me wel maar ik hoor niks.

[Verwijderd]

Even een update voor de mensen die hier ook eventueel tegenaan lopen.
In dit geval moest SIP ALG en de sip helper wel aan staan, het draait nu als een zonnetje.
Het gaat om een fortigate 60D met FortiOS 5.4