Community discussions

MikroTik App
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Cannot dial out wifi-call from mobile phone

Tue Dec 21, 2021 5:21 am

I am not able to dial out wifi-call from mobile phone with a layer 2 AP connect to RB4011 with details:
routerboard: yes
model: RB4011iGS+
revision: r2
serial-number: xxxxxxxxxxxxxx
firmware-type: al2
factory-firmware: 6.47.9
current-firmware: 7.1
upgrade-firmware: 7.1

Phone A connected to the wifi and dial a call out, Phone B with no wifi will ring and can pick up the call but without sound.
Even Phone B pick the call, Phone A still hear the dial tone just like no one pick the call.

Any help?
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Tue Jan 11, 2022 10:43 am

Any help?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Tue Jan 11, 2022 11:31 am

When talking about "wifi call", do you have in mind the "WiFi calling" or "VoWiFi" service (same thing, different marketing names) provided by the mobile operator, or some IP phone application where an app on the smartphone registers with some other account not related to the mobile operator?
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 2:46 am

My issue is just concerning the WiFi Call service provided by the mobile operator.
Any suggestion?
 
gotsprings
Forum Guru
Forum Guru
Posts: 2102
Joined: Mon May 14, 2012 9:30 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 6:50 am

My cellular service outside the house is "ok".
Inside the house it's like 1 bar.

So I have wifi calling turned on, in my phone. As soon as I get in range of my wifi my phone flips to wifi calling. I work from home most days and make about 40 calls per day. They all show as over wifi...

Getting to the point.
If I look at my phone and pull down from the top (Android) it shows "Verizon WiFi Calling".
I can confirm this connection by looking at my wan port and opening Torch.

I can see a connection to Verizon's Calling Gateway on port 4500.

When I am actually on the phone... I can see the packets between when they talk and when I talk.

So...
Look at torch and see if you can find a connection on 500 or 4500 on your BRIDGE coming from your phone. Then track that to the WAN port. Find the IP it connects too...

Then you can start trouble shooting.
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 9:53 am

I can see the connection of the IP for the port 4500, but how can I track to that to the WAN port?
And what is the next step to trouble shoot?
Please help.
Thanks a lot!!!!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 10:01 am

Then you can start trouble shooting.
And in particular - the symptoms you describe (outgoing call ringing at the called party but nothing happens when the called party accepts it), it seems as if the answer message (SIP 200 OK) did not make it to your router from the mobile operator's exchange, or the router has failed to forward it to the phone.

So open a command line window to the router, make it as wide as your screen allows, and run
/tool sniffer quick ip-address=ip.of.mobile.exchange port=4500

While there is no call, you should see some keepalive packets every 20 seconds or so. Leave it like that for, say, two minutes, then stop the sniffer (Ctrl-C), do /tool sniffer packet print, copy the output as text and post it here (if you have a public IP on WAN of the router, replace it systematically by my.pub.lic.ip or so before posting).

You should see each packet multiple times - in via wlanX, then in via bridge, then out via ether1 (WAN), and then the response in reverse order, if your RB4011 is more or less in the factory default configuration.

Once we get past this, we can debug the actual issue.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1275
Joined: Tue Jun 23, 2015 2:35 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 10:31 am

@sindy
why port 4500?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Jan 12, 2022 10:39 am

Because WiFi calling = VoWiFi establishes an IPsec tunnel from the phone to the operator's exchange, so that no one could wiretap the calls on the packet network. Apparently this turned out simpler than to deal with SIPS (SIP/TLS) and SRTP.
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 13, 2022 2:36 am

Then you can start trouble shooting.
And in particular - the symptoms you describe (outgoing call ringing at the called party but nothing happens when the called party accepts it), it seems as if the answer message (SIP 200 OK) did not make it to your router from the mobile operator's exchange, or the router has failed to forward it to the phone.

So open a command line window to the router, make it as wide as your screen allows, and run
/tool sniffer quick ip-address=ip.of.mobile.exchange port=4500

While there is no call, you should see some keepalive packets every 20 seconds or so. Leave it like that for, say, two minutes, then stop the sniffer (Ctrl-C), do /tool sniffer packet print, copy the output as text and post it here (if you have a public IP on WAN of the router, replace it systematically by my.pub.lic.ip or so before posting).

You should see each packet multiple times - in via wlanX, then in via bridge, then out via ether1 (WAN), and then the response in reverse order, if your RB4011 is more or less in the factory default configuration.

Once we get past this, we can debug the actual issue.
This is the result. I just fine tune to include the "via WAN traffic".

/tool/sniffer/packet/print
Columns: TIME, INTERFACE, SRC-ADDRESS, DST-ADDRESS, IP-PROTOCOL, SIZE, CPU
# TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
0 6.581 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
1 6.581 local 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
2 6.581 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 43 2
3 22.057 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
4 22.057 local 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
5 22.057 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 122 2
6 22.062 ether1 dest-pub-ip:4500 src-pub-ip:4500 udp 122 2
7 22.062 local dest-pub-ip:4500 192.168.1.8:4500 udp 122 2
8 22.062 ether10 dest-pub-ip:4500 192.168.1.8:4500 udp 122 2
9 22.098 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
10 22.098 local 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
11 22.098 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 43 2
12 40.301 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
13 40.301 local 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
14 40.301 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 122 2
15 40.304 ether1 dest-pub-ip:4500 src-pub-ip:4500 udp 122 2
16 40.304 local dest-pub-ip:4500 192.168.1.8:4500 udp 122 2
17 40.304 ether10 dest-pub-ip:4500 192.168.1.8:4500 udp 122 2
18 41.548 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
19 41.548 local 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
20 41.548 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 43 2
21 49.43 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
22 49.43 local 192.168.1.8:4500 dest-pub-ip:4500 udp 122 2
23 49.43 ether1 src-pub-ip:4500 dest-pub-ip:4500 udp 122 2
24 49.433 ether1 dest-pub-ip:4500 src-pub-ip:4500 udp 122 2
25 49.434 local dest-pub-ip:4500 192.168.1.8:4500 udp 122 2
26 49.434 ether10 dest-pub-ip:4500 192.168.1.8:4500 udp 122 2

Any idea?
Thanks a lot.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 13, 2022 9:27 am

OK. This shows that the phone has a local address of 192.168.1.8, is connected via a WiFi AP connected via ether10, ether10 is a member port of bridge local, and ether1 is a WAN.

So now you can run the sniffer again, not restricting it to a particular interface, try the outgoing call, and try to answer the call on the called phone. Since the traffic is encrypted, you cannot identify the SIP registration updates and call control messages and RTP media packets from one another and from the IPsec keepalive traffic by anything else but size. But all the SIP and RTP packets should be larger than the 122 bytes of the IPsec DPDs you can see in the "idle time" capture as above. Which means that when printing the captured packets, you'll use /tool/sniffer/packet/print where size>122 in order to get rid of the "background noise" and only see the SIP & RTP.

So the pattern we are looking for is the following:
  • as you press "call", there should be a single large message from the phone to the exchange (the INVITE), responded by a multiple smaller ones from the exchange (100 Trying, 180 Ringing, 183 Media Change - cannot say whether all of them will be there, but at least one should)
  • many same-size packets (RTP ones) should follow, carrying the alerting tone, unless the exchange asks the phone to generate the tone - both cases are possible
  • once you answer the called phone, one packet larger than the RTP ones should be seen from the exchange to the phone (200 OK), "responded" with another "larger-than-RTP" one from the phone (ACK). Following the 200 OK, the RTP should start flowing in both directions.
What we are looking for is whether the 200 OK arrives to ether1 (WAN) and whether the router delivers it all the way to ether10. That's basically all we can find - if it does, the only other wrongdoing of the router could be that it malforms the contents of the packet as delivering it; to find out, it would be necessary to sniff into a file, open the file using Wireshark, and compare the payload of the two packets - the Ethernet and IP headers will be different due to NAT and different MAC addresses.

If the router did nothing wrong, it must be the exchange, the phone, or the wireless AP.

What can interfere with the message exchange outlined above is the periodic SIP registration, which has its own timing, independent from the call establishing messages. So better to do the complete procedure (two separate sniffings) for two calls and compare the results. You can filter out also the RTP by size to have only the SIP packets printed, or you can sniff into files and open them using Wireshark for better filtering and graphing possibilities.

As you specifically mention outgoing calls, do I read it right that incoming calls work normally for this phone and this home network? What about outgoing calls in another wireless network?
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 14, 2022 2:55 am

OK. This shows that the phone has a local address of 192.168.1.8, is connected via a WiFi AP connected via ether10, ether10 is a member port of bridge local, and ether1 is a WAN.

So now you can run the sniffer again, not restricting it to a particular interface, try the outgoing call, and try to answer the call on the called phone. Since the traffic is encrypted, you cannot identify the SIP registration updates and call control messages and RTP media packets from one another and from the IPsec keepalive traffic by anything else but size. But all the SIP and RTP packets should be larger than the 122 bytes of the IPsec DPDs you can see in the "idle time" capture as above. Which means that when printing the captured packets, you'll use /tool/sniffer/packet/print where size>122 in order to get rid of the "background noise" and only see the SIP & RTP.

So the pattern we are looking for is the following:
  • as you press "call", there should be a single large message from the phone to the exchange (the INVITE), responded by a multiple smaller ones from the exchange (100 Trying, 180 Ringing, 183 Media Change - cannot say whether all of them will be there, but at least one should)
  • many same-size packets (RTP ones) should follow, carrying the alerting tone, unless the exchange asks the phone to generate the tone - both cases are possible
  • once you answer the called phone, one packet larger than the RTP ones should be seen from the exchange to the phone (200 OK), "responded" with another "larger-than-RTP" one from the phone (ACK). Following the 200 OK, the RTP should start flowing in both directions.
What we are looking for is whether the 200 OK arrives to ether1 (WAN) and whether the router delivers it all the way to ether10. That's basically all we can find - if it does, the only other wrongdoing of the router could be that it malforms the contents of the packet as delivering it; to find out, it would be necessary to sniff into a file, open the file using Wireshark, and compare the payload of the two packets - the Ethernet and IP headers will be different due to NAT and different MAC addresses.

If the router did nothing wrong, it must be the exchange, the phone, or the wireless AP.

What can interfere with the message exchange outlined above is the periodic SIP registration, which has its own timing, independent from the call establishing messages. So better to do the complete procedure (two separate sniffings) for two calls and compare the results. You can filter out also the RTP by size to have only the SIP packets printed, or you can sniff into files and open them using Wireshark for better filtering and graphing possibilities.

As you specifically mention outgoing calls, do I read it right that incoming calls work normally for this phone and this home network? What about outgoing calls in another wireless network?
Incoming calls work normally for this phone in this home network.
Incoming and outgoing calls work normally for this phone in other network.
Only outgoing calls work abnormally for this phone in this home network.

I will try the outgoing call again in these days and let you know the result.
Thanks a lot for your help!!!!!!
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 14, 2022 11:08 am

# TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
0 19.502 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
1 19.53 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
2 19.53 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
3 19.53 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
4 19.555 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
5 19.555 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
6 19.555 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
7 19.561 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
8 19.561 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
9 19.561 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
10 19.609 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
11 19.609 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
12 19.609 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
13 19.609 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
14 19.609 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
15 19.609 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
16 19.622 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
17 19.622 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
18 19.622 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
19 19.642 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
20 19.642 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
21 19.642 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
22 19.662 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
23 19.662 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
24 19.662 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
25 19.682 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
26 19.682 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
27 19.682 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
28 19.702 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
29 19.702 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
30 19.702 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
31 19.733 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
32 19.733 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
33 19.733 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
34 19.743 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
35 19.743 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
36 19.743 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
37 19.762 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
38 19.762 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
39 19.762 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
40 19.793 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
41 19.793 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
42 19.793 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
43 19.802 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
44 19.802 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
45 19.802 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
46 19.822 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
47 19.822 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
48 19.822 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
49 19.853 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
50 19.853 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
51 19.853 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
52 19.862 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
53 19.862 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
54 19.862 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
55 19.882 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
56 19.882 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
57 19.882 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
58 19.914 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
59 19.914 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
60 19.914 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
61 19.922 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
62 19.922 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
63 19.922 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
64 19.941 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
65 19.941 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
66 19.941 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
67 19.977 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
68 19.977 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
69 19.977 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
70 19.981 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
71 19.981 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
72 19.981 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
73 20.012 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
74 20.012 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
75 20.012 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
76 20.029 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
77 20.029 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
78 20.029 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
79 20.058 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
80 20.058 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
81 20.058 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
82 20.061 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
83 20.061 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
84 20.061 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
85 20.082 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
86 20.082 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
87 20.082 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
88 20.102 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
89 20.102 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
90 20.102 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
91 20.122 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
92 20.122 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
93 20.122 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
94 20.142 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
95 20.142 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
96 20.142 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
97 20.162 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 0
98 20.162 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
99 20.162 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
100 20.182 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
101 20.182 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
102 20.182 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
103 20.189 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 302 >
104 20.189 local dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
105 20.189 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
106 20.189 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 1514 >
107 20.189 local dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
108 20.189 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
109 20.202 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
110 20.202 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
111 20.202 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
112 20.222 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
113 20.222 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
114 20.222 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
115 20.242 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
116 20.242 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
117 20.242 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
118 20.282 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
119 20.282 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
120 20.282 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
121 20.282 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
122 20.282 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
123 20.282 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
124 20.302 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
125 20.302 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
126 20.302 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
127 20.322 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
128 20.322 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
129 20.322 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
130 20.343 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
131 20.343 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
132 20.343 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
133 20.361 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
134 20.361 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
135 20.361 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
136 20.382 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
137 20.382 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
138 20.382 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
139 20.403 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
140 20.403 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
141 20.403 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
142 20.422 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
143 20.422 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
144 20.422 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
145 20.442 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
146 20.442 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
147 20.442 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
148 20.469 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
149 20.469 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
150 20.469 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
151 20.482 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
152 20.482 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
153 20.482 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
154 20.524 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
155 20.524 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
156 20.524 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
157 20.561 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
158 20.561 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
159 20.561 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
160 20.722 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
161 20.722 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
162 20.722 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
163 20.882 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
164 20.882 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
165 20.882 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
166 21.048 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
167 21.048 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
168 21.048 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
169 21.181 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
170 21.181 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
171 21.181 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
172 21.212 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
173 21.212 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
174 21.212 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
175 21.221 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
176 21.221 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
177 21.221 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
178 21.272 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
179 21.272 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
180 21.272 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
181 21.282 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
182 21.282 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
183 21.282 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
184 21.341 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
185 21.341 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
186 21.341 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
187 21.362 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
188 21.362 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
189 21.362 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
190 21.392 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
191 21.392 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
192 21.392 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
193 21.402 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
194 21.402 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
195 21.402 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
196 21.421 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
197 21.421 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
198 21.421 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
199 21.451 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
200 21.451 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
201 21.451 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
202 21.462 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
203 21.462 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
204 21.462 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
205 21.481 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
206 21.481 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
207 21.481 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
208 21.511 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
209 21.511 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
210 21.511 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
211 21.525 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
212 21.525 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
213 21.525 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
214 21.551 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
215 21.551 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
216 21.551 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
217 21.612 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 158 >
218 21.612 local dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
219 21.612 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 158 >
220 21.621 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
221 21.621 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
222 21.621 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
223 21.643 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
224 21.643 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
225 21.643 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
226 21.682 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
227 21.682 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
228 21.682 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
229 21.682 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
230 21.682 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
231 21.682 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
232 21.702 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
233 21.702 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
234 21.702 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
235 21.722 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
236 21.722 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
237 21.722 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
238 21.748 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
239 21.748 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
240 21.748 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
241 21.762 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
242 21.762 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
243 21.762 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
244 21.782 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
245 21.782 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
246 21.782 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
247 21.809 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
248 21.809 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
249 21.809 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
250 21.821 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
251 21.821 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
252 21.821 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
253 21.841 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
254 21.841 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
255 21.841 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
256 21.869 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
257 21.869 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
258 21.869 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
259 21.882 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
260 21.882 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
261 21.882 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
262 21.902 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
263 21.902 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
264 21.902 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
265 21.929 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
266 21.929 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
267 21.929 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
268 21.942 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
269 21.942 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
270 21.942 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
271 21.963 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
272 21.963 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
273 21.963 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
274 21.989 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
275 21.989 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
276 21.989 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
277 22.019 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
278 22.019 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
279 22.019 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
280 22.022 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
281 22.022 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
282 22.022 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
283 22.052 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
284 22.052 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
285 22.052 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
286 22.059 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
287 22.059 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
288 22.059 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
289 22.079 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
290 22.079 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
291 22.079 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
292 22.111 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
293 22.111 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
294 22.111 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
295 22.119 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
296 22.119 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
297 22.119 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
298 22.14 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
299 22.14 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
300 22.14 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
301 22.171 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
302 22.171 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
303 22.171 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
304 22.18 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
305 22.18 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
306 22.181 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
307 22.203 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
308 22.203 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
309 22.203 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
310 22.23 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
311 22.23 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
312 22.23 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
313 22.242 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
314 22.242 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
315 22.242 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
316 22.262 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
317 22.262 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
318 22.262 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
319 22.289 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
320 22.289 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
321 22.289 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
322 22.302 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
323 22.302 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
324 22.302 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
325 22.322 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
326 22.322 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
327 22.322 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
328 22.348 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
329 22.348 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
330 22.348 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
331 22.36 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
332 22.36 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
333 22.36 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
334 22.382 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
335 22.382 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
336 22.383 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
337 22.411 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
338 22.411 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
339 22.411 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
340 22.421 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
341 22.421 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
342 22.421 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
343 22.441 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
344 22.441 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
345 22.441 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
346 22.466 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
347 22.466 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
348 22.466 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
349 22.479 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
350 22.479 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
351 22.479 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
352 22.501 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
353 22.501 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
354 22.501 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
355 22.52 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
356 22.52 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
357 22.52 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
358 22.557 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
359 22.557 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
360 22.557 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
361 22.561 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
362 22.561 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
363 22.561 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
364 22.58 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
365 22.58 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
366 22.58 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
367 22.599 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
368 22.599 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
369 22.599 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
370 22.621 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
371 22.621 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
372 22.621 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
373 22.639 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
374 22.639 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
375 22.639 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
376 22.66 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
377 22.66 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
378 22.66 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
379 22.682 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
380 22.682 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
381 22.682 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
382 22.738 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
383 22.738 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
384 22.738 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
385 22.738 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
386 22.738 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
387 22.738 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
388 22.742 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
389 22.742 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
390 22.742 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
391 22.761 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
392 22.761 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
393 22.761 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
394 22.802 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
395 22.802 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
396 22.802 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
397 22.802 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
398 22.802 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
399 22.802 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
400 22.822 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
401 22.822 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
402 22.822 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
403 22.862 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
404 22.862 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
405 22.862 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
406 22.863 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
407 22.863 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
408 22.863 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
409 22.884 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
410 22.884 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
411 22.884 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
412 22.901 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
413 22.901 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
414 22.901 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
415 22.923 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
416 22.923 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
417 22.923 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
418 22.953 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
419 22.953 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
420 22.953 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
421 22.961 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
422 22.961 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
423 22.961 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
424 22.982 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
425 22.982 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
426 22.982 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
427 23.013 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
428 23.013 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
429 23.013 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
430 23.035 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
431 23.035 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
432 23.035 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
433 23.041 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
434 23.041 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
435 23.041 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
436 23.061 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
437 23.061 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
438 23.061 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
439 23.085 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
440 23.085 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
441 23.085 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
442 23.118 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
443 23.118 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
444 23.118 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
445 23.119 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 174 >
446 23.119 local dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
447 23.119 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 >
448 24.191 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 302 >
449 24.191 local dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
450 24.191 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
451 24.191 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 1514 >
452 24.191 local dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
453 24.191 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
454 28.191 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 302 >
455 28.191 local dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
456 28.191 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
457 28.191 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 1514 >
458 28.191 local dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
459 28.191 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
460 28.826 ether10 192.168.1.8:4500 dst-pub-ip:4500 udp 60 >
461 28.826 local 192.168.1.8:4500 dst-pub-ip:4500 udp 60 >
462 28.826 ether1 src-pub-ip:4500 dst-pub-ip:4500 udp 43 >
463 31.747 ether10 192.168.1.8:4500 dst-pub-ip:4500 udp 990 >
464 31.747 local 192.168.1.8:4500 dst-pub-ip:4500 udp 990 >
465 31.747 ether1 src-pub-ip:4500 dst-pub-ip:4500 udp 990 >
466 31.753 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 654 >
467 31.753 local dst-pub-ip:4500 192.168.1.8:4500 udp 654 >
468 31.753 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 654 >
469 32.197 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 302 >
470 32.197 local dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
471 32.197 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 302 >
472 32.197 ether1 dst-pub-ip:4500 src-pub-ip:4500 udp 1514 >
473 32.197 local dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >
474 32.197 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 1582 >

This is a outgoing call capture, any ideas?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone  [SOLVED]

Fri Jan 14, 2022 12:16 pm

Yes. What happens is that the exchange sends a packet so large that it exceeds the L2 MTU of the AP or the phone, or the L3 MTU of the phone, and the L3 MTU configuration on bridge local is too optimistic so the router sends that packet to the phone without fragmentation.

You can see that e.g. frame #106 in the list has 1514 bytes on ether1; the subsequent frame on interfaces local (the bridge) and ether10 (the port of the bridge to which the AP is connected) has 1582 bytes. It is not "inflated" by your router - what actually happens is that you sniff with port=4500 as requested, and because port numbers are not present in fragments, the frame carrying the 2nd fragment of that packet whose 1st fragment has arrived in frame #106 has not been captured into the sniff. But since the packet is routed between ether1 and local, the router reassembles it from the two fragments first.

/interface bridge set local mtu=1500 should resolve the issue. There is a negligible chance that it will break something else, so just for the case, remember that change if you eventually start encountering some problems with other devices.
 
gotsprings
Forum Guru
Forum Guru
Posts: 2102
Joined: Mon May 14, 2012 9:30 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 14, 2022 2:00 pm

Sindy,

Thanks for taking the lead on this and digging in.
 
wkamlun
just joined
Topic Author
Posts: 8
Joined: Fri Dec 10, 2021 4:43 am

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 11:01 am

Sindy, thanks a lot.
I just solve it by setting the MTU on eth10 to 1500.
It’s now all working!!!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 11:43 am

You're welcome. So the only thing left is to mark my previous post as the solution for others searching for a solution of same or similar problem.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 4:12 pm

7.1.1 firmware seems solved problems with VoWIFI I experienced. I updated yesterday and still testing it, but for these two days it works well.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 5:10 pm

Could it be that the issues you've encountered before the upgrade were actually configuration problems similar to the one discussed in this topic, and that the default settings of 7.1.1 are just "safer" from this perspective? The thing is that from the point of view of the router, VoWiFi is yet another UDP flow initiated by a LAN client to be forwarded and src-nated.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 6:01 pm

I wonder why the effective MTU is above 1500 for these users.
Have they set high MTU value themselves (e.g. after a tutorial how to have jumbo frames on the LAN) or is there a situation where no interface has an actual MTU setting and the result is that the bridge has the L2 MTU as effectve MTU?
I checked in my router config and it has explicit MTU 1500 set on the bridge. But it could well be that I set that myself at some time.

It also is "interesting" that RouterOS performs reassembly for the received packets, and that this even works across IP packets that form a single UDP packet.
Usually, re-assembly in routers is only done at the IP level, not at the UDP level. Maybe this happens only on IPsec tunnels?
It seems a bit superfluous, and as shown in this example it could even be dangerous.
EDIT: I realize now that "fragmentation at UDP level" in fact is just fragmentation at IP level, i.e. IP datagrams larger than the MTU are send and then fragmented, there is no difference between the further fragmentation of packets due to limited MTU and this first fragmentation due to large UDP datagram size...

Finally, it is strange that the VoWIFI service sends UDP packets that are too large to fit in a 1500 byte ethernet packet. Usually those packets are much smaller, to reduce latency.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 7:07 pm

I checked in my router config and it has explicit MTU 1500 set on the bridge. But it could well be that I set that myself at some time.
On a bridge, the default mtu setting is auto (these days, and makes sense in general); on Ethernet ports, it seems to be set to 1500 in the default configuration, so it seems the OP has changed it manually.

It also is "interesting" that RouterOS performs reassembly for the received packets, and that this even works across IP packets that form a single UDP packet.
Usually, re-assembly in routers is only done at the IP level, not at the UDP level. Maybe this happens only on IPsec tunnels?
It seems a bit superfluous, and as shown in this example it could even be dangerous.
I'm afraid that reassembly and eventual re-fragmentation is inevitable where connection tracking is used, i.e. any NAT handling means reassembly, otherwise the router would not know where to forward the second and later fragments that do not contain port numbers. And as the router just forwards the IPsec packets, it doesn't care about them being IPsec ones.

Finally, it is strange that the VoWIFI service sends UDP packets that are too large to fit in a 1500 byte ethernet packet. Usually those packets are much smaller, to reduce latency.
The packets that need to be small to limit latency are those carrying the media (audio), i.e. RTP. What was not passing through was the packet informing the calling party that the call has been answered and which codecs out of the offered ones have been accepted by the called party. What I suspect (I didn't read the recommendations) is that VoLTE/VoWiFi may be using SIP over TCP, and that several SIP messages may get piggybacked into a single TCP packet, explaining its size to make use of the MTU. Or maybe the codec list was huge in the INVITE (which is missing in the capture), so the codec list in the response is proportionally huge in the 200 that has exceeded the phone's MTU even if it is sent in UDP - when a payload packet is encapsulated into an IPsec transport one, the additional headers and authenticity/replay protection bits are added, and only the resulting packet is fragmented depending on the MTU of the outgoing interface.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 7:40 pm

It also is "interesting" that RouterOS performs reassembly for the received packets, and that this even works across IP packets that form a single UDP packet.
Usually, re-assembly in routers is only done at the IP level, not at the UDP level. Maybe this happens only on IPsec tunnels?
It seems a bit superfluous, and as shown in this example it could even be dangerous.
I'm afraid that reassembly and eventual re-fragmentation is inevitable where connection tracking is used, i.e. any NAT handling means reassembly, otherwise the router would not know where to forward the second and later fragments that do not contain port numbers. And as the router just forwards the IPsec packets, it doesn't care about them being IPsec ones.
Actually that isn't the case. The IP fragments all contain the same ID number and subsequent fragments could be forwarded to the same place as the first fragment with the same ID.
Of course it is tricky because a subsequent fragment may arrive at the router BEFORE the first fragment (when packets are re-ordered upstream).
Probably the decision was made that when packets are to be queued anyway, they can be re-assembled without much more effort.
And in the general case where fragmentation only happens because of lower-than-normal downstream MTU, that is probably more efficient as well.
However, I question whether it is a good idea to re-assemble IP packets beyond the default 1500 byte MTU and then attempt to forward them. It is quite likely to create the problems encountered in this topic.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 7:56 pm

The wrong order of fragments causes the same complication with or without reassembly, you have to remember the non-1st fragments until you receive the first one to be able to proceed. So yes, I agree with you that the reassembly before forwarding is a design choice rather than being objectively "inevitable", but forwarding across NAT by IP ID would require much more of a dedicated code than reassembly before forwarding, as for the reassembly way, all the building blocks are available. We'd have to talk to the netfilter team to get the real reasons of the choice.

And here, the refragmentation was not the reason why it didn't work - the actual cause was the MTU setting incompatible with the receiving device's capability.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 8:06 pm

And here, the refragmentation was not the reason why it didn't work - the actual cause was the MTU setting incompatible with the receiving device's capability.
Well of course that always is the case, but I could understand when someone thinks "well, I can try to make jumboframes work on my network, let's set all local ethernet MTU to 9000 and the internet facing MTU to 1500. that should work because traffic between local hosts can pass at 9000 byte MTU and traffic to internet will be fragmented. Traffic from internet will be limited to 1500 by the internet interface. TCP traffic to internal systems will work because of the MSS parameter".
Then, when they have a device what has 1500 byte MTU it will only fail in this very special case.
Maybe it should be possible to specify a reassembly-MTU separately.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11433
Joined: Thu Mar 03, 2016 10:23 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 10:35 pm

Then, when they have a device what has 1500 byte MTU it will only fail in this very special case.
Maybe it should be possible to specify a reassembly-MTU separately.

Why doing something, that is nowdays so little needed, fool-proof?

The defaults are usually very sensible, if somebody wants to deviate then he should understand what he's doing. And if it breaks, it's him who keeps the pieces.
As far as my understanding goes, MTU has to be set to exactly the same value on all devices inside same subnet (and should be set lower than minimum supported calue by all involved hardware), otherwise things are bound to break sooner or later. Hence I don't see any reason to specify any special-case MTUs.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 10:42 pm

Well, it is only needed because of the configuration structure. Maybe not: it could be that it works perfectly OK when the MTU of the ethernet ports is set to 9000 and the MTU of the bridge is set to 1500. Maybe that allows bridging of traffic between ports at 9000 byte MTU and into the bridge (from the CPU) at 1500 bytes MTU.
I have no equipment (and no desire) to test it here. But some people seem to be obsessed by those jumbo frames... I think they are only realistically usable on a closed network like a SAN.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11433
Joined: Thu Mar 03, 2016 10:23 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 17, 2022 10:55 pm

I don't think the problem with MTUs is on mikrotik ... I'd say it's on wireless device, where MTU (and MRU which generally matches MTU) is left at default and can not accomodate for packets (or fragments) larger than that. And that's the problem with setting MTU different than default: if one doesn't control (and configure) every single device that will ever join subnet in question, then there will be problems. Period.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 21, 2022 2:37 pm

7.1.1 firmware seems solved problems with VoWIFI I experienced. I updated yesterday and still testing it, but for these two days it works well.
Unfortunately, I was too optimistic. On the third day it stops working. The situation as was before: on port 4500 (UDP) there is only one-way traffic, because firewall cannot establish bidirectional connection. Sometimes (rare) it can, mostly cannot, so traffic is not routed back to the source. I think, it's related to NAT and firewall implementation. I cannot test it on 6.x branch, unfortunately.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 21, 2022 4:54 pm

A stupid question - the phone keeps sending its IPsec traffic to port 4500 of the IP address of the mobile exchange. Assuming you haven't intentionally told the src-nat/masquerade rule to use only a single specific port at your WAN IP address for this connection, if you run /tool/sniffer/quick ip-address=ip.of.the.exchange port=4500, can you see the phone->exchange packets also at the WAN interface or only at the LAN one? If at both, can you see the responses from the exchange to arrive to the WAN interface?
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 1:37 am

A stupid question - the phone keeps sending its IPsec traffic to port 4500 of the IP address of the mobile exchange. Assuming you haven't intentionally told the src-nat/masquerade rule to use only a single specific port at your WAN IP address for this connection, if you run /tool/sniffer/quick ip-address=ip.of.the.exchange port=4500, can you see the phone->exchange packets also at the WAN interface or only at the LAN one? If at both, can you see the responses from the exchange to arrive to the WAN interface?
As far as I remember I saw packets in both directions. When I reported this issue to MikroTik support, I mentioned I have two separate connections in firewall instead one "linked". The root of this issue is still unknown to me. I continue experimenting, but every try takes days. I.e. right now it is working, after changing router config and phone reboot (it stops connecting to Wi-Fi, LOL, maybe iOS 15 bug? RouterOS 7.x bug? I don't know :), and I'll see what happens in few more days of coming in and coming out.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 11:23 am

When you have an unstable link and reconnections it could happen that the router creates a second NAT entry with a different (translated) portnumber other than 4500.
When you or the other side have a firewall that is too strict and allows only port 4500, that could mean trouble.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 11:54 am

@pe1chl, many households use the same phone vendor and mobile operator for several family members, meaning that it's nothing unusual that multiple VoWiFi sessions from distinct subscribers arrive from the same IP address. So accepting only requests coming from port 4500 at the exchange side would cause a lot of failed VoWiFi sessions.

@memelchenkov, I have repeatedly seen two unidirectional tracked connections for GRE (and to make it even more weird, only on some CPU architectures and only if that GRE was carrying EoIP with its misuse of the ID field), but there was no NAT involved. I can hardly imagine how a forwarded UDP connection on a NATing router could create two independent unidirectional connections, unless there was a dst-nat rule forwarding port 4500 from the public IP of the router (or some other UDP port that would match the one chosen by src-nat for a previous connection). So I'd be really interested in seeing the sniff result, the /ip/firewall/connection print detail where src-address~":4500" or dst-address~":4500", and the configuration of /ip/firewall/nat when you encounter such situation again.

Unfortunately, I cannot test the same in my home lab, because the only iPhone here prefers VoLTE and even GSM to VoWiFi and there is no spot with bad enough mobile coverage in the house, and the Android phones don't even attempt to establish VoWiFi connections although VoLTE is working on them and VoWiFi is enabled and preferred.
 
gotsprings
Forum Guru
Forum Guru
Posts: 2102
Joined: Mon May 14, 2012 9:30 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 12:27 pm

Sindy,

I have a pixel phone.

If I wanna test wifi calling...
I set my phone to airplane mode turn back on wifi.

Wifi calling engages instantly.

That doesn't work on any of your devices?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 12:36 pm

Tried that 10 minutes ago, nope. The phone is not of one of major brands, and it required some non-standard moves to make the network start fully support VoLTE on it, so maybe yet more such steps are required to make VoWiFi work.

But yes, on the iPhone it was possible to manually choose another operator to force VoWiFi on. This doesn't work on this Android - if you manually choose a network that rejects you, the phone switches over to auto again.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 1:15 pm

I am monitoring a new situation on our company network where I see the firewall rule that catches packets with wrong source address trigger a lot.
It appears that in normal 4G operation the phone uses a IPSEC ESP link to the provider over IPv6, and when the phone joins our WiFi network it continues to send that traffic over our WiFi network, with the IPv6 source and destination addresses of the provider (T-Mobile).
The firewall log looks like this: src-mac a0:d7:22:5c:81:32, proto 50, 2a02:498:1fea:b228:2:2:6788:faf1->2a02:498:0:3207::2, prio 5->0, len 64

When these phones use VoWifi on our network it always uses only IPv4, never IPv6. So I think it is VoLTE traffic that I see there.
I still have to research if that IPv6 address is from the actual 4G internet or if it is a hidden network only used for VoLTE.
Users report dropped calls so I need to find how this really works... the previous time I checked a work phone it did not have IPv6 on 4G internet, but maybe this has changed.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 2:42 pm

I still have to research if that IPv6 address is from the actual 4G internet or if it is a hidden network only used for VoLTE.
Why is this important? The phone uses a distinct APN for ims than for "other data", which implies two distinct addresses to be assigned, but the fact that the phone keeps using that address when sending packets via WiFi has the same effect - even if you let those packets through, the responses won't reach the phone unless the mobile network is still reachable.

So theoretically, letting the phone->exchange packet through might let the network finish an ongoing call in this heterogeneous mode?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Sat Jan 22, 2022 4:27 pm

I presume the 4G connection is still present. The phone connects to the WiFi because it sees a known network. It gets IPv4 and IPv6 address from there.
But apparently it lacks the policy routing to know that it should still route its voice data over the 4G network until it has established a new tunnel over the WiFi (which it will only do in IPv4) and then presumably some handover has to take place between the two.
Before, the outgoing traffic would be blocked and the call would disconnect. Friday I added an exeception rule for the T-Mobile /29 and now the packets are passed, but monday I will test if that actually works (I'm not sure if there is BCP38 on our internet connection...) or if the call still disconnects.
Of course the handling in the phone is completely wrong.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Mon Jan 24, 2022 2:34 pm

Further debugging shows that the leaked traffic is from the APN dedicated to 4G calling. The spoofed traffic via normal internet does not work, either the ISP or T-Mobile does not route it.
The IPv6 address definately is not from the 4G internet connection as T-Mobile does not support IPv6 on their internet (they are quite backward, their webcare says there are no plans to do so).
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Tue Jan 25, 2022 4:55 pm

I can hardly imagine how a forwarded UDP connection on a NATing router could create two independent unidirectional connections, unless...
Yes, it's a very unusual situation. Sorry for not sharing details publicly, but I created one more ticket with support, #[SUP-72355], especially related to this situation. It's 100% reproducible now. Last time they replied me they did not see anything unusual and they do not know why these connections are separate. Personally I think that it's a bug in firewall. I would like to be wrong, then it could be easily corrected. I better wait for response from a tech support, than guessing.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Tue Jan 25, 2022 8:08 pm

When you had double entries, was one of them with an untranslated port number 4500 and the other one with a different reply port number?
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 12:39 pm

When you had double entries, was one of them with an untranslated port number 4500 and the other one with a different reply port number?
Look:
* IP ends with .77 is cellular provider's IP.
* IP ends with .61 is my external IP.
* IP 10.0.0.24 is cellphone's IP.

Image
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 1:23 pm

So connection #4 should have been src-nated (unless there is an issue in chain srcnat of nat, which is unlikely as it works for some time after reboot) but it is not, and connection #3 should not have been even accepted unless connections to UDP port 4500 are permitted in chain input of filter.

I.e. it looks as if the original single src-nated connection goes missing at some point, subsequent packets of the ongoing IPsec session from phone side create a new one but without src-nat so they either don't get anywhere or at least the responses to them cannot reach your home, and subsequent packets of the ongoing IPsec connection coming from exchange side create a new connection but, not surprisingly, do not get any response from the router's own IPsec stack.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 2:22 pm

Of course it is always important that some keepalive is used, either on IPsec level or on SIP level. But with a 5 minute timeout on the NAT rule I would not expect that to be a factor.
(I think most applications that keep a UDP "connection" live over NAT realize that 3 minutes is a common timeout for such rules)
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 2:24 pm

So connection #4 should have been src-nated (unless there is an issue in chain srcnat of nat, which is unlikely as it works for some time after reboot) but it is not, and connection #3 should not have been even accepted unless connections to UDP port 4500 are permitted in chain input of filter.
Incoming UDP 4500 permitted in input chain, as I have IKEv2 server enabled. I also tried to disable it and test, and the result was unsatisfactory. I have no idea what to do with this situation.
It's something related to re-establishing a connection. When I turn off Wi-Fi on the phone, then turn on again, the phone re-establish IPSEC (VoWiFi) connection, but it leads to this situation. Even if I delete both connections from firewall Connections tab, and then connect the phone again, the situation is the same.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 2:39 pm

And there is no restriction of allowed to-ports in the src-nat/masquerade rule that normally creates the correct, bi-diectional & src-nated, connection?

In RouterOS 6, if a new connection to the same remote socket address cannot use any port at the WAN address, it is simply not created and the packet is dropped. Maybe the newer version of ipfilter in RouterOS 7 behaves differently in the same situation, but even if it is the case, the fact that you remove the "old & correct" connection before re-enabling WiFi on the phone and it nevertheless ends up like this suggests that removal of old connections fails somehow.

You have outlined it to support with all these scary details and they nevertheless say it works as expected? Афигеть...
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 7:13 pm

And there is no restriction of allowed to-ports in the src-nat/masquerade rule that normally creates the correct, bi-diectional & src-nated, connection?
Sure no. A default plain masquerade rule.
Maybe the newer version of ipfilter in RouterOS 7 behaves differently in the same situation, but…
I think, it's some kind of weird bugs they have in ROS7 firmware. There were bugs with bridge filtering, which they fixed (maybe not all, but most noticeable), but, obviously, there are a lot of not-so-common cases that will pollute their support tickets until some 7.x minor version. I'd love to use RouterOS 6 and that's all but Chateau device do not allow me to do it.
Афигеть...
:))
Exact phrase was "Unfortunately, we cannot spot any errors which can cause such behavior. " There was a combined ticket in which the bridge filter was also not working correctly, so perhaps they did not attach much importance to this bug. I mean, sometimes some bug unwinds a tangle of other errors. Now in the new ticket it is exclusive problem, with a most fresh ROS version than before, and now I will wait for a response from them.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 7:34 pm

Exact phrase was "Unfortunately, we cannot spot any errors which can cause such behavior."
OK, this sounds much different than "the behaviour is normal" as I understood it before.

I wonder whether it can be a hardware error, but currently I don't wonder enough to buy an Audience :)

But I've got another idea - would it be possible that if the WAN goes down for some reason, the packets towards the exchange take some other route than via the WAN gateway? That would explain why the new connection is not src-nated.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 7:51 pm

But I've got another idea - would it be possible that if the WAN goes down for some reason, the packets towards the exchange take some other route than via the WAN gateway? That would explain why the new connection is not src-nated.
No, it do not goest down. Indeed, I have interface list as masquerade destination, PPPoE + LTE. PPPoE is the main route, LTE is second. But: I tried to change it solely to PPPoE (as support recommended me to do)—the situation did not change. So no, not a routing issue, at least not on configuration level.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Thu Jan 27, 2022 8:38 pm

Still... if you shut down WiFi on the phone, wait for the existing weird connections to die off (3+ minutes), then run /tool sniffer quick ip-address=ip.of.the.exchange and switch on the WiFi on the phone, what does the sniffer output show?
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 28, 2022 2:56 pm

Still... if you shut down WiFi on the phone, wait for the existing weird connections to die off (3+ minutes), then run /tool sniffer quick ip-address=ip.of.the.exchange and switch on the WiFi on the phone, what does the sniffer output show?
Wi-Fi calling was turned off on the phone, at least one day without it (so not 5 minutes, but whole day). Now I turned on again, and what I see: src-address: LAN IP -> dst-address: MTS IP. And src-address: MTS IP -> dst-address: Provider IP. It do not establish NAT for reply packets.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 28, 2022 3:00 pm

what I see: src-address: LAN IP -> dst-address: MTS IP. And src-address: MTS IP -> dst-address: Provider IP.
On what interfaces? wlanX->bridge->pppoe?
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 28, 2022 3:14 pm

what I see: src-address: LAN IP -> dst-address: MTS IP. And src-address: MTS IP -> dst-address: Provider IP.
On what interfaces? wlanX->bridge->pppoe?
Here is the dump. 10.x - LAN, x.77 - MTS VoWiFi IP, x.61 - my provider.
[admin@Router] > /tool sniffer quick ip-address=x.77
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE     TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS         DST-ADDRESS         PROTOCOL  SIZE  CPU
wlan5         12.726   10  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
bridge        12.726   11  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
pppoeX        12.726   12  ->                                         10.x:4500           x.77:4500           ip:udp     112    3
wlan5         17.731   13  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
bridge        17.731   14  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
pppoeX        17.731   15  ->                                         10.x:4500           x.77:4500           ip:udp     112    3
wlan5         22.738   16  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
bridge        22.738   17  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp     126    3
pppoeX        22.738   18  ->                                         10.x:4500           x.77:4500           ip:udp     112    3
pppoeX        23.766   19  <-                                         x.77:4500           x.61:4500           ip:udp      29    3
wlan5         25.255   20  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp      43    3
bridge        25.255   21  <-   MA:C1:00:00:00:00  MA:C2:00:00:00:00  10.x:4500           x.77:4500           ip:udp      43    3
pppoeX        25.255   22  ->                                         10.x:4500           x.77:4500           ip:udp      29    3
pppoeX        28.039   23  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
pppoeX        29.055   24  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
pppoeX        30.1     25  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
pppoeX        31.126   26  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
pppoeX        32.176   27  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
pppoeX        33.201   28  <-                                         x.77:4500           x.61:4500           ip:udp     112    3
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 28, 2022 4:45 pm

So if the sniff was running before you've enabled VoWiFi on the phone, it means that already the initial phone->exchange packet has not triggered the NAT treatment, not just that the connection tracking doesn't remember the result. Assuming your WAN (pppoe) IP is a public one, what surprises me most is that the response from the exchange has found its way back to your device. What surprises me second most is that this weird behaviour only affects VoWiFi.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Fri Jan 28, 2022 5:07 pm

Waiting for resolution from MikroTik side.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 9:00 am

change udp and udp stream timeout to 10m.

drop connections from WAN that is not NAT'ed.

enable WMM and set priority 7 for udp/500 and udp/4500

works. wish there was VOWLAN helper just like SIP. to keep these connections alive.
Last edited by volkirik on Fri Feb 04, 2022 3:25 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 11:08 am

changing udp timeout (not udp stream) to 1h will likely cause you other problems...
there are lots of short-lived udp sessions for DNS lookups, and they would remain in the table for a long time so it will grow very large.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 3:27 pm

then please email mikrotik guys and request IPSEC alg. other vendors have it.

vowifi (VOWLAN) use IPSEC
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 3:47 pm

vowifi (VOWLAN) use IPSEC
Yes it does, but there is normally no need for a special treatment for IPsec traversing a NATing router. When IPsec detects NAT, it normally automatically sends keepalive packets every 20 seconds in order to keep the pinhole open even if no actual traffic is being sent, plus usually also Dead Peer Detection packets every minute, whereas the default UDP pinhole lifetime in RouterOS is 180s. So what @memelchenkov suffers from is some malfunction of the regular operation of the NAT, which is intermittent on top of that.

If neither your mobile phone nor your operator's ePDG send the keepalives, then indeed the workaround is to extend the timeout, but that's a bug of that particular phone and/or ePDG, and that workaround is not a panacea for all VoWiFi/WiFiCalling/WoWLAN related issues - as this topic shows, there are at least two other issues with a different root cause.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 4:11 pm

thats the problem. they dont have to enable keepalives

so we need ipsec helper (ALG) to keep conns alive
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 4:38 pm

No, they have to enable keepalives. Either at the IPsec level or at the SIP level.
Assuming UDP sessions remain alive without traffic just doesn't make sense.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 5:09 pm

I can respect your idea. but keepalive may be disabled or interval may be long, so that doesnt keep connection alive.

I had the same problem with my provider TURKCELL, inspected their traffic they never ever send keepalive, nor send ka responses. sorry.

prolly ip-firewall-drop rule or misconfiguration in their server. hope they read it here. set 2 seconds keepalive and respond client keepalive, idiots.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 5:40 pm

It is not possible to counter such stupity... it will never work reliably when there is no keepalive traffic.
Instead of requesting MikroTIk to fix it, ask the provider to fix it or switch to a better one.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 04, 2022 7:11 pm

@pe1chl, I hate it to be like that but in many cases, working around others' bugs is necessary, as the customer is more likely to ditch your own product (a Mikrotik router in this case) than the one which is actually wrong (the phone or the operator, hard to say which one is guilty in @volkirik's case - it seems to be the phone but maybe the operator instructs the phone not to send the keepalives).

Having said that, @volkirik, for a home environment, a safer workaround than extending the UDP timeout in connection tracking should be to make the DHCP leases for all the phones static and to create static srcnat and dstnat rules for each of them vs. the addresses of the ePDGs. So no matter from which side the transport packet comes after the UDP connection has timed out, the same mapping between the WAN UDP port and the private address of the phone will be recreated. In an environment where phones come and go, this cannot be used of course. I assume you do have a public WAN IP, as otherwise the extension of the pinhole timeout on the Mikrotik alone would change nothing.

I assume you don't assign public IPs to your phones, do you?

I have just tried to trick the SIP helper into acting as an IPsec helper (as you can set the pinhole lifetime for the SIP helper), but no joy as expected, it seems to look into the packet payload and if it is not SIP, it ignores it.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Sun Feb 06, 2022 3:28 pm

/ip firewall connection tracking
set icmp-timeout=30s udp-stream-timeout=6m udp-timeout=30s loose-tcp-tracking=no

/ip settings
set arp-timeout=20m

/ip firewall service-port
set sip disabled=no ports=5060,5061,500,4500,3478,45395,50318,59234 sip-direct-media=no sip-timeout=1h

/ip firewall mangle
add action=set-priority chain=prerouting comment="sip=p7" connection-type=sip new-priority=7 passthrough=yes

/interface wireless
set [ find ] ampdu-priorities=0,1,2,3,4,5,6,7 disconnect-timeout=15s frame-lifetime=150 hw-retries=15 wmm-support=enabled
Last edited by volkirik on Tue Feb 08, 2022 7:29 pm, edited 2 times in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Sun Feb 06, 2022 3:34 pm

Yes, I can see now it actually does work... I was expecting the connection to change the timeout on the fly as I've added the 4500 to the list, but the "SIP mode" for UDP is actually only set when the connection is created, quite logical. So it is a way after all, but only if there is no further NAT between the router and the ePDG, as it just prevents the local pinhole from expiring, it does not refresh the pinhole on that other NAT.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot dial out wifi-call from mobile phone

Sun Feb 06, 2022 3:39 pm

it refresh conntrack timeout each and everytime traffic flows
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Sun Feb 06, 2022 3:43 pm

Sorry, too brief, I did not get what you actually wanted to say by that.

I have added port 4500 to the /ip firewall service-port list for sip yesterday, and all IPsec connections kept showing at 3m timeout max., across multiple refreshes. Today, the one that fell and re-established in the meantime shows max. 1h (I've kept the timeout for sip at 1h, not at 1d, as I don't need the workaround and I was just testing it). Those that have not re-established keep showing max. 3m even today.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Tue Feb 08, 2022 11:43 am

Overall information from this forum shows that there are different issues with VoWiFi, and one of them is lack (or blocking) of keep-alive packets. But, it is not the single possible issue (i.e. it's not related to my case). Second issue is NAT problems, like in my case, as stated by tech. support. I cannot say if it is exclusively related to VoWiFi, or related to bug in firmware, or a problem on ISP side. Tech. support can't help resolve this case (yet). I hope, they will do, sooner or later. However, probably I end this story by changing my ISP. Currently its Virgin Connect, it's a brand which came to my area and acquired several good providers, and now very slowly going bankruptcy (legal cases already opened). Thinking about it, I imagine Richard Branson as a stewardess with painted lips, and for some reason it seems to me that he succeeded in this role better than the role of brand manager. I'm sorry, I could not restrain myself from expressing this in the context of my situation.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10194
Joined: Mon Jun 08, 2015 12:09 pm

Re: Cannot dial out wifi-call from mobile phone

Tue Feb 08, 2022 2:25 pm

I have studied the connections in our company router for a while (inconvenient that you cannot filter connections on destination port number in winbox...) where we have hundreds of phones connected.
What I observe is that the typical VoWIFI VPN (e.g. to our provider T-Mobile) sends a packet every 30 seconds when idle. That is what I consider reasonable behavior when relying on an open connection over NAT.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 11:19 am

The support still did not solve the issue. The reply was still the same as before: check routing (it's OK), make sure your provider's NAT is OK. They checked router config, config is also well. When sending follow-up, no reply back. I just found they did not fix Bridge IP Firewall, however they told me they fix it a long time ago (in one of my past bugreports). If disable Bridge IP Firewall everything starts working. So, bridge IP firewall breaks NAT on router, absolutely not funny :((. I'd love to disable but I cannot, I use it to segment traffic. I could replace it with Bridge Filter packet marks, but they do not work as well. v7 is still a very problematic firmware, even in their "stable" branch.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 11:54 am

Just to double-check, when talking about Bridge IP Firewall, do you have in mind /interface bridge filter or indeed /interface bridge settings set use-ip-firewall=yes?

In the latter case, yes, that causes a lot of trouble with NAT because the L2 frames pass through the firewall already before routing, and as the NAT rules are only used for the initial packet of each tracked connection, the NAT decision is taken already before the packet reaches the routing stage, and the decision is "no NAT necessary" because when the L2 frame carrying the packet is being handled, the out-interface(-list) is not yet known so it doesn't match.

What I can imagine could help here would be to use action=notrack in raw/prerouting with match conditions allowing to distinguish the first pass (bridging from the physical interface to the bridge interface) from the second pass (routing from the bridge to the pppoe). The decision in raw is made for every single packet, so frames told to bypass the conntrack module during bridging will reach it anyway during routing, which is what we need here. Of course, this will only work if your "traffic segmentation" doesn't rely on connection tracking as well.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 12:05 pm

/interface bridge settings set use-ip-firewall=yes?
This.

I didn't think about this, thanks (and MikroTik support didn't think about this too). Sounds reasonable. However, I do not realize how to implement raw rule with both "In. Interface" and "Out. Interface" options, to exclude firewall processing between the interface and the bridge. There are only two chains: "prerouting" and "output"; "prerouting" allows only "In. Interface", and "output" only "Out. Interface".
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 12:10 pm

In fact you should not need the out-interface in raw to make it work. in-bridge-port-list matching to an interface list consisting of all ports of the bridge should alone be sufficient to do the trick.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 12:21 pm

There is no in-bridge-port-list option for RAW section.
However, I use this option in Mangle section, to connection-mark traffic coming from specific WLAN interfaces which destination is WAN.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 12:24 pm

Mangle would be too late, but I've realized in the meantime that in-bridge-port-list would act during the second pass as well, which is not what we want.

So in-interface=!bridge should do the job.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 12:31 pm

If you mean below rule, then this rule just blocks everything.
/ip firewall raw
add action=notrack chain=prerouting in-interface=!bridge
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 1:59 pm

If you mean below rule, then this rule just blocks everything.
/ip firewall raw
add action=notrack chain=prerouting in-interface=!bridge
Sure, the idea was that instead of positive matching on in-bridge-port(-list), you have to use negative matching on IP interface (in-interface=!bridge), because the positive one will match during both passes (bridging and routing) whereas the negative one will match only during bridging phase where in-interface is (hopefully) not the bridge yet, but you have to add some src-address(-list) condition to restrict the effect of the rule only to traffic initiated from your local LAN subnets. If that doesn't help, I cannot see any other way how to distinguish the routing phase from the bridging phase.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Wed Feb 16, 2022 3:24 pm

but you have to add some src-address(-list) condition to restrict the effect of the rule only to traffic initiated from your local LAN subnets. If that doesn't help, I cannot see any other way how to distinguish the routing phase from the bridging phase.
It seems it does not work that way. When adding src-address limited to LAN address space (or even just a single IP address), the counter of this rule is always zero.
If MikroTik fix packet marks in Bridge Filter then I'll be fine without Brdige IP Firewall. To be honest, I already gave up sending them various bug reports, it's hard to do (time-consumpting) and see little feedback.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Fri Feb 25, 2022 6:23 pm

NAT with Bridge IP Firewall bug is now fixed in 7.2rc4. Bridge Filters (packet-marks not working) are not fixed yet, but the support is already reproduced the problem and will fix it in future. For me, my situation is solved now (I hope :), because I use Bridge IP Firewall, not Bridge Filter for my needs, and it works now.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

Re: Cannot dial out wifi-call from mobile phone

Sun Feb 27, 2022 11:38 am

UPD: the situation reappears after two days. Bridge IP Firewall is not fixed. Do not use it at all, very buggy feature.

Who is online

Users browsing this forum: dredex, Fl3tch, Google [Bot], infabo, sebus46 and 41 guests