SIP traffic getting hijacked by router

[totalimpact]

On pfsense 2.4.2,
I have some Aastra phones behind the router, which connect to a cloud PBX and work fine.

Today I am deploying a new onsite PBX, and when making calls, there seems to be some sort of proxy running on pfsense that is stealing the calls. I do not have the sipproxy package installed, and cannot find any mention of this in the settings. I have set this up many times, and have tried manual outbound nat, with static UDP, and also non-static, same results.

LAN	udp	192.168.10.22:5060 -> 127.0.0.1:19000 (remote.sip.trunk:5060)	NO_TRAFFIC:SINGLE	7 / 0	6 KiB / 0 B

What on earth is 127.0.0.1 doing in there?? Shouldnt it show my WAN IP?? This sounds like a proxy on the router has stolen the traffic, but under Services menu there is no Sipproxy option.

I made a outbound NAT rule like this, at the top of the rule list (tried both on and off static port):

WAN1	any	udp/*	*	udp/5060	WAN1 Address	*	Static Port Y/N SIP_Out

[totalimpact]

As usual I found the issue right after posting:
Advanced > Firewall & NAT > NAT Reflection mode for port forwards

Has to be disabled. There is some sort of bug there, yes I have a port forward for SIP, but my outbound SIP traffic is not destined for my WAN IP, it is destined for my trunk provider in the cloud, so I dont understand why that was grabbing the traffic and routing it back in.

Any outbound calls were actually ringing back in to my pbx and hitting the default IVR, so that is definitely an issue with the reflection detection (new rock band?). I might try this on 2.4.3x some day to see if there is any improvement.

[Derelict]

Because you told it to do that by enabling NAT reflection on that rule. If you don't want NAT reflection, disable it. It can be disabled on a per-port-forward basis.

[totalimpact]

You are implying I dont understand reflection, so correct me if I am wrong, this applies to internal packets from the LAN that are going outbound destined to the WAN IP on a port that has a forwarding rule?? In which case the traffic never hits the WAN, the reflection instead bounces it back in to the port forward destination on the LAN side - right??

Example: LAN 192.x.x.x, WAN 55.5.5.5 Traffic from 192.x.x.x destined to 55.5.5.5:25 gets sent directly to my mail server on the 192.x.x.x and never even hits the WAN.

Well in my case, traffic from 192.x.x.x destined for 64.4.4.4 (something in the clouds), and it was getting reflected without ever hitting the WAN - why?? I am pretty sure this would not meet the reflection criteria, unless I have made an error in one of my rules.

I want to understand the proper workings of this, because I really need the reflection for some other services that I dont have DNS control over.

[Derelict]

Post your /tmp/rules.debug file and I will show you the rules natting/passing the traffic. PM it if you're not feeling like an exhibitionist. I'll need to know the actual IP address for remote.sip.trunk for completeness. Not sure I will be able to find it unless you post the rules.debug file when it is in the malfunctioning state (NAT reflection enabled based on your description).

[totalimpact]

well I see the yellow pages are in there, thanks so much for extending the offer, but PM wont allow that quantity of text. I will just do as advised and disable the reflection on just that rule.

[Derelict]

If you are interested I can provide a secure upload link outside of the forum.

I generally like to see the exact rules that cause unexpected behavior. Kind of like seeking closure and understanding.