I have a srcnat rule setup as follows (public IP changed of course)
0 chain=srcnat action=src-nat to-addresses=1.1.1.21
src-address=172.16.10.21 out-interface=ether1 internet
The PBX looks like its dst nat is working. It also has incoming connections to it, but srcnat is showing no traffic at all as well the PBX is not communicating back to the devices that are external to our business. I have no firewall rules in place that would block it, and I moved the srcnat and dstnat rules for my pbx to 0 and 1 respectively.
Any ideas? The internal LAN ip phones are working fine. I need the offsite IPphones with static IP addresses from AT&T to connect to the IPU address (ie. 1.1.1.21) and it appears they are, but my PBX is not responding to them.
are you sure your PBX isnt responding to them? Have you run wireshark (pcap) to see if its just replying to a private IP that doesnt exist on your network?
why would it respond to a private IP if my srcnat and dst nat rules are 1:1? Im not using masquerade. Im using 1 private to public. anything incoming should be forwarded to the private IP and anything outgoing should be forwarded to the public IP.
If the PBX isn’t initiating traffic to the WAN the source NAT rule wouldn’t show hits - the translation for return traffic in connections originally established from the outside is done as part of the destination NAT (or rather, the undoing of the destination NAT), and technically you don’t even need a source NAT rule. The source NAT rule is good to have to ensure that both traffic in connections established by the PBX as well as in connections established to the PBX shows the same endpoint IPs, but it isn’t strictly necessary from just a routing perspective.
The best way to troubleshoot this really would be Wireshark on a monitor port, or torch or the built in packet sniffer on the router. You didn’t post enough configuration to check whether what you have there is right.
It’s absolutely feasible that the PBX is sending traffic to the wrong place if, for example, it has a bad default route. It would get the destination NAT’d packet correctly from the router and try to send return traffic, but send it to the wrong gateway. So step one is to check if the router is ever seeing any return traffic in those connections.
The reply address in SIP packets are in the payload, not in the IP headers. If you are using SIP, check pcap of the conversation and make sure its not replying to the private IP from the sources network.
this is the dstnat rule right after the src-nat, also if I torch the src. and dst addresses I can see a connection made for about 2 seconds then it disappears.
I have been running torch and it looks like the packets are making it to the PBX just fine. So I see a src address from the static IP of my IP phones offsite, and the dst address as the public IP of my PBX that is in the dstnat rule.
When I go to torch packets from my (src address) Public IP of the PBX I do not see anything going out, however on the internal interface I do see the private IP of the PBX 172.16.10.21 going to the correct destination address.
Adding to this, I can see the IP Phone (offsite) once more on torch, src port of 50076 on one and src port of 49251 while the destination IP (PBX Public) has dst ports of 2944 and 1718