MikroTik

/ip firewall connection tracking
set icmp-timeout=1h udp-stream-timeout=1h

[admin@router] > /ip firewall connection print detail where protocol=icmp      
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, 
F - fasttrack, s - srcnat, d - dstnat 
 0  S C  s  protocol=icmp src-address=192.168.0.100 dst-address=199.87.121.233 
            reply-src-address=199.87.121.233 reply-dst-address=10.10.1.2 
            icmp-type=8 icmp-code=0 icmp-id=521 timeout=58m16s orig-packets=4 
            orig-bytes=336 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=3 repl-bytes=252 repl-fasttrack-packets=0 
            repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

[admin@router] > /ip firewall connection print detail where protocol=icmp      
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, 
F - fasttrack, s - srcnat, d - dstnat 
 0  S C  s  protocol=icmp src-address=192.168.0.100 dst-address=199.87.121.233 
            reply-src-address=199.87.121.233 reply-dst-address=10.10.1.2 
            icmp-type=8 icmp-code=0 icmp-id=521 timeout=49m38s orig-packets=4 
            orig-bytes=336 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=3 repl-bytes=252 repl-fasttrack-packets=0 
            repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 1  S C  s  protocol=icmp src-address=192.168.0.100 dst-address=199.87.121.233 
            reply-src-address=199.87.121.233 reply-dst-address=10.10.2.2 
            icmp-type=8 icmp-code=0 icmp-id=522 timeout=59m36s orig-packets=2 
            orig-bytes=168 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=2 repl-bytes=168 repl-fasttrack-packets=0 
            repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

[admin@router]> /ip firewall connection print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat
 0  SAC  s  protocol=tcp src-address=192.168.0.100:40000
            dst-address=172.127.30.14:443 reply-src-address=172.127.30.14:443
            reply-dst-address=10.10.1.2:40000 tcp-state=established
            timeout=23h59m51s orig-packets=3 orig-bytes=164
            orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=2
            repl-bytes=185 repl-fasttrack-packets=0 repl-fasttrack-bytes=0
            orig-rate=0bps repl-rate=0bps

[admin@router]> /ip firewall connection print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat
 0  SAC  s  protocol=tcp src-address=192.168.0.100:40000
            dst-address=172.127.30.14:443 reply-src-address=172.127.30.14:443
            reply-dst-address=10.10.1.2:40000 tcp-state=time-wait timeout=5s
            orig-packets=10 orig-bytes=536 orig-fasttrack-packets=0
            orig-fasttrack-bytes=0 repl-packets=8 repl-bytes=611
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps
            repl-rate=0bps

[admin@router]> /ip firewall connection print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat

[admin@router] /ip firewall connection> print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat
 0  SAC  s  protocol=tcp src-address=192.168.0.100:40000
            dst-address=172.127.30.14:443 reply-src-address=172.127.30.14:443
            reply-dst-address=10.10.1.2:40000 tcp-state=fin-wait timeout=2s
            orig-packets=12 orig-bytes=646 orig-fasttrack-packets=0
            orig-fasttrack-bytes=0 repl-packets=4 repl-bytes=315
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps
            repl-rate=0bps

root@sip-client:~# netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0     12 192.168.0.100:40000    172.127.30.14:443       FIN_WAIT1

[admin@router]> /ip firewall connection print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat

[admin@router] /ip firewall connection> print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat
 0  SAC  s  protocol=tcp src-address=192.168.0.100:40000
            dst-address=172.127.30.14:443 reply-src-address=172.127.30.14:443
            reply-dst-address=10.10.1.2:40000 tcp-state=fin-wait
            timeout=59m56s orig-packets=11 orig-bytes=580 
            orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=2 
            repl-bytes=185 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 
            orig-rate=0bps repl-rate=0bps  

[admin@router] /ip firewall connection> print detail where protocol=tcp
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying,
F - fasttrack, s - srcnat, d - dstnat
 0  SAC  s  protocol=tcp src-address=192.168.0.100:40000
            dst-address=172.127.30.14:443 reply-src-address=172.127.30.14:443
            reply-dst-address=10.10.2.2:40000 tcp-state=established
            timeout=23h59m55s orig-packets=3 orig-bytes=164 
            orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=2 
            repl-bytes=185 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 
            orig-rate=0bps repl-rate=0bps 

/ip firewall connection remove [find where connection-type=sip]

SIP can be carried by several transport layer protocols including the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Stream Control Transmission Protocol (SCTP).[13][14] SIP clients typically use TCP or UDP on port numbers 5060 or 5061 for SIP traffic to servers and other endpoints. Port 5060 is commonly used for non-encrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS).

Hi @sindy, thanks for your explanation. You are right: the SIP problem is not a SIP problem, but an UDP NAT problem (a more general problem). It isn't even a bug: it's a UDP NAT limitation (a protocol limitation).

I made some NAT tests and understood better how NAT works in MikroTik. I'm publishing my discoveries here.

@ZeroByte, this can help you.

Users with a single fixed IP on a single WAN line should not be affected by the above, so they do not need a fix.
The problem described above only occurs when there are multiple WAN lines and the router switches between them (e.g. due to some failover mechanism) without the client knowing about it.

Users with a single fixed IP on a single WAN line should not be affected by the above, so they do not need a fix.
The problem described above only occurs when there are multiple WAN lines and the router switches between them (e.g. due to some failover mechanism) without the client knowing about it.

I have a single fixed IP on a single WAN and I've suffered from this particular bug.

Where did I state I have one WANIP> I have two WANS and one voip modem on a single private IP behind the router which is static.

You do raise a good question. For my FIBER connection which is a dynamic IP address, how do I know for sure that when the iP changes the connection will still work as I am not manually at the router to see what gatewayIP is in use in case it needs to be changed for routing. ?????

[...] with masquerade, each time the interface goes down or its IP address changes, all tracked connections are cleared and newly established connections are src-nated to the new address (there is a video on that as well, explaining why to use masquerade only where really necessary).

By the way I have two srcnat rules and both use action=masquerade so it is no fix (yes sindy can be wrong, touch wood).

• the device itself uses STUN to determine how the NAT behaves and what is the public addres (which may not be a simple task, think about load balancing on WANs with different IP addresses) and puts that public address into the REGISTER message
• the NAT in the router uses an ALG, modifying the SIP message contents (the device puts its private address into the message and the ALG replaces it with the public IP of the WAN it uses to forward the message
• the exchange notices that the source socket address of the incoming REGISTER message differs from the one received inside the message and remembers both (so it sends messages to the source socket of the REGISTER and uses the address received inside the REGISTER inside the messages it sends)

NAT Traversal Considerations

If the device sits behind a NAT (typically the case), it can discover the mapped external address corresponding to its local SIP contact address as seen by the server in one of the following ways:

- From the “received=” and “rport=” parameters of the VIA header of the REGISTER response sent by the server; these two parameters tells the device its mapped IP address and port number respectively. This method is used if periodic registration is enabled on the device

- From the response to a STUN binding request the device sent to a STUN server. This method is used by enabling X_KeepAliveEnable and setting the X_KeepAliveMsgType parameter to “stun”. In that case, the STUN server is taken from the X_KeepAliveServer parameter, if it is specified. Otherwise, the keep-alive messages are sent to the same server where a REGISTER request would be sent to. The latter is the most effective way of using STUN to discover the mapped external contact address

The device always uses the mapped external contact address in all outbound SIP requests instead of its local contact address if one is discovered by either method discovered above.

If you can connect the phone directly to the Mikrotik's Ethernet port, you can use the script configured at the dhcp-client attached to the WAN interface to switch the port down and up again each time the address changes (or with each assignment regardless whether it differs from the previous one or not). So first try to do that manually to see whether the phone notices that and re-registers, and if it does, create the script.

There are two real world instances which I do not reguarly detect.

One if the ISP was actually unavailable (rare).
Two if the ISP changes my public WANIP (probably more often but I am not able to discern when this happens).
My concern in the latter case is that the gateway I HAD TO manually enter into my routing rules, so as long as the ISP doesnt change the gateway I think I am okay (and just changes the wanip).

I stumbled across an inoperative VOIP because of setting up the hex routers and playing with routing.
I could switch ISPs and the VOIP phone would not switch to the new ISP AT ALL. It seemed stuck, now I dont think I waited as long as an hour though.......
In this case it must be true that the SIP alg maybe had no effect because Im assuming the SIP alg would know which one of my WANs is the active primary in a (primary and failover setup).

All goes back to my ATA modem settings on page 99. What parameter or set of parameters would better handle an ISP changeover////

if it senses a change Netwtch can issue the following directive that forces the Obi to re-register:
/ip firewall connection remove where connection-type=sip or connection-type=sip2

if it senses a change Netwtch can issue the following directive that forces the Obi to re-register:
/ip firewall connection remove where connection-type=sip or connection-type=sip2

@moserd, how exactly does the above force the OBi (or any other SIP CPE) to re-register? What that script command definitely does is that it removes the existing "connection" in the firewall, so the next (re-)register creates a new connection whose src-nat address will be the one of the active WAN, but unless I miss something fundamental, it does not make the phone re-register immediately. So until the phone itself decides to renew the registration, it will be inaccessible for incoming calls and, depending on the VoIP provider, may also be unable to call out.

There is a scenario I have run into where stale connection-tracking entries prevent SIP phones from re-registering, which to this day I do not understand:

1. Customer has a single WAN / internet connection.
2. WAN uses PPPoE.
3. Customer is assigned a STATIC ADDRESS on the PPPoE interface.
4. PPPoE session bounces for whatever reason.
5. After PPPoE session comes back up WITH THE SAME IP ADDRESS, SIP phones cannot reregister until I clear out connection-tracking entires (or reboot).

One oddball thing that I HAVE seen, and which I have also seen others mention in other threads, is that typically when this problem is occurring, we will see the connection-tracking rule that is the culprit have its timeout value count down to 0 from the specified UDP Stream Timeout...AND THEN PROMPTLY STARTS COUNTING UP FROM ZERO. At that point the rule appears to be "stuck" and will never clear out of the table on its own. It has to be purged manually.

Re: Successful implementaion with Obi devices?
« Reply #1 on: May 29, 2017, 01:34:00 pm »
When I was testing there was a 32 second delay before failover occurred, so you might not be waiting long enough. This delay is controlled by TimerB and the default is 32 seconds. I set mine to 10 seconds. Don't set it too low because you will get false failovers. You can set NoRegNoCall to get instant failovers when the trunk isn't registered. TimerB will catch any non-register problems.

Voice Services -> SP1 Service -> X_NoRegNoCall: checked
Service Providers ITSP A -> SIP -> TimerB: 10000

Thanks. After I checked Voice Services -> SP1 Service -> X_NoRegNoCall, it works.

@NathanA,
your scenario really smells like a RouterOS bug, so support@mikrotik.com. If counting the connection timeout up actually has some special meaning, it should be stated in the documentation, which is not the case.

local currentGw [ip route get [find active=yes 0.0.0.0/0 in dst-address !routing-mark] gateway]
if ([len [/system script environment find name=previousGw]]=0) do={global previousGw $currentGw}
if ($currentGw!=previousGw) do={
  set previousGw $currentGw
  ...put whatever the script should do when it detects a gateway change here ...
}

• the first line stores the gateway of the currently used default route into a local variable currentGw. Local variables "disappear" at the end of the script run (simplified!).
• the second line checks whether the global variable exists; if it doesn't because it is the first run of the script ever or after a reboot, it creates and initializes it. You can initialize it to the current value, which means that the script will never execute its "on-change" part during the first run, or you can initialize it to 0.0.0.0 which means the opposite. The choice is yours.
• the first thing the "on-change" part must do is to store the current value so that it doesn't get executed on the next run if no actual change has happened (line 4).

I would use 'dst-address~":5060$"' form: it doesn't touch ports 50600-50609 and it should be a bit faster

@NathanA,
your scenario really smells like a RouterOS bug, so support@mikrotik.com. If counting the connection timeout up actually has some special meaning, it should be stated in the documentation, which is not the case.

`
Agreed, it smells like a bug. But I'm not the first one to encounter it and it has already been discussed ad nauseam on these forums for years, so it is hard for me to believe that MT support & engineers are not already aware of it. I can also tell you from past experience that reporting it via support@ is a waste of time until I can find a way to reliably reproduce it (which I totally understand -- how are they going to fix something that they themselves cannot verify? -- but is still a roadblock).

I also have a feeling this is a Linux bug at the core, not a ROS bug in particular. It would be nice if MT could implement a fix in current RouterOS, but what if it is already fixed in later Linux kernels? Chances are good that we will just get the response "you will have to wait for RouterOS 7" as so many other people have received when it comes to other core engineering/structural defects. Unfortunately, ROS is not going to be off of Linux 3.3.5 (+ custom patches) until RouterOS 7, and at this point who knows when (or if) that will ever happen...

-- Nathan

/ppp profile
set *0 on-down=":local einwahlether\r\
    \n:if ([/interface get [/interface pppoe-client get [find where disabled=no] interface] type]=\"vlan\") do={:set einwahlether ([/interface vlan get [find where vlan-id=31] interface])} else={:set einwahlether ([/interface pppoe-client get [find w\
    here disabled=no] interface])}\r\
    \n\r\
    \n:local einwahlppoe\r\
    \n:set einwahlppoe  ([/interface pppoe-client get [/interface pppoe-client find disabled=no] name])\r\
    \n\r\
    \n:if ([/interface ethernet find name=\$einwahlether disabled=no] !=\"\") do={\r\
    \n:if ([/interface pppoe-client find name=\$einwahlppoe disabled=no] !=\"\") do={\r\
    \n  /interface pppoe-client disable \$einwahlppoe\r\
    \n  /interface ethernet disable \$einwahlether\r\
    \n  delay 3\r\
    \n  /interface ethernet enable \$einwahlether\r\
    \n  delay 2\r\
    \n  /interface pppoe-client enable \$einwahlppoe\r\
    \n}\r\
    \n}\r\
    \n"


/system scheduler
add interval=5m name=activate-interfaces-every-5-min on-event=\
    "\r\
    \n/interface ethernet enable [find where disabled=yes comment!=\"disabled\"]\r\
    \n/interface pptp-client enable [find where disabled=yes comment!=\"disabled\"]\r\
    \n/interface pppoe-client enable [find where disabled=yes comment!=\"disabled\"]" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

In Terminal - yep, but when you paste the script via WinBox - nope

Im surprised your script is working, because i could only truly reset these connections by disabling the interfaces for a couple of seconds.

Chupaka wrote:

In Terminal - yep, but when you paste the script via WinBox - nope

`
Maybe I am misunderstanding you, but what you say does not appear to be true: if I take this script WITHOUT escaping the $, add it to System > Scripts in Winbox, and then highlight it and click the "Run Script" button, it does not work. If I go in and edit the script and escape the $, and click "Run Script" again, it works perfectly.

Exactly in what context are you able to get the quoted regex to parse without escaping the EOL ($) character? I agree that it shouldn't need to be escaped, but I can't find any place where it works without being escaped, either inside or outside of Terminal.

mTwUser wrote:

Im surprised your script is working, because i could only truly reset these connections by disabling the interfaces for a couple of seconds.

`
Interesting. We are both an ISP and a VoIP provider, and have deployed hundreds of MTs to customers. So far we have never had manually removing the connection tracking entries NOT work for us, so I see no reason why the script should not work for us, either. I'm not sure what is different between the way you are configuring ROS and the way we are. I might have suggested that the SIP ALG might have additional bugs that compound the issue, and we turn it off for anyone we set up with our VoIP service, but I see from reading your post in the other thread that you turn it off as well. So I'm as surprised/puzzled as you are.

-- Nathan

Though i have to say, the issue doesn't always come up, what seems to happen (for us) is if there is only a brief disconnection of PPoE (like really quickly, [...]). I think your disconnections are long enough, thats why the issue doesn't happen, [...]

No, ours tend to happen after brief disconnections, too. It's rare, but we have even seen it happen *immediately* after a reboot ('tik boots up, PPPoE connects, SIP still stuck). And, yes, it doesn't always happen to us either...in fact it has been FRUSTRATINGLY difficult to reproduce in a lab. If I *try* to make it happen, it will never happen.

Maybe I am misunderstanding you, but what you say does not appear to be true: if I take this script WITHOUT escaping the $, add it to System > Scripts in Winbox, and then highlight it and click the "Run Script" button, it does not work. If I go in and edit the script and escape the $, and click "Run Script" again, it works perfectly.

It would be nice when NAT entries in general (and for SIP in particular) were more aware of interfaces going down/up, routing to change, etc.

As far as I know, the SIP server has a limited number of connections on the account. If the limit is exceeded, the SIP server will block the connection.

I also have a feeling this is a Linux bug at the core, not a ROS bug in particular. It would be nice if MT could implement a fix in current RouterOS, but what if it is already fixed in later Linux kernels?
-- Nathan