But I’m pretty sure that 192.168.96.225 is the correct value, because in your post #16, Frontier said that they successfully ping your router at 192.168.96.226 from their SBC 192.168.96.225.
Also, what is connected to eth11 on the router?
Sorry about that I sent from Lab test machine but made some progress here is the current results the 192.168.96.226 is the inbound address from the trunk provider going to eth11 on a edge router the 192.168.96.225 is the trunk address.
Capturing eth11 Frontier Connection IP address 192.168.96.226 On Interface eth11 see results below also provided the pjsip logger info below
parrishpc@EdgeRouter-12:~$ show interfaces ethernet eth11 capture
Capturing traffic on eth11 …
21:03:05.960615 IP 192.168.96.226.36088 > 255.255.255.255.10001: UDP, length 4
21:03:18.292313 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:18.294388 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:18.792727 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:18.793977 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:19.793552 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:19.794900 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:21.794097 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:21.795341 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:24.856701 ARP, Request who-has 192.168.96.225 tell 192.168.96.226, length 28
21:03:24.857213 ARP, Reply 192.168.96.225 is-at 80:2d:bf:70:c2:50, length 46
21:03:25.794139 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:25.795773 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:29.793476 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:29.794717 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
21:03:33.793355 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
21:03:33.794624 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
From res_pjsip_logger
2023-09-12 16:06:37] VERBOSE[2970] res_pjsip_logger.c: <— Transmitting SIP request (435 bytes) to UDP:192.168.96.225:5060 —>
29421 OPTIONS sip:192.168.96.225:5060 SIP/2.0
29422 Via: SIP/2.0/UDP 192.168.96.225:5060;rport;branch=z9hG4bKPj3b95cca8-0929-488a-a87f-353112f11b8f
29423 From: sip:[email protected];tag=c1fbfe07-6150-4a83-afae-5cdcdaa83f9e
29424 To: sip:192.168.96.225
29425 Contact: sip:[email protected]:5060
29426 Call-ID: bae6ef81-ee9b-44fc-8dd6-2f4b9b1a488c
29427 CSeq: 36178 OPTIONS
29428 Max-Forwards: 70
29429 User-Agent: FPBX-16.0.40.4(18.19.0)
29430 Content-Length: 0
In Asterisk SIP Settings (or other setting that may override it), External Address seems to be set to 192.168.96.225; it should be 192.168.96.226. After changing this, Submit and Apply Config, you must restart Asterisk.
Ok made changed and restarted astrack have results below and a question on MATCH PERMIT setting in the trunk setup.
PJSIP LOGGER RESULTS
63648 [2023-09-13 08:20:54] VERBOSE[2489] res_pjsip_logger.c: <— Transmitting SIP request (435 bytes) to UDP:192.168.96.225:5060 —>
63649 OPTIONS sip:192.168.96.225:5060 SIP/2.0
63650 Via: SIP/2.0/UDP 192.168.96.226:5060;rport;branch=z9hG4bKPj7ba94cd3-51a7-46fa-a995-27226279ff26
63651 From: sip:[email protected];tag=ce53b502-5f5d-461f-89dd-0d55ea230817
63652 To: sip:192.168.96.225
63653 Contact: sip:[email protected]:5060
63654 Call-ID: 90fb7b02-400a-43f3-afd1-c09018a663ab
63655 CSeq: 15979 OPTIONS
63656 Max-Forwards: 70
63657 User-Agent: FPBX-16.0.40.4(18.19.0)
63658 Content-Length: 0
Dose it matter if there is a value in the Match Permit in the trunk setup see image below.
when I leave it blank it shows a subnet of /32
Here is what match permit shows when there is a value 192.168.96.226/30
Endpoint: 8159382000 Unavailable 0 of inf
Aor: 8159382000 0
Contact: 8159382000/sip:192.168.96.225:5060 d020a302ba Unavail nan
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
Identify: 8159382000/8159382000
Match: 192.168.96.224/30
Match endpoint 192.168.96.224/30
Here is what the endpoint shows when MATCH PERMIT has no value
Endpoint: 8159382000 Unavailable 0 of inf
Aor: 8159382000 0
Contact: 8159382000/sip:192.168.96.225:5060 d020a302ba Unavail nan
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
Identify: 8159382000/8159382000
Match: 192.168.96.225/32
Match (Permit) should be left blank. It is used when the provider sends calls from multiple IP addresses (load balancing, failover, etc.) It does not apply to your case.
The outgoing OPTIONS request looks fine, but the PBX is apparently not getting a response. I would guess it’s a firewall issue. Check on its eth11 interface. You should see the outgoing OPTIONS source address rewritten to 192.168.96.226 port 5060 and replies from 192.168.96.225 port 5060 to 192.168.96.226 port 5060.
On the LAN interface, the replies should be sent from 192.168.96.225 port 5060 to 192.168.2.200 port 5060. If this is all correct, possibly FreePBX firewall or something in the virtualization system is blocking the replies. Does sngrep show replies? If not, can you see them on the host interface?
Here is the the capture for eth11
Capturing traffic on eth11 …
16:25:00.889080 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:03.305490 IP 192.168.96.226.41695 > 255.255.255.255.10001: UDP, length 4
16:25:06.389538 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:10.108991 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:10.111219 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:10.609628 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:10.611046 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:11.609875 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:11.611299 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:11.889905 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:13.610905 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:13.612289 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:15.176727 ARP, Request who-has 192.168.96.225 tell 192.168.96.226, length 28
16:25:15.177204 ARP, Reply 192.168.96.225 is-at 80:2d:bf:70:c2:50, length 46
16:25:17.390879 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:17.610615 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:17.611998 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:21.610413 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:21.611890 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:22.891803 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:25.610910 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:25.612313 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:28.392683 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:29.610698 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:29.612098 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:33.610799 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:33.612318 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:33.894902 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:34.307381 IP 192.168.96.226.50904 > 255.255.255.255.10001: UDP, length 4
16:25:37.610065 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:37.611432 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
16:25:39.394844 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
16:25:41.610785 IP 192.168.96.226.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
16:25:41.612193 IP 192.168.96.225.62539 > 192.168.96.226.5060: SIP: SIP/2.0 200 OK
The OPTIONS sent looks ok, but I have no idea why the Frontier SBC is sending the reply from a different port. This does not look like a ‘reply’ to the firewall, so it drops it. In the firewall, try forwarding UDP destination port 5060 to 192.168.2.200 port 5060. With luck, pjsip will ignore the strange port number and the trunk will become available. If not, you’ll have to ask Frontier if they can change a setting at their end so the reply comes from the same port the request was sent to.
Frontier is also sending you OPTIONS from a strange port. The port forward I mentioned earlier should allow this to reach the PBX. If they don’t get your replies, please post pjsip logger output showing their request and your reply.
Here is the results thanks again.
70733 [2023-09-13 12:24:13] VERBOSE[18296] res_pjsip_logger.c: <— Transmitting SIP request (435 bytes) to UDP:192.168.96.225:5060 —>
70734 OPTIONS sip:192.168.96.225:5060 SIP/2.0
70735 Via: SIP/2.0/UDP 192.168.96.226:5060;rport;branch=z9hG4bKPjc9aa1b9a-5fcf-4d26-beda-e5142ae69f4b
70736 From: sip:[email protected];tag=f4d09851-f4f6-4710-9975-3b1488055e65
70737 To: sip:192.168.96.225
70738 Contact: sip:[email protected]:5060
70739 Call-ID: f37ed5b5-1da5-4f82-9b23-797322eb07cd
70740 CSeq: 49571 OPTIONS
70741 Max-Forwards: 70
70742 User-Agent: FPBX-16.0.40.4(18.19.0)
70743 Content-Length: 0
Results of what? You only posted the outgoing OPTIONS request, but that was fine before. The forwarding change is an attempt to get the replies back. Are you getting them now? If not, you need to capture at various points to see why they are getting lost. If you are getting replies, does the trunk show as available?
Ok I have forwarded UDP destination port 5060 to 192.168.2.200 port 5060
Here are the results from the capture of eth11
parrishpc@EdgeRouter-12:~$ show interfaces ethernet eth11 capture
Capturing traffic on eth11 …
02:03:00.630370 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:03.833984 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:04.630085 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:05.656703 ARP, Request who-has 192.168.96.225 tell 192.168.96.226, length 28
02:03:05.657238 ARP, Reply 192.168.96.225 is-at 80:2d:bf:70:c2:50, length 46
02:03:05.784630 IP 192.168.96.226.37863 > 255.255.255.255.10001: UDP, length 4
02:03:08.630476 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:09.334117 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:14.836001 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:20.337144 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:25.838229 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:31.339539 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:36.770494 IP 192.168.96.226.36679 > 255.255.255.255.10001: UDP, length 4
02:03:36.840947 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:37.128699 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:37.628934 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:38.629615 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:40.630430 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:42.136701 ARP, Request who-has 192.168.96.225 tell 192.168.96.226, length 28
02:03:42.137192 ARP, Reply 192.168.96.225 is-at 80:2d:bf:70:c2:50, length 46
02:03:42.341708 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:44.630366 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:47.842219 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
02:03:48.629757 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:52.630522 IP 192.168.2.200.5060 > 192.168.96.225.5060: SIP: OPTIONS sip:192.168.96.225:5060 SIP/2.0
02:03:53.343131 IP 192.168.96.225.56259 > 192.168.96.226.5060: SIP: OPTIONS sip:192.168.96.226:5060 SIP/2.0
Still no connection at the trunk endpoint
Somehow whatever you did to forward the port broke NAT – the PBX LAN address (192.168.2.200) should never appear on the Frontier interface.
Do you know whether the request from Frontier appeared in pjsip logger?
I know nothing about EdgeRouter, but a search seemed to show that port forwarding is pretty simple. Based on
I assume that all you need is something like:
configure
set port-forward auto-firewall enable
set port-forward hairpin-nat enable
set port-forward wan-interface eth11
set port-forward lan-interface (whatever interface is connected to the PBX)
set port-forward rule 1 description SIP
set port-forward rule 1 forward-to address 192.168.2.200
set port-forward rule 1 forward-to port 5060
set port-forward rule 1 original-port 5060
set port-forward rule 1 protocol udp
commit ; save
What commands did you use to set this up?
OK need to explain the setup better.
Edge router 12
Eth9 Is wan port
Forwards are done on this lan for WAN traffic.
Eth11 is SIP from Fronter 192.168.96.226 no internet traffic on eth11 just Frontier Sip Trunk 192.168.96.225
masquerade for SIP for nat
So all nat routing was done in masquerade for SIP
pbx is not on an actual lan port on the router it is a Hyper-V on a windows server and the address for this is 192.168.2.200
Here is the routing infomation
IP Route Table for VRF “default”
S *> 0.0.0.0/0 [1/0] via x.x.87.25, eth9
C *> 127.0.0.0/8 is directly connected, lo
C *> 192.168.2.0/24 is directly connected, switch0
C *> 192.168.96.224/30 is directly connected, eth11
C *> x.x.x.24/29 is directly connected, eth9
WanIP on eth9
Here where I can change the routing for the Sip on eth11 see image.
In the Source NAT Rule, under Translation, fill in the Address field with 192.168.96.226 (so the packets will be sent out with the correct source address). Also fill in Dest Address with 192.168.95.225 (to ensure that unrelated SIP traffic on the LAN doesn’t have the rule applied).
At this point, you should see proper OPTIONS being sent out on eth11 and Frontier’s replies. However, if the PBX doesn’t get the replies, I believe you also need a Destination NAT rule and a Firewall rule. According to
I believe that you want:
Firewall / NAT > NAT > +Add Destination NAT Rule
Description: SIP
Inbound Interface: eth11
Translation Address: 192.168.2.200
Translation Port: 5060
Protocol: UDP
Destination Address: 192.168.96.226
Destination Port: 5060
and you probably also need:
Firewall/NAT > Firewall Policies > WAN_IN > Actions > Edit Ruleset > Add New Rule
Description: SIP
Action: Accept
Protocol: UDP
Destination > Port: 5060
Destination > Address: 192.168.2.200
If we can’t get this working soon, is it feasible to put a second NIC on the Hyper-V machine and connect the line from Frontier there, bypassing the EdgeRouter altogether?
I want to thank you for all your help, with working with the provider we found that there was a configuration on their end once configured the sip trunk connected without issue.
I will continue to monitor the forum in hopes that I can help someone with their issue.
Thanks Again
Glad to hear that you got it working. Please post the EdgeRouter settings used and trunk configuration changes for the benefit of future visitors to this thread.
While the majority of such setups connect the trunk to a second NIC on the PBX, many would choose your topology because of physical layout constraints or security concerns.
Based on what I understand about Frontier’s SBC, one from Verizon or AT&T would be almost identical, so your settings are likely widely applicable.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.