Bon, encore des déboires ahah.

Cette fois, j'ai la redirection de ports qui ne se fait pas correctement : on dirait que le tunnel fonction partiellement (oui ça n'a pas de sens)
J'ai passé plus d'une journée sur le truc sans suspecter OMR...

J'ai finit par mettre mon serveur juste derrière omr, avec des regles et une ip cible. Mes serveurs répondent sans repondre (j'ai internet, mais c'ets comme si les serveurs ne savaient pas s'authentifier).
J'ai baissé la mtu, même chose.

Je finis par mettre un bypass dans les source (omr) + changement de la zone uniquement dans les regles nat (de zone vpn à wan évidement) : les serveurs sont parfaitement enfin joignables depuis les wans...
J'enlève le bypass + repassage des zones en zone vpn, le serveur répond à moitié avec l'ip vps.
Le vps n'a pas de parefeu externe (host) ni interne (linux) autre que ce qui est géré par OMR.

Je constate (merci l'ia) qu'il y a un soucis avec le peer : le vps a un peer en 3 ou 4, et la vm est en 2 par exemple.
Je redémarre l'un, l'autre, et toujours des différences.
J'ai tenté de relancer le script aussi. Même constat.
Là, après avoir remis mqvpn, je n'arrive même plus à me connecter à la vm locale en ssh ou web...

J'ai tenté mqvpn et glorytun udp... avec mqvpn y'a pas d'affichage tout court des serveurs (j'avais commencé par là d'ailleurs, en config @stock).

Bref, j'abandonne à nouveau OMR, et je vais refaire de l'ip6ip6 et ip4ip6...

VPS debian 13 pulseheberge, vm debian 13 sous proxmox.
Les autres omr semblent bien fonctionner (une qui était en glory et l'autre mqvpn, mais je ne sais pas pourquoi/comment s'est fait la config). Une chez sapinet et une chez ionos (vps).

Question bête... Ayant lu que le problème d'hébergement de la partie semblait sensible, est-ce que la même IP peut être serveur et client en même temps dans ce type de jeu (par ex: Grounded)?

Complément pour ceux qui veulent un Asterisk sur un serveur du LAN, et non sur le routeur (cas de farmouss, kdaffef91, olitask... resté sans solution publiée ici). Configuration en service depuis fin septembre 2026 : Asterisk 22 (PJSIP) sur un NAS Debian, derrière un Xiaomi AX3000T sous OpenWrt branché sur l'ONT, NB6VAC éteinte. Entrants, sortants, présentation du numéro, DTMF, urgences.

Prérequis : une IPv4 publique dédiée (pas de CGNAT, sinon aucune redirection possible, voir plus haut dans le fil) et fixe, puisqu'elle est écrite dans la configuration.

1. Routeur OpenWrt : deux redirections vers le serveur, MÊMES ports des deux côtés (Asterisk annonce ses ports tels quels ; une translation de port casse l'audio). Pas d'ALG SIP.

config redirect
option name 'SIP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '5062'
option dest_ip '192.168.1.X'
option dest_port '5062'
option target 'DNAT'
option reflection '0'
option src_ip '92.91.129.136'

(même bloc quatre fois de plus, avec src_ip 92.91.129.152, .168, .184 et .200)

config redirect
option name 'RTP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '20000-20099'
option dest_ip '192.168.1.X'
option dest_port '20000-20099'
option target 'DNAT'
option reflection '0'

Les cinq adresses sont celles de trappes.p-cscf.sfr.net (getent ahostsv4 trappes.p-cscf.sfr.net). Une redirection par adresse : je n'ai pas vérifié qu'une seule redirection avec une liste src_ip soit respectée par fw4. Vérifier après coup avec nft list chain inet fw4 dstnat_wan que chaque règle SIP-SFR porte bien son ip saddr. Le RTP reste sans restriction : les passerelles média de SFR ne sont pas connues d'avance. Le routeur conserve le port source 5062 en sortie (vérifié dans conntrack).

Constat intéressant : les compteurs des cinq règles SIP sont à 0 depuis le dernier redémarrage du routeur, alors que des appels entrants sont arrivés depuis. Les INVITE de SFR passent donc par la correspondance NAT que maintiennent les REGISTER et les OPTIONS sortants depuis le port 5062, et non par la redirection, qui ne sert qu'en secours. Ça va dans le sens du rôle des OPTIONS décrit plus bas, sans le démontrer.

2. rtp.conf

[general]
rtpstart = 20000
rtpend = 20099
strictrtp = yes

3. pjsip.conf (numéro, NDI et mot de passe remplacés)

[transport-sfr]
type = transport
protocol = udp
bind = 0.0.0.0:5062
external_signaling_address = <IP publique>
external_signaling_port = 5062
external_media_address = <IP publique>
local_net = 192.168.1.0/24

[sfr-auth]
type = auth
auth_type = digest
username = NDI...@sfr.fr
password = <mot de passe SIP>

[sfr]
type = registration
transport = transport-sfr
outbound_auth = sfr-auth
server_uri = sip:ims.mnc010.mcc208.3gppnetwork.org
client_uri = sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user = +33XXXXXXXXX
outbound_proxy = sip:92.91.129.168:5062\;lr
expiration = 3600
retry_interval = 60
max_retries = 10000
forbidden_retry_interval = 600
fatal_retry_interval = 600
auth_rejection_permanent = no

[sfr]
type = endpoint
transport = transport-sfr
context = depuis-sfr
disallow = all
allow = alaw,ulaw
dtmf_mode = rfc4733
direct_media = no
outbound_auth = sfr-auth
outbound_proxy = sip:92.91.129.168:5062\;lr
from_domain = ims.mnc010.mcc208.3gppnetwork.org
from_user = +33XXXXXXXXX
aors = sfr
rewrite_contact = yes
100rel = yes
rtp_symmetric = yes
force_rport = yes
trust_id_inbound = yes

[sfr]
type = aor
contact = sip:ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy = sip:92.91.129.168:5062\;lr
qualify_frequency = 60

[sfr]
type = identify
endpoint = sfr
match = 92.91.129.136
match = 92.91.129.152
match = 92.91.129.168
match = 92.91.129.184
match = 92.91.129.200

4. Sortants, dans extensions.conf : donner l'URI explicitement (les urgences 15, 17, 18, 112... de la même façon).

exten => _0XXXXXXXXX,1,Dial(PJSIP/sfr/sip:${EXTEN}@ims.mnc010.mcc208.3gppnetwork.org,120)

Deux pièges propres au cas « derrière NAT », qui m'ont coûté deux semaines (détail dans mon fil : https://lafibre.info/remplacer-sfr/asteriskopenwrt-entrants-perdus-apres-inactivite-ok-apres-un-sortant/) :

- Sans la qualification OPTIONS de l'AOR (qualify_frequency = 60, avec l'outbound_proxy répété DANS l'AOR, celui de l'endpoint ne vaut pas pour les OPTIONS), les appels entrants cessaient d'arriver après quelques heures sans communication, alors que l'inscription restait active. Avec : cinq silences de 6 h à 28 h tenus sans perte.

- Avec la qualification, si le proxy ne répond plus aux OPTIONS pendant quelques minutes, le contact passe Unavailable et la forme habituelle Dial(PJSIP/${EXTEN}@sfr) refuse localement TOUS les sortants, urgences comprises (« cause 3 - No route to destination »). L'URI explicite du point 4 contourne ce blocage : vérifié en forçant le contact Unavailable.

Si tu déménages en mai 2027 reste chez ton opérateur, c'est absurde de faire un changement pour quelques mois.

Bonjour à tous
Pour faire court : je souhaiterais un avis éclairé sur la démarche à suivre svp :

Suis client Red depuis 2020, (Adsl, puis déménagement = Fibre FTTH puis (re) (re) déménagement ...
j'en passe des étapes ! ... et  cerise sur le gâteau = Déménagement prévu en mai 2027 ...

je suis aujourd'hui à 19,99 (Box 7 fibre, sans Ont) = ce qui avec l'augmentation reçue par courriel aujourd'hui (+2,49) = 22,48
Compte tenu des étapes de fin de vie de nos (mon) contrat , ma question est :
Que faut-il faire  / Que feriez-vous ?

ps : ma position actuellement est = je ne fais rien où .. mais ?

Merci de vos lanternes pour un retraité pas trop geek