I’m pushing several hundred concurrent SIP sessions. Every INVITE goes to dport 5060, torch shows this true.
The first rule below follows the same filter as I put into torch, yet the counters do not increment. Everything hits the second rule instead.
You shouldnt need to specify the out interface, try without that. you could also try identifying it via the source port instead of destination as well.
I have better luck identifying via my local IP’s instead of publics for some reason too.
No luck with or with out the interface nor using source port, which thankfully is static in this case. The WAN and LAN IP are one and the same, it’s a routed public internet address. Using the destination address instead of the source along with the afore mentioned combinations also does not work.
tcpdump running directly on the XXX.200 machine verified what torch shows:
# tcpdump -i eth1 -n -nn -N -s 0 src XXX.XXX.XXX.200 and udp dst port 5060
15:04:45.286216 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.27.5060: SIP, length: 424
15:04:46.444211 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 436
15:04:47.075953 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 467
15:04:48.926155 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 467
15:04:50.907552 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 803
15:04:53.230850 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 803
15:04:55.991327 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 436
15:04:59.211580 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 467
15:05:05.039716 IP XXX.XXX.XXX.200.5060 > XXX.XXX.XXX.44.5060: SIP, length: 803
I’m at a loss as to why the MT fw isn’t catching it. Over the past several days since my initial post, several thousand packets have hit the rule, but it’s definitely not all of them. Only 3 have hit it over the past hour, when it should be 1 every could seconds.