Wrong network interface when registering to server

Before I begin, let me introduce the basic structure of my Asterisk server.

Asterisk uses PJSIP, connected to an ISP-provided SIP service on one side and multiple extensions on the other.

The server itself has several NICs: ens33, ens34, ens35, and ens37. Among them, ens33 is for internet connection using DHCP; ens34 is for other purposes with IP 192.168.11.11/255.255.255.0; ens35 is for ISP-provided SIP service using DHCP, with an assigned address range in 172.0.0.0/7 (which I believe is incorrectly configured as it includes global IPv4 addresses); and ens37 is for other extensions connecting to Asterisk, using IP 192.168.33.1/255.255.255.0.

Now, considering my situation, I have allocated two transports in pjsip.conf as follows:

[external-udp]
type=transport
protocol=udp
bind=173.28.123.123        // ip address for ens35 which is dynamically configured

[internal-udp]
type=transport
protocol=udp
bind=192.168.33.1        // ens37 for extensions

Then, I used ip route add 172.0.0.0/7 dev ens35 to manually control routing in the multi-NIC setup.

However, Asterisk is unable to register with the ISP’s SIP service. Packet capture shows that Asterisk attempts to send packets with 173.28.123.123 as the source IP via ens34, which is futile.

My confusion is, given that I’ve already configured the bind address and routing for ens35, why is Asterisk still sending register packets from ens34? Where might the issue be?

Moreover, how should the bind address be handled in the case where ens35’s IP is dynamically assigned via DHCP? Could this be related to my problem?

Any suggestions would be greatly appreciated!

Asterisk does nothing, you have a routing problem. Packets are going out where network route send them.

That’s why I’m confused. traceroute shows that the routing table 172.0.0.0/7 dev ens35 works, and mtr shows an identical route too. Only Asterisk chooses the wrong NIC to send REGISTER to.

What is the actual configuration, and not just for transports?

Here it is.
Thanks a lot!

[external-udp]

type=transport

protocol=udp

bind=172.25.123.123

[internal-udp]

type=transport

protocol=udp

bind=192.168.33.1

[mytrunk]

type=registration

transport=external-udp

outbound_auth=mytrunk_auth

outbound_proxy=sip:[redacted].js.ctcims.cn:5060\;lr

server_uri=sip:js.ctcims.cn

client_uri=sip:+86XXXXXXXXXXX@js.ctcims.cn:5060

contact_user=+86XXXXXXXXXXX

retry_interval=60

forbidden_retry_interval=120

expiration=120

line=yes

endpoint=mytrunk

[mytrunk_auth]

type=auth

auth_type=userpass

password=[redacted]

username=+86XXXXXXXXXXX@js.ctcims.cn

;realm=js.ctcims.cn

[mytrunk]

type=endpoint

transport=external-udp

context=from-external

disallow=all

allow=opus

allow=g722

;allow=g729

outbound_auth=mytrunk_auth

aors=mytrunk

;force_rport=yes

;direct_media=no

;ice_support=yes

[mytrunk]

type=aor

contact=sip:+86XXXXXXXXXXX@js.ctcims.cn:5060

max_contacts=1

[mytrunk]

type=identify

endpoint=mytrunk

match=172.0.0.0/7

[8001]

type=endpoint

transport=internal-udp

context=from-internal

disallow=all

allow=opus

allow=g722

auth=8001

aors=8001

[8001]

type=auth

auth_type=userpass

password=XXXX

username=8001

[8001]

type=aor

max_contacts=1

contact=sip:8001@192.168.33.11:5060

Please also provide a SIP trace using “pjsip set logger on” of the attempt.

<--- Transmitting SIP request (634 bytes) to UDP:172.xxx.xxx.xxx:5060 --->

REGISTER sip:js.ctcims.cn SIP/2.0

Via: SIP/2.0/UDP 172.yyy.yyy.yyy:5060;rport;branch=[redacted]

Route: <sip:[outboundproxy].js.ctcims.cn:5060;lr>

From: <sip:+86XXXXXXXXXXX@js.ctcims.cn>;tag=[redacted]

To: <sip:+86XXXXXXXXXXX@js.ctcims.cn>

Call-ID: [redacted]

CSeq: ***** REGISTER

Contact: <sip:+86XXXXXXXXXXX@172.yyy.yyy.yyy:5060;line=xxxxxxxxx>

Expires: 120

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER

Max-Forwards: 70

User-Agent: Asterisk PBX 20.9.0

Content-Length: 0

As is shown above, the REGISTER packet itself seems valid. But I cannot capture the register packet on ens35. Instead, it’s sent from ens34, using ens35’s IP address as source IP.

From an Asterisk perspective nothing seems to be out of the ordinary, and you’ve even explicitly set it to use the transport bound to the specific IP address. If the IP address is bound on the correct interface then Linux should send it out that interface, unless something else outside of Asterisk is causing it not to. Asterisk just binds to local IP addresses, and the routing and interface usage is outside of it.

After changing [external-udp] to bind=0.0.0.0 , it works……
Thanks a lot!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.