OPNsense Forum

Hello,

I am having an issue with the SIP trunk on my Telekom fiber connection.

In general, everything works correctly. The Grandstream HT802v2 successfully registers both telephone numbers (one for telephone and one for fax). Both lines can make and receive calls, caller ID works, and incoming numbers are displayed correctly.

However, after some time — sometimes after 3 hours, sometimes only after a day — the lines become "dead".

When someone calls in, the call is immediately forwarded to voicemail. When trying to make an outgoing call, I get a busy signal.

The Grandstream's status page still shows both lines as **Registered**.

The problem eventually resolves itself without any intervention. Sometimes this happens within 15 minutes, but often it takes 1–2 hours.

Sometimes only one of the two lines is affected. The Internet connection itself remains fully operational during this time.

### Troubleshooting

To diagnose the problem, I have already captured traffic on the LAN interface of the Grandstream while the problem was occurring. I also enabled debug logging on the Grandstream and forwarded the logs to an external syslog server.

From what I can tell, it looks as if Telekom is acknowledging the keep-alive packets, while the SIP registration itself may actually have expired.

In OPNsense, under **Firewall > Diagnostics**, the states/connections show that the Grandstream keeps its connections to Telekom open and that they remain **Established**. According to the keep-alive interval, packets are exchanged approximately every 30 seconds.

Despite this, the SIP connection eventually becomes unusable.

At this point, even with some help from AI, I have reached the limits of my knowledge regarding what is actually causing the problem or which setting I might need to change.

Network setup

┌─────────────────────┐
│    Fiber connection │
└──────────┬──────────┘
           │
           │ Fiber
           ▼
┌─────────────────────┐
│   Media converter   │
└──────────┬──────────┘
           │
           │ Ethernet
           ▼
┌─────────────────────┐
│      OPNsense       │
│      Firewall       │
└──────────┬──────────┘
           │
           │ Ethernet
           ▼
┌─────────────────────┐
│ Grandstream HT802v2 │
│                     │
│  FXS 1 ─────────────┼──────► Telephone
│                     │
│  FXS 2 ─────────────┼──────► Fax
└─────────────────────┘

Settings I have already tried

OPNsense:

• Outbound NAT set to Hybrid
• Static Port enabled in the Outbound NAT rule for the Grandstream's fixed IP address
• Normalization disabled for the Grandstream's IP address on both the LAN and PPPoE interfaces, so that the QoS Layer 3 packet markings are not removed

Grandstream HT802v2:

• Updated to the latest stable firmware (not beta): 1.15.1
• Scheduled daily reboot at 03:00
• SIP transport protocol: TCP (I also tried UDP)
• SIP Server: tel.telekom.de
• DNS Mode: SRV
• Keep-Alive: On
• Keep-Alive method: OPTIONS/NOTIFY → OPTIONS
• Keep-Alive interval: 30 seconds
• Register Expiration: 12 minutes
•   I also tested 15 minutes, 8 minutes and 20 minutes
• Only the following codecs are enabled:
•   G.722
•   PCMA

My questions

Has anyone experienced a similar problem with Telekom SIP trunks behind OPNsense?

Is there anything specific I should check in OPNsense regarding SIP over TCP, NAT, state timeouts, or connection tracking?

Could there be an issue with the SIP registration being considered valid by the Grandstream even though the registration has actually expired on the Telekom side?

Any suggestions on what I could check next would be greatly appreciated.

Thank you!

Have you tried killing the session on the firewall when the issue occurs? Basically just a data point, but it might help determine the point in the protocol stack where the issue lies.

Quote from: Xaver on Today at 02:57:32 PMOPNsense:

• Outbound NAT set to Hybrid
• Static Port enabled in the Outbound NAT rule for the Grandstream's fixed IP address
• Normalization disabled for the Grandstream's IP address on both the LAN and PPPoE interfaces, so that the QoS Layer 3 packet markings are not removed

Don't you need to do some Port Forwards for VoIP too ?!

The last time I was messing around with VoIP was around 15 years ago, so I don't remember all the rules exactly :)