NAT issues with SIP

Started by mattlf, April 30, 2025, 02:11:23 PM

Previous topic - Next topic
April 30, 2025, 02:11:23 PM Last Edit: April 30, 2025, 02:56:46 PM by mattlf
Currently on OPNsense 25.1.5_5, recently upgraded from 25.1.3 or 25.1.2 where the issue didn't exist, checked my audit log no other configuration changed since.

I currently cannot make outbound calls via my PBX server, IPs mentioned faked. I use Hybrid Outbound NAT generation.

I have my OPNsense firewall GW at 50.0.0.1
Default traffic goes outbound via 50.0.0.1 via auto NAT rule
My PBX server is locally at 10.0.0.100
I NAT all inbound traffic for the PBX server to 50.0.0.5, all works fine
I have an outbound NAT rule for all traffic from 10.0.0.100 to translate to 50.0.0.5, the rule is super simple, looks like:

interface: WAN
prot: any
src: 10.0.0.100
src port: any
dest: any
dest port: any
translate 50.0.0.5
static port: yes

placed at the top of outbound rules

If I run a public IP check from FreePBX server and do an IP check e.g: curl ifconfig.me, I can verify it's being correctly NAT'd publically to 50.0.0.5

If I manually send some packets to another remote server from the PBX machine via the port it typically uses (5060) and monitor with tcpdump, the IP is correctly 50.0.0.5

When peforming an outbound call from the PBX machine to our 3rd party SIP Trunk provider, during a packet capture via OPNsense's Diagnostics (attached), I can see that there's traffic via the default gw IP, 50.0.0.1, not 50.0.0.5, which it should be being translated to.

I've also tried adding a catch-all outbound rule for the 3rd party IP, forcing anything going to it to use 50.0.0.5 as well, but also didn't work.

I'm not currently in a position to restore an earlier version of 25.1.x to confirm if it's related, but it's my best guess at the moment. Would anyone have any other ideas to check?

Thanks for any help.



Hi mattlf, I don't have a public IP range to test this but I think, from older posts I read, that you have to declare the additional public IPs of your range as VIPs (virtual IPs).

Thanks for the reply @muchacha_grande, VIP was already defined though and inbound + non-SIP outbound working correctly so that wasn't it.

I have since just upgraded to version 25.1.6, captured some outbound SIP packets and the issue seems resolved...

I cannot see anything obvious in changelog that would obviously be related but seeing as it was working correctly on ~25.1.3, not on 25.1.5, and now working correctly on 25.1.6 (without me changing any configuration) I'm going to assume this could have been been a bug introduced in .4 or .5, would recommend an update if anyone is encountering the same issue on those versions.

Would love confirmation that it was for my own sanity and it wasn't just me doing something silly, but in any case looks to be working fine in 25.1.6