/ip firewall connection remove [find where src-address~"\^client's_ip:"]
/ip firewall connection remove [/find where dst-address~"192.168.2.200"]
I tried the script but it doesn't work. I did include an ip address. I don't see anything in my logs te help me find the fault.
Thanks
Dolf
sounds a bit like 'RouterOS routes the SIP client through the VPN, but still NATted with WAN address - because it's imppossible to re-NAT established connection'...Once the interface does come up (seconds after the WAN is online), Mikrotik will not route the SIP client down the VPN, but continue it out the WAN.
and all that time pppoe is up, without disconnects?SIP UDP sessions need to be refreshed with a script every few hours to maintain registration when gateway is a pppoe interface.
What exactly is working? Do you have the same setup?it's working with me without any problems.
can't you just forbid (in Firewall Filter) that connection over Internet, and allow it only via PPTP?PPTP connection takes some time to establish, so routerboard first tries to route the connection over internet NAT and remembers this wrong route for an hour! I have to kill the connection manually to get the phone working.
Timeout is being reset each time a packet matching the state hits the router, no matter what direction this packet is passing in.However, the issue as I see it is that it should only do this for as long as the timeout is valid. After which it should drop the rule and re-establish it when required. What it does instead is that the timeout starts counting up instead of down and never disappears.
I'm not really sure of it ..I've just made a test monitoring 'sip' conn tracking: making a call (sip invite) I've seen no update on timeout.Timeout is being reset each time a packet matching the state hits the router, no matter what direction this packet is passing in.
I've different 'masquerade/src-nat' rules for every outbound wan connections (so I presume the rule must go 'invalid' changing wan conn); I've just made a simple test and the 'assured contrack item' never invalidates on failover.Not sure if it helps, but have you tried specifying out-interface in your NAT rules? Please note though that in this case you might need to have several NAT rules (one for each out-interface).
/ip firewall connection remove [/ip firewall connection find where connection-type="sip" and connection-mark="w1c" and reply-dst-address~"2.2.2.2"]
/ip firewall connection remove [/ip firewall connection find where connection-type="sip" and connection-mark="w2c" and reply-dst-address~"1.1.1.1"]
/ip firewall connection remove [/ip firewall connection find where connection-type="sip" and assured="no"]
[admin@MikroTik] > /ip firewall service-port disable sip
Nathan, if I've a Sip-PBX in lan I've usually disable SipAlg/helper and I make manual/specific rules for SIP and RTP, but if I've several Sip Phones which have to register to external it's really difficult to set up things (not all sip phones permit sip parameters fine tuning) ..you must do sip/rtp rules for each one's. Sometimes impossible, sometimes only .. boringCan your SIP application work without the Linux SIP ALG/NAT helper, and if so, have you tried just turning it off...
interesting .. but not really promisingIt sounds like the Linux SIP NAT helper disregards the UDP connection timeouts you specify for connection tracking. From http://www.dslreports.com/forum/r26935307-: "The reason I suggest disabling it is that one of its 'features' is that it causes SIP connections to disrespect the UDP Timeouts and time out after one hour."
Well, no, it's both interesting and promising. If we can pinpoint where the problem is, then that makes it easier to get specific when filing tickets with MikroTik, and perhaps even makes it easier to devise a workaround that can be used in the meantime. The better your understanding of the problem is, the more effective (and creative) you can be when you go to tackle it.interesting .. but not really promising
..from this point of view you are absolutely right!Well, no, it's both interesting and promising. If we can pinpoint where the problem is .. (cut)
This is really interesting and worth a try! ..time to setup an Asterisk test bed(cut) .. RTP audio (directmedia=no, directrtpsetup=no) and then force-enable "rport"/RFC3581 behavior and symmetric RTP port response for every remote peer (nat=yes) .. (cut) .. multiple SIP phones .. (cut) .. all phones work fine. No manual SIP or RTP rules per phone require ..(cut)