Two years ago I got connected to FTTH. Since then I use a Mikrotik CCR2004-1G-12S+2XS main router and -not the problem- a CRS305 and a CSS610 switch. My ISP offers a SIP telephone service, but only with IPv6 connection. OK, I know there is a IPv4 test connection although, but just with a extreme low capacity that does not even work by night. For telephone I use a Fritz-box, which is direct locally connected to the main router via a SFP to RJ45 (S-RJ01) converter module. This Fritz-box is configured not to work as a router, do no switch or WLAN or else, but be just a IPv6 DECT telephone base with LAN connection only. Still IPv6 DECT bases are rare. This has been tricky to configure, but it worked well for two years with several updates.

A few days ago I made an update for the CCR2004 router. It has still been running ROS 7.11 and then got updated to 7.14.1, and just now to 7.14.2. But since that first update, my SIP phone does not work anymore. In the past I used all UDP connection for SIP port 5060, but now I can not register my accounts with UDP. How ever, this works with TCP for the port 5060 SIP traffic. But now I have upstream UDP RTP contact only. That means, I can call someone, where the phone rings and my voice is present, but the downstream packets back do not pass through to my Fritz-box DECT base. And I can not be called. Of cause I have tried and changed a lot to solve this. But I did not manage that. It is special that AVM Fritz-boxes use 32 UDP ports 7078-7109 for RTP. 7078 or 7080 are used first. That eases filtering.

In a phone call, downstream incoming SIP & RTP UDP packets enter WAN, are counted and accepted in prerouting, and are accepted in forward chain, but they do not arrive at destination LAN port if they are UDP protocol. At port 5060 I have captured both TCP and UDP up- and downstream traffic. TCP works, but the UDP downstream does not arrive at LAN port, same as with RTP. The interface of the packets is not developed pppoe-out1 -> bridge1 -> sfp-sfpplus9 like with TCP, but just pppoe-out1 -> pppoe-out1 with UDP downstream. Captured with packet sniffer with IP protocol: udp & tcp, port: 7078 & 7080 & 5060 (->sip) filter.

UDP or TCP up:
Interface sfp-sfpplus9 . rx . Src. bridge1:sfp9mac . Dst. ISP-SIP_adr::20 . port: 7078->31632
Interface bridge1 ...... . rx . Src. bridge1:sfp9mac . Dst. ISP-SIP_adr::20 . port: 7078->31632
Interface pppoe-out1 .. tx . Src. pppoe-out1:mac . Dst. ISP-SIP_adr::20 . port: 7078->31632

UDP down ~ 12 (9-16)ms later:
Interface pppoe-out1 . rx . . Src. ISP-SIP_adr::20 . Dst. pppoe-out1:mac . port: 31632->7078
Interface pppoe-out1 . tx . . Src. ISP-SIP_adr::20 . Dst. bridge1:sfp9mac . port: 31632->7078
next up about 12ms later. TCP down looks reverse ordered like TCP/UDP up.


Actually in my raw ipv6 prerouting chain there are two filters to accept anything from source of a sip_server_ipv6 address list and separated same to destination of this address list. My ISP offers three /64 SIP server addresses, which are on that list, but just one address got used, no proxy. Address switches from A:B:C::8 for SIP to A:B:C::20 for RTP or else. In mangle there are four filters to mark packets with port [5060-5062,7078-7109], one for TCP and one for UDP with Dst. address list sip_server_ipv6 marking packets VOIP_to_WAN and same with Src. address list marking packets VOIP_to_LAN. I have tried filters with connection state "new". They match for a 1/2 percent of upstream packets, but not at all for downstream UDP packets, not even in prerouting chain. So connection marking will not work, and I mark every single packet. One rule for TCP and UDP is not possible, but they get same marking. I got same count results for mangle rules with rerouting or forward or post routing chain. I use forward chain for UDP downstream marking VOIP_to_LAN and additional passthrough filters in rerouting and in post routing chain count the same packet number. In the IPv6 filter rules there are two separated passthrough rules to count the packages matching either VOIP_to_LAN or VOIP_to_WAN marking. The packet count is almost perfect same for up and down and same to the raw rerouting chain. Packets are then last time together counted and forward accepted by a "defconf: established, related, untracked" rule, just with that connection states. Some rules like "accept IKE" are disabled, so there are no more different rules for TCP and UDP at all.

If the router is disconnected except for the Fritz-box, one PC and of cause pppoe WAN, a "defconf: enable for transparent firewall" top rule is enabled (just accept in raw rerouting chain) and in the filter rules the "established, related, untracked" rule is pulled to of the list: That does not help. In Webfig Interfaces->bridge1 and ->sfp-sfpplus9 allow to show the highly asymmetric traffic during a phone call.

I do not know anything about SIP ALG with IPv6. Seems it does not matter, if IPv4 sip service port and Direct Media are enabled or not. Are packets lost in postroute or even in the linux kernel of the router? Why is no new connection state labelled? The issue that there is no SIP downstream is quite common, but all cases I have found are based on IPv4 or related to multiple external addresses.

To me, it looks like the packets are being dropped at the bridge.

Do you have any firewall rules configured on the bridge itself (separate config from the firewall)?
Also, make sure the bridge settings have use-ip-firewall, use-ip-firewall-for-pppoe and use-ip-firewall-for-vlan are all set to no.

That doesn't mean traffic will bypass the firewall, this is for specific use case scenarios. If you do have it enabled, you need to make the firewall rules more granular, or you get results like you're experiencing. It also adds more processor overhead too, so try and work around it where you can.

If that doesn't work, it would be useful to see your exported configuration, with the flag show-sensitive to no.

The SIP helpers are only for IPv4, it's not needed for IPv5, as no NAT translation is being used.

I don't fully understand regarding the raw firewall rule, however, if you accept a packet there, it will still hit the other chains, mangle, NAT etc. Only if you drop the packet, that will stop it hitting the other chains.

How to change bridge settings here

https://help.mikrotik.com/docs/display/ ... +Switching

How to export your configuration here

https://help.mikrotik.com/docs/display/ ... tionExport

I was not aware about an easy src nat and a dst nat rule in bridge nat. They just accept everything without further filter. I can disable both without any effect. But they do have counters! So I see continuous basic traffic in srcnat not effected by a phone call, but the dstnat counts ten times more traffic in a phone call, if other ports are disconnected. However, bridge srcnat is not a bridge input counter.

At this time there are no filter rules at all set for the bridge. In the manual there is no word special related to CCR2004 bridge. But if I try to add one in WebFig, I can only select chain forward and action accept. Just to see the counters I have set up two bridge filter rules: Both forward accept with filter rule packet mark. There I can choose my IPv6 mangle rules VOIP_to_LAN and VOIP_to_WAN. The filter with VOIP_to_LAN counts just nothing, even during a phone call. But the filter with VOIP_to_WAN counts a basic stream. Counting rate stays constant, no matter of a phone call or not. May be this is not triggered by RTP? However, why is it triggered at all? Remember: The VOIP_to_WAN packet mark is set by a mangle rule if a packet -here not connection related, but any single packet is tested- is UDP or TCP protocol and related to any port of [5060-5062,7078-7109]. Here we are in early stage from LAN port to bridge, far away from mangle filter and WAN out…??? If I could, I would set a packet sniffer to see what is counted here. Now the test bridge filter are deleted again. I have although tried to add a direct filter with Dst. port [5060-5062,7078-7109], but I go:" Couldn´t add New Bridge filter Rule - ip matchers are valid only when mac-protocol is set to ip or ipv6". Ups, yes, I guess I will not change.

Both, use-ip-firewall and use-ip-firewall-for-pppoe have been set to yes. I have been hopeful, when I set them to no. But that had no effect. May a bit less stress for the CPU. I don´t need this bridge processing, so it is better off.

Thank you for the extra information.

I think the issue could now be, that you've made allot of changes in order to fix this, which may now backfire.

I'm happy to help further, however you will need to share your config, as we're shooting in the dark here.
It will also reveal anything you're not aware of, so maybe have a read of it yourself first, it may just have the answer.