Inbound TCP connection denied syn flag ASA

[wallywally]

Hallo,

Kan iemand mij uitleggen wat de melding exact zegt? Ik heb tonnen aan informatie gelezen over securitylevels, over assymetrische routeringen over globale accesslists en noem maar op. Maar de exacte definitie van de foutmelding kan ik niet vinden.

Het gaat om Inbound TCP connection denied from ipSIPCENTRALE/60747 to ipSIPCLIENT/8085 flags SYN on interface

Ik zal even de situatie schetsen (sorry voor de crappy paint )



Dit is de situatie. Eerder zat de SIP client ook gewoon op de fortigate maar vanwege een migratie moet dat nu even op deze manier en gaat de SIP client achter de ASA en zit de centrale achter de fortigate.

Op de ASA staat een route naar 172.16.3.x/24 (to fortigate)
Op de fortigate staat een route naar 10.0.0.x/24 (to asa)

Ook worden op beide firewalls het traffic allowed.
Securitylevel heb ik op 50 gehad en op 5, dit maakt geen verschil.
Er zijn geen globale accesslists die dit blokkeren of enigsinds beinvloeden.
NAT is niet aanwezig, alles wordt gerouteerd.

Nu krijg ik de melding dus op de interface van de ASA waar de voipclient op zit. Eerder heb ik deze melding wel eens gehad bij een gelijk securitylevel, dan moet je intra interface traffic aanzetten maar nu lijkt het niet eens op het probleem van toen..

Wat zegt de melding precies? Is het zo dat er een synflag gezet wordt op de transport-VLAN-interface waarna ook de sipclient-interface een SYNflag probeert te setten en het daarom botst met elkaar? Veel meer kan ik er niet van maken?

Edit ; dit kwam naar voren in een change die nu gerollbackt is, maar dit was niet het voornaamste probleem om de rollback te doen. Toch ben ik er niet helemaal gerust op, ik heb 18K hits op de accesslist waarvan er 100 of 200 terug komen met deze synflag melding. De change moet nog gaan gebeuren en daarom wil ik even weten waar ik tegen aan kijk.

Alvast bedankt

[ Voor 10% gewijzigd door wallywally op 05-10-2017 17:00 ]

[ik222]

Die melding zegt niets meer of minder dan dat het aangegeven verkeer geblokkeerd wordt. Waarom is niet te zeggen zonder de configuratie te hebben.

[wallywally]

ik222 schreef op donderdag 5 oktober 2017 @ 17:25:
Die melding zegt niets meer of minder dan dat het aangegeven verkeer geblokkeerd wordt. Waarom is niet te zeggen zonder de configuratie te hebben.

Ja zo ver was ik ook, maar het lijkt niet alleen in ACL's of iets dergelijks te zitten, een assymetrische routering zou ook een probleem kunnen zijn voor zover ik zaken tegen ben gekomen. Dus dan klopt het niet helemaal dat het geblockt wordt door de firewall, dan wordt het geblockt om een andere reden; namelijk routering. Dus ik zoek even zaken die ik óók naast ACL en routering nog na moet lopen. Ik zal kijken of ik delen van de config kan posten.

[ik222]

Ja dat kan inderdaad meer redenen hebben dan puur ACL's. Maar zeker zonder config is dat gokken, die melding zegt niets over de reden.

[_Hades_]

Probeer de tcp ttl eens wat op te hogen. In veel firewalls (asa ook geloof ik) staat dit default op 60. Ik kom geregeld tegen dat dit voor sip registraties in centrales hoger staat. 180 bijvoorbeeld..

[PerfectPC]

Asymetrische routering lijkt me niet de oorzaak van het issue te zijn, dan zou je return traffiek (SYN/ACK) gedropped zien op een andere interface. Dit wijst echt op het ontbreken van een correcte acl.
Je spreekt over securitylevel 5, gaat dat over de interface naar het transport net? Wat is de security level van de interface naar de SIP client? Gaat SIP verkeer op UDP/5060 of TCP/5061 wel netjes over en weer?

[_-= Erikje =-_]

Vraag is eerder; heb je wel een ACL die connecties vanaf je sipcentrale naar de sipclient op TCP/8085 toestaat?

[Kabouterplop01]

asymetrisch maakt niets uit, zolang het gerouteerd wordt. (met ping testen) als je reply krijgt-->OK.
SYN wil zeggen er wordt een TCP sessie opgezet. Ergens staat een deny in je accesslist(s). (Op het device dat deze log regel heeft veroorzaakt)
kun je wel pingen door die interface, of staat dat dicht?
(debug op je accesslist met een filter, of tcpdumpen met een filter)

(/me thinks dat het een sessie voor bepaalde provisioning messages is, die wordt getracht te "establishen")

[Barreljan]

probeer eens op de asa:

packet-tracer input <interface-outside> tcp ipSIPCENTRALE 60747 ipSIPCLIENT 8085 detailed

Waarbij <interface-outside> het interface naam betreft op de asa aan de transport vlan kant.
Je kan dat het hele pad volgen en waar deze misschien fout gaat.