Fri Oct 06, 2023 9:30 pm
OK. So the idea is based on the fact that the connection tracking itself (not the firewall as a whole) only takes into account the IP part of the packets (addresses, protocol, and ports) - it doesn't care about in/out interface or MAC addresses. Also, to reset the timeout of the connection, it is enough that a packet belonging to that connection passes in either direction.
So if we can generate UDP packets with exactly the same source and destination addresses and ports like those sent by the phone to the VoWiFi gateway, these will be enough to update the pinhole on the Mikrotik itself and on eventual other routers between the Mikrotik and the internet.
We cannot assign the address of the phone to the Mikrotik itself as it would prevent Mikrotik from ever sending anything to the phone, but we can use src-nat to replace the own address of the Mikrotik by the one of the phone. As src-nat is executed as one of the last actions on an outgoing packet, and as we need this translation to be handled by another tracked connection than the VoWiFi pinhole, we need to push the packet through the packet stack twice; to do that, we use a hairpin tunnel.
So you set up and empty bridge interface (with no ports), like br-local, and attach to it two own adresses of the Mikrotik, such as 127.0.0.1/32 and 127.0.0.2/32. Then you create two ipip tunnels - ipip1 with local-address=127.0.0.1 and remote-address=127.0.0.2, and ipip2 with these addresses swapped. So whatever you send via ipip1 will come back as a new packet via ipip2 and vice versa. To route our keepalive packets via ipip1, add a default route with gateway=ipip1 and routing-mark=via-hairpin.
Now we have to send the packets. The lowest packet rate you can achieve with tool traffic-generator seems to be 1 pps which would be way too much, so you need a scheduled script that will be starting and stopping the traffic generator once a minute or so, or you have to use resolve or tool traceroute to send the packets to the required destination. /tool traceroute seems to be the best choice to me as you can easily control their the TTL so the keepalive packets will only get as far as you need them to get to update all the keepalives but not to the VoWiFi gateway, so even if it happens to be picky, we won't make it angry. The destination will be the address and port of the VoWiFi gateway; as the Mikrotik itself will be sending them, you can use a mangle rule in chain output to assign them a routing-mark via-hairpin; the "real" packets from the phone do not pass through the output chain so they will not be affected.
The last step before actually starting to send the packets is to set up a src-nat rule setting both to-addresses and to-ports to those used by the phone, and acting on out-interface=ipip1.
If this proof of concept works, you can proceed to using the scheduled scripts also to search for the VoWiFi connections in the /ip firewall connection list and to dynamically update the src-nat rule so that you could spoof keepalive packets from multiple phones. As the connection tracking will treat a spoofed packet from the same local address and port as one belonging to an existing spoofed connection, you will need a unique address:port combination for each phone. As the phones do not always use port 4500 for VoWiFi (just checked mine uses 14500), you cannot use a single static rule. And to be sure that the connections will be unique, you will need to create as many local addresses as there will be phones.
