Hello everyone!

I have a question about SIP, maybe somebody can help.

We have a Mikrotik CCR v6.43.8 running as a PPPoE server with number of PPPoE clients. Each client is a simple SOHO router (not Mikrotik, not managed by us).

What I need is to recognize SIP packets when they are sent from those PPPoE clients to outside world.

If I simply watch ports UDP / TCP 5060-5061 on dynamic PPPoE interfaces, I can see packets. This bit is not a problem. The problem is if an unknown port is used.

Is there any way to recognise a SIP packet regardless TCP / UDP port?

I found the following in one of the forums:

It worked like that only:
I mean it works only if a SIP client is on a our CCR's LAN (in-interface=bridge-lan).
However, if a SIP client is behind a PPPoE router, that mangle rule is not working, therefore I can’t see SIP packets forwarded from PPPoE interfaces to a remote SIP server…

Changing chain from prerouting to forward in the mangle rule doesn’t help

Sorry if the description is a bit confusing.

Thank you in advance

My understanding, not the authority here, ... for non-encrypted packets, you can identify Session Initiation text that appears. I don't know how traffic is flowing through your router to tell you which chain. This is step 1.

Then you need to identify RTP (the audio) which gets randomly assigned to ports (usually between the 10K-20K range). See wire shark notes here.

You might tell us what you're trying to do. Otherwise, you may have to write a custom packet filter that reads the SIP session data then acts on that to go identify all the ports that were dynamically requested, for that initial session.

I don't know how traffic is flowing through your router to tell you which chain. This is step 1.
...
You might tell us what you're trying to do.

Hello pcunite,

Thank you very much for the answer. Our company provides an Internet access for a building. We have a direct connect from our Mikrotik (CCR1036) to Internet with a public static IP address. Then we have our own "management" lan and pppoe server for the clients. Each client has a router that creates a pppoe session to our Mikrotik. Once established, a dynamic pppoe interface is created in Mikrotik, and the client has an Internet access.

I'm trying to stop the pppoe clients using 3-rd party SIP providers, this is a building management policy. Therefore, I'm trying to intercept SIP traffic by the firewall filter on in-interface=all-ppp.

It works on forward chain if I watch traffic on ports 5060-5061. But if a different port(s) is used rather than 5060, I simply don't see the SIP traffic.

So, I thought if there is a possibility within Mikrotik to recognize a SIP (or RTP) packet coming from all-ppp; in similar way Wireshark does that: it recognizes and marks a packet as "SIP" regardless of a TCP or UDP port.

Will it not be easier to allow SIP traffic only to the SIP providers you / building management approves of with Address Lists?

Will it not be easier to allow SIP traffic only to the SIP providers you / building management approves of with Address Lists?

Thank you for the reply. Yes, you are correct, it would be much easier. However, the building management is the only allowed SIP provider if you are using the building Internet by the resident's usage agreement. ALL others should be blocked. I'm blocking them on ports 5060-5061. But that is the only mechanism I can make working to define that this is a SIP packet if a client is behind PPPoE router.

If a SIP client is on our LAN (not behind PPPoE), the code in my first post works regardless of the port that SIP client uses.

So, if SIP traffic is going from a PPPoE router to the outside world, and the port is different to 5060-5061, I can't stop it. (so far)

Thank you again for trying to help.

A bit of update, if someone is interested. The rule in my first post doesn't work if a SIP client uses TCP. Wireshark doesn't recognize such packets as "SIP" either.

This is a part of the problem. However I still can't recognize UDP SIP packets if they are sent from behind PPPoE.

Filtering ports 5060-5061 is the only method I'm aware of so far. If I find something I'll share the knowledge. Meanwhile, any help or ideas are welcome.