[Gelöst] Debian Server an Fritzbox --> kein Audio bei FritzFon

MB2020

Neuer User
Mitglied seit
3 Dez 2020
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich bin schon einige Zeit am Suchen, wg. einem Update auf meinem Debian Server funktioniert mein Fritzfon an dem Server nicht mehr: ich kann rauswählen, habe aber kein Audio.

Meine Konfiguration:

Debian Server 192.168.1.1
Fritzbox 192.168.1.2
FritzFon läuft auf Android, eingewählt auf dem Debian Server.

Konfiguration des Debian Server
Code:
root@ion:~# lsmod |grep sip
nf_nat_sip             20480  0
nf_conntrack_sip       28672  1 nf_nat_sip
nf_nat                 24576  3 nf_nat_sip,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack          114688  7 nf_conntrack_sip,nf_nat_sip,nf_conntrack_ipv4,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat

Code:
root@ion:~# cat /etc/iptables.up.rules
# Generated by webmin
*filter
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:INPUT ACCEPT [0:0]
-A FORWARD -m conntrack -i wlp2s0 -o enp0s10 -j ACCEPT  --ctstate NEW
-A FORWARD -m conntrack -j ACCEPT  --ctstate RELATED,ESTABLISHED
COMMIT
# Completed
# Generated by webmin
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p udp -m udp --dport 5060 -j CT --helper sip
*mangle
:OUTPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed
# Generated by webmin
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o enp0s10 -j MASQUERADE
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
# Completed

Code:
root@ion:~# route -n
Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.2     0.0.0.0         UG    0      0        0 enp0s10
172.16.0.0      172.16.0.2      255.255.255.0   UG    0      0        0 tun0
172.16.0.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s10
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlp2s0


Ich hatte das Problem schon einmal, kann mich aber an die Lösung nicht mehr erinnern. Es war eine relativ einfache Konfiguration auf dem Debian Server.

Danke Marc
 
Zuletzt bearbeitet:
Fritzbox 192.168.1.2
FritzFon läuft auf Android, eingewählt auf dem Debian Server.
Würde das noch probieren:
Code:
iptables -A PREROUTING -t nat -i enp0s10 -p udp --dport 5060 -j DNAT --to 192.168.1.2:5060
iptables -A FORWARD -p udp -d 192.168.1.2 --dport 5060 -j ACCEPT
 
  • Like
Reaktionen: MB2020
iptables -A PREROUTING -t nat -i enp0s10 -p udp --dport 5060 -j DNAT --to 192.168.1.2:5060 iptables -A FORWARD -p udp -d 192.168.1.2 --dport 5060 -j ACCEPT

Danke. Das war es leider nicht. Ich hab mal iptables loggen lassen, was es blockt:

Code:
Dec  3 16:27:54 ion kernel: [ 8258.368184] iptables denied: IN=wlp2s0 OUT= MAC=00:25:d3:89:61:ea:04:b1:67:0e:ec:f2:08:00 SRC=192.168.2.203 DST=192.168.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=22690 PROTO=ICMP TYPE=0 CODE=0 ID=6322 SEQ=4

und dann noch tcpdump an port 5060 lauschen lassen.

Code:
root@ion:~#  tcpdump -vni any -s0 port 5060
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:59:12.275354 IP (tos 0x0, ttl 64, id 31441, offset 0, flags [none], proto UDP (17), length 786)
    192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 758
        INVITE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK38124
        Max-Forwards: 70
        To: <sip:[email protected]>
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 1 INVITE
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Min-SE: 90
        Session-Expires: 600;refresher=uas
        Content-Length: 261
        Content-Type: application/sdp

        v=0
        [email protected] 0 0 IN IP4 192.168.2.203
        s=Session SIP/SDP
        c=IN IP4 192.168.2.203
        t=0 0
        m=audio 21000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
16:59:12.275475 IP (tos 0x0, ttl 63, id 31441, offset 0, flags [none], proto UDP (17), length 786)
    192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 758
        INVITE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK38124
        Max-Forwards: 70
        To: <sip:[email protected]>
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 1 INVITE
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Min-SE: 90
        Session-Expires: 600;refresher=uas
        Content-Length: 261
        Content-Type: application/sdp

        v=0
        [email protected] 0 0 IN IP4 192.168.2.203
        s=Session SIP/SDP
        c=IN IP4 192.168.2.203
        t=0 0
        m=audio 21000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
16:59:12.280599 IP (tos 0x68, ttl 64, id 45623, offset 0, flags [none], proto UDP (17), length 428)
    192.168.1.2.5060 > 192.168.1.1.47831: SIP, length: 400
        SIP/2.0 401 Unauthorized
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK38124;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=3E3FC57046A89E0F
        Call-ID: [email protected]
        CSeq: 1 INVITE
        WWW-Authenticate: Digest realm="fritz.box", nonce="B65E82B548752137"
        User-Agent: FRITZ!OS
        Content-Length: 0

16:59:12.280672 IP (tos 0x68, ttl 63, id 45623, offset 0, flags [none], proto UDP (17), length 428)
    192.168.1.2.5060 > 192.168.2.203.47831: SIP, length: 400
        SIP/2.0 401 Unauthorized
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK38124;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=3E3FC57046A89E0F
        Call-ID: [email protected]
        CSeq: 1 INVITE
        WWW-Authenticate: Digest realm="fritz.box", nonce="B65E82B548752137"
        User-Agent: FRITZ!OS
        Content-Length: 0

16:59:12.285318 IP (tos 0x0, ttl 64, id 31443, offset 0, flags [none], proto UDP (17), length 394)
    192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 366
        ACK sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK38124
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=3E3FC57046A89E0F
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 1 ACK
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:12.285397 IP (tos 0x0, ttl 63, id 31443, offset 0, flags [none], proto UDP (17), length 394)
    192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 366
        ACK sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK38124
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=3E3FC57046A89E0F
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 1 ACK
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:12.287511 IP (tos 0x0, ttl 64, id 31444, offset 0, flags [none], proto UDP (17), length 961)
    192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 933
        INVITE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK81346
        Max-Forwards: 70
        To: <sip:[email protected]>
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Min-SE: 90
        Session-Expires: 600;refresher=uas
        Authorization: Digest username="Mi_A1-lbP864Us", realm="fritz.box", nonce="B65E82B548752137", uri="sip:[email protected]", response="c20ccc0fc64ffea65ed84e6436f8c50a"
        Content-Length: 261
        Content-Type: application/sdp

        v=0
        [email protected] 0 0 IN IP4 192.168.2.203
        s=Session SIP/SDP
        c=IN IP4 192.168.2.203
        t=0 0
        m=audio 21000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
16:59:12.287547 IP (tos 0x0, ttl 63, id 31444, offset 0, flags [none], proto UDP (17), length 961)
    192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 933
        INVITE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK81346
        Max-Forwards: 70
        To: <sip:[email protected]>
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Min-SE: 90
        Session-Expires: 600;refresher=uas
        Authorization: Digest username="Mi_A1-lbP864Us", realm="fritz.box", nonce="B65E82B548752137", uri="sip:[email protected]", response="c20ccc0fc64ffea65ed84e6436f8c50a"
        Content-Length: 261
        Content-Type: application/sdp

        v=0
        [email protected] 0 0 IN IP4 192.168.2.203
        s=Session SIP/SDP
        c=IN IP4 192.168.2.203
        t=0 0
        m=audio 21000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
16:59:12.309934 IP (tos 0x68, ttl 64, id 45626, offset 0, flags [none], proto UDP (17), length 365)
    192.168.1.2.5060 > 192.168.1.1.47831: SIP, length: 337
        SIP/2.0 100 Trying
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>
        Call-ID: [email protected]
        CSeq: 2 INVITE
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Content-Length: 0

16:59:12.309983 IP (tos 0x68, ttl 63, id 45626, offset 0, flags [none], proto UDP (17), length 365)
    192.168.1.2.5060 > 192.168.2.203.47831: SIP, length: 337
        SIP/2.0 100 Trying
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>
        Call-ID: [email protected]
        CSeq: 2 INVITE
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Content-Length: 0

16:59:12.354184 IP (tos 0x68, ttl 64, id 45628, offset 0, flags [none], proto UDP (17), length 760)
    192.168.1.2.5060 > 192.168.1.1.47831: SIP, length: 732
        SIP/2.0 183 Session Progress
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]>
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Content-Type: application/sdp
        Content-Length:   271

        v=0
        o=user 266168 266168 IN IP4 192.168.1.2
        s=Session SIP/SDP
        c=IN IP4 192.168.1.2
        t=0 0
        m=audio 50000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=sendrecv
        a=rtcp:50001
16:59:12.354233 IP (tos 0x68, ttl 63, id 45628, offset 0, flags [none], proto UDP (17), length 760)
    192.168.1.2.5060 > 192.168.2.203.47831: SIP, length: 732
        SIP/2.0 183 Session Progress
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]>
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Content-Type: application/sdp
        Content-Length:   271

        v=0
        o=user 266168 266168 IN IP4 192.168.1.2
        s=Session SIP/SDP
        c=IN IP4 192.168.1.2
        t=0 0
        m=audio 50000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=sendrecv
        a=rtcp:50001
16:59:16.929365 IP (tos 0x68, ttl 64, id 45747, offset 0, flags [none], proto UDP (17), length 1029)
    192.168.1.2.5060 > 192.168.1.1.47831: SIP, length: 1001
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]>
        Session-Expires: 600;refresher=uas
        Min-SE: 90
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Supported: 100rel,replaces,timer
        Allow-Events: telephone-event,refer
        Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
        Content-Type: application/sdp
        Accept: application/sdp, multipart/mixed
        Accept-Encoding: identity
        Content-Length:   271

        v=0
        o=user 266168 266168 IN IP4 192.168.1.2
        s=Session SIP/SDP
        c=IN IP4 192.168.1.2
        t=0 0
        m=audio 50000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=sendrecv
        a=rtcp:50001
16:59:16.929453 IP (tos 0x68, ttl 63, id 45747, offset 0, flags [none], proto UDP (17), length 1029)
    192.168.1.2.5060 > 192.168.2.203.47831: SIP, length: 1001
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK81346;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 2 INVITE
        Contact: <sip:[email protected]>
        Session-Expires: 600;refresher=uas
        Min-SE: 90
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Supported: 100rel,replaces,timer
        Allow-Events: telephone-event,refer
        Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
        Content-Type: application/sdp
        Accept: application/sdp, multipart/mixed
        Accept-Encoding: identity
        Content-Length:   271

        v=0
        o=user 266168 266168 IN IP4 192.168.1.2
        s=Session SIP/SDP
        c=IN IP4 192.168.1.2
        t=0 0
        m=audio 50000 RTP/AVP 9 8 0 101
        a=rtpmap:9 G722/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=sendrecv
        a=rtcp:50001
16:59:17.062771 IP (tos 0x0, ttl 64, id 31801, offset 0, flags [none], proto UDP (17), length 476)
    192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 448
        ACK sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK22483
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 2 ACK
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:17.062817 IP (tos 0x0, ttl 63, id 31801, offset 0, flags [none], proto UDP (17), length 476)
    192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 448
        ACK sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK22483
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 2 ACK
        Contact: <sip:[email protected]:47831>
        Expires: 300
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:42.267509 IP (tos 0x0, ttl 64, id 33579, offset 0, flags [none], proto UDP (17), length 411)
    192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 383
        BYE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK50053
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 3 BYE
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:42.267593 IP (tos 0x0, ttl 63, id 33579, offset 0, flags [none], proto UDP (17), length 411)
    192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 383
        BYE sip:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport;branch=z9hG4bK50053
        Max-Forwards: 70
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        Call-ID: [email protected]
        CSeq: 3 BYE
        Supported: timer
        User-Agent: FRITZApp/1.90.10/Mi A1
        Content-Length: 0

16:59:42.276766 IP (tos 0x68, ttl 64, id 45784, offset 0, flags [none], proto UDP (17), length 713)
    192.168.1.2.5060 > 192.168.1.1.47831: SIP, length: 685
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK50053;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 3 BYE
        X-RTP-Stat: CS=0;PS=2123;ES=1496;OS=194016;SP=0/0;SO=0;QS=-;PR=0;ER=1496;OR=0;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=0/0;EN=G722;DE=;JI=0,0;DL=0,0,0;IP=192.168.1.2:50000,192.168.2.203:21000
        X-RTP-Stat-Add: DQ=0;DSS=0;DS=0;PLCS=0;JS=0
        X-SIP-Stat: DRT=0;IR=0
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Supported: 100rel,replaces,timer
        Allow-Events: telephone-event,refer
        Content-Length: 0

16:59:42.276837 IP (tos 0x68, ttl 63, id 45784, offset 0, flags [none], proto UDP (17), length 713)
    192.168.1.2.5060 > 192.168.2.203.47831: SIP, length: 685
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 192.168.2.203:47831;rport=47831;branch=z9hG4bK50053;received=192.168.1.1
        From: <sip:[email protected]>;tag=z9hG4bK28775328
        To: <sip:[email protected]>;tag=973E785FE49F9C1D
        Call-ID: [email protected]
        CSeq: 3 BYE
        X-RTP-Stat: CS=0;PS=2123;ES=1496;OS=194016;SP=0/0;SO=0;QS=-;PR=0;ER=1496;OR=0;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=0/0;EN=G722;DE=;JI=0,0;DL=0,0,0;IP=192.168.1.2:50000,192.168.2.203:21000
        X-RTP-Stat-Add: DQ=0;DSS=0;DS=0;PLCS=0;JS=0
        X-SIP-Stat: DRT=0;IR=0
        User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
        Supported: 100rel,replaces,timer
        Allow-Events: telephone-event,refer
        Content-Length: 0
 
Moinsen


Für Ton ist RTP zuständig, und das geht über UDP.
Also zur FRITZ!Box offenhalten: 7077 bis 7110 UDP (IPv4/v6) Telefonie (RTP, RTCP)

Ach ja, IPv6, wenn du es vollständig machen willst nutze auch ip6tables
 
Ich vermute dieses log läßt einen Rückschluss auf das Problem zu, ich kann es aber nicht interpretieren. Eine Suche im Forum hat mit nicht wirklich weitergebracht.

Code:
SIP/2.0 401 Unauthorized
 
401 kommt immer beim ersten Versuch.
Dabei antwortet der Server mit einem NONCE, was der Klient beim zweiten Versuch richtig beantworten muss.
...erst dann ( richtige Antwort beim 2. Versuch ) kommt das OK vom Server.
...guck, wegen dem nonce, mal etwas genauer hin ;)
 
Richtig, 401 ist nichts Ungewöhnliches.
Kann als SIP Händeschütteln bezeichnet werden, bei einer Authorisation.
Wird gemacht bei...
1. Registration
2. Subskription ( BLF und MWI )
3. INVITE ( Anrufe ) ohne REGISTER wenn "Guest Calls" ( SIP URI Calls ) nicht erlaubt sind/werden
 
Zuletzt bearbeitet:
Interessant ist, daß ich mit der FritzFon App intern mein DECT Telefon erreiche (ohne Audio), aber vom DECT Telefon erreiche ich das Handy mit der FritzFon App nicht. Es kommt kein Klingelzeichen, TCPDUMP macht keinen Mucks.

:rolleyes:
 
Für Ton ist RTP zuständig, und das geht über UDP.
Also zur FRITZ!Box offenhalten: 7077 bis 7110 UDP (IPv4/v6) Telefonie (RTP, RTCP)

Ich hab folgendes ausprobiert:
Code:
iptables -A FORWARD -i enp0s10 -p udp --dport 7078:7109 -j ACCEPT
iptables -t nat -A PREROUTING -i enp0s10 -p udp --dport 7078:7109 -j DNAT --to 192.168.1.2

iptables -A PREROUTING -t nat -i enp0s10 -p udp --dport 5060 -j DNAT --to 192.168.1.2:5060
iptables -A FORWARD -p udp -i enp0s10  -d 192.168.1.2 --dport 5060 -j ACCEPT

klappt leider auch nicht :oops:
 
klappt leider auch nicht :oops:

danach ist mein iptable

Code:
root@ion:/etc# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpts:7078:7109
ACCEPT     udp  --  anywhere             gateway              udp dpt:sip

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
FRITZ!Box SIP ist 5060 TCP/UDP - Vielleicht nutzt die App TCP?
 
  • Like
Reaktionen: MB2020
Stimmt, lt Herstellerangabe sollte man auch tcp freigeben

Code:
 iptables -A PREROUTING -t nat -i enp0s10 -p tcp --dport 5060 -j DNAT --to 192.168.1.2:5060
 iptables -A FORWARD -p tcp -i enp0s10  -d 192.168.1.2 --dport 5060 -j ACCEPT

Code:
root@ion:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate NEW
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             udp dpts:7078:7109
ACCEPT     udp  --  anywhere             gateway              udp dpt:sip
ACCEPT     tcp  --  anywhere             gateway              tcp dpt:sip

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

will aber immer noch nicht:rolleyes:
 
Und jetzt das Ganze nochmal mit: ip6tables

Code:
Das hier: 192.168.2.203.47831 > 192.168.1.2.5060: SIP, length: 758
...
Contact: <sip:[email protected]:47831>
...sieht nach VPN ( reines IPv4 ) aus, während...
Code:
192.168.1.1.47831 > 192.168.1.2.5060: SIP, length: 758
...mit...
Code:
Contact: <sip:[email protected]:47831>
...nicht plausibel ist.

Also, vom *.2.*er ins *.1.*er und wieder zurück, das dürfte deine Probleme plausibilieren, grenzt an Kausalität, sozusagen.
Aber eine handfeste Lösung kann ich dir dafür jetzt nicht präsentieren.
Rate mal ins Blaue: Eine Route zum *.2.*er im *.1.*er Netz setzen

Ach ja, Wie du siehst, hat der VPN Klient eine zufällige SIP Portnummer, die solltest du im Klienten natürlich auch fest auf 5060 nageln.
...falls das auch nötig sein sollte, musst du checken ;)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: MB2020
Danke, das sind zwei sehr valide Punkte, denen ich noch im Detail nachgehen muss. Ich habe auch schon vermutet, dass es was mit dem Gateway zu tun haben könnte - http Verkehr läuft aber übers Gateway.
Was ich gerade noch gefunden habe ist die folgende Nachricht in /var/log/messages:

Code:
 ion kernel: [  156.794540] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.

Vielleicht kann ich die iptables nochmal genauer loggen.
 
Kleiner Tipp von meiner Seite (ohne mich hier danach weiter einmischen zu wollen) ... in den SIP-Messages sieht man ja, daß keine richtige RTP-Verbindung zwischen den beiden Clients (7490 + Mi-Smartphone) aufgebaut wird:
X-RTP-Stat: CS=0;PS=2123;ES=1496;OS=194016;SP=0/0;SO=0;QS=-;PR=0;ER=1496;OR=0;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=0/0;EN=G722;DE=;JI=0,0;DL=0,0,0;IP=192.168.1.2:50000,192.168.2.203:21000
PS (Packets sent) ist zwar aus Sicht der Box > 0, aber PR (Packets received) zeigt, daß nicht ein einziges RTP-Paket hier empfangen wurde.

Ich würde mal darauf tippen (mehr ist's erst einmal nicht, solange man da nicht einfach mal mit den richtigen Tools - u.a. "conntrack" - die wichtigen Infos sammelt und hier "vorzeigt"), daß der SIP-Helper für das Connection-Tracking die notwendigen zusätzlichen Einträge nicht einrichtet, weil er gar nicht den gesamten SIP-Dialog zu Gesicht bekommt. Denn die kommen wohl nur bei ihm vorbei, wenn sie als "destination port" auch UDP 5060 verwenden. Das ist hier bei den "Antworten" der 7490 ganz offensichtlich ja nicht der Fall (die Replies der 7490 gehen an den Port 47831) und so wird der CT-Helper für SIP hier das "Session Progress"-Paket wohl gar nicht auswerten können und damit auch nicht die passende (ausgehende) Verbindung zwischen 192.168.2.203:21000 und 192.168.1.2:50000 (und natürlich auch eine zweite für RTCP, falls erforderlich) einrichten.

Da die FRITZ!Box ja ihrerseits für die RTP-Verbindung einen Absender 192.168.2.203 erwartet (so steht die Gegenstelle im SDP-Inhalt der SIP-Messages), müßte sie den Verbindungsversuch von 192.168.1.1 (nach dem Masquerading für das Interface "enp0s10") ignorieren - auch wenn die "ausgehende Verbindung" von "wlp2s0" natürlich "automatisch" funktioniert dank der vorhandenen Regeln.

Entweder die SDP-Descriptions werden passend modifiziert (so daß die FRITZ!Box die Verbindung auch von 192.168.1.1 "erwartet") oder man sorgt dafür, daß für diese Pakete eben kein Masquerading erfolgt und damit auch bei der 7490 als Absenderadresse die 192.168.2.203 sichtbar wird - diese direkte Verbindung (ohne Masquerading) sollte das SIP-ALG einrichten (ich habe aber nicht in die "netfilter"-Sources gesehen, wann/ob das erfolgt, wie ich es erwarte).

Die ganzen Kunststückchen mit "iptables" in den Beiträgen #10 und #13 verstehe ich aber auch nicht ... immerhin ist "enp0s10" ganz offensichtlich das Interface, welches die IP-Adresse 192.168.1.1 hat - was bringt dann eine DNAT(!)-Regel (also das Ändern der Zieladresse(!) auf 192.168.1.2), die auf Pakete anzuwenden ist, die auf diesem Interface ankommen (-i enp0s10)? Hier würde für mich (in Richtung auf 192.168.2.0/24) max. noch ein SNAT einen Sinn ergeben, wobei auch das eher fragwürdig wäre.

Das alles unter Vorbehalt und nur mal so ins Blaue gedacht von mir ... ich würde hier also weniger selektiv vorgehen bei der Verzweigung zum CT-Helper und mind. einen zweiten Eintrag anlegen, der UDP-Pakete von "enp0s10" (oder sogar mit der Absenderadresse der 7490) mit Absenderport 5060 auch an/über das SIP-ALG sendet. Wenn man dann tatsächlich noch SIP over TCP abdecken will, braucht's zwei weitere Einträge.

Wenn dann die notwendigen Pakete auch beim CT-Helper für SIP vorbeikommen, kann man (a) noch einmal einen Dump für die SIP-Pakete machen (aber sinnvollerweise auch nach Interfaces getrennt, denn in #3 muß man auch "erahnen", auf welchem Interface da welche Pakete eingehen und gesendet werden) und (b) nach dem Aufbau der SIP-Session zumindest mal mit "conntrack" nachsehen, welche Verbindungen vom Helper eingerichtet wurden, wenn - nach dem SIP-Dialog zu urteilen - die Verbindung steht.

Wenn man dann noch (c) auch die verwendeten RTP-Ports überwacht (man kann so ein "tcpdump" ja auch erst einmal in eine Datei ausgeben lassen und man kann das sogar als Background-Job ausführen - dann am besten auch die richtigen Ports nehmen, weil 7078+32 die von der Box als SIP-UA (also als Client) verwendeten sind), sieht man auch gleich noch, ob die RTP-Pakete tatsächlich "durchgehen" oder ob (bzw. sogar wie) sie vom Router modifiziert werden.
 
Vielen herzlichen Dank für PeterPawn, koyaanisqatsi und insti für die sehr guten Hinweise. Ich habe einen Teilerfolg: Ich kann vom Handy zum Mobilteil telefonieren und habe Ton auf beiden Seiten. Was noch fehlt ist Mobilteil zum Handy - da bekomme ich einen Klingelton.

Folgendes war das Problem: die /etc/iptables.up.rules waren korrupt - seltsam, da ich sie nicht editiere und durch Webmin erstellt wurden. Es fehlte ein COMMIT beim raw (!) und

Code:
-A OUTPUT -p udp -m udp --dport 5060 -j CT --helper sip

Mittels

Code:
iptables -A FORWARD -p udp -d 192.168.1.2 --dport 5060 -j ACCEPT
iptables -A FORWARD -p tcp -i enp0s10 -d 192.168.1.2 --dport 5060 -j ACCEPT

kann ich vom Handy zum Mobilteil anrufen und habe Ton. Fehlt noch der Rückweg.

Gruss
 
Also zurück vom *.1.*er ins *.2.*er Netz?
 
  • Like
Reaktionen: MB2020
Ich habe es gerade nochmals getestet, es klappt volltändig!

Herzlichen Dank insbesondere an koyaanisqatsi!
 
iptables -A FORWARD -p tcp -i enp0s10 -d 192.168.1.2 --dport 5060 -j ACCEPT
Ich verstehe diesen Eintrag aber immer noch nicht ... da werden also alle TCP-Pakete für das Routing (und nur darum geht's bei "FORWARD") akzeptiert, die auf dem Interface enp0s10 (das selbst die IP-Adresse 192.168.1.1/24 verwendet) ankommen und für Adresse/Port 192.168.1.2:5060 bestimmt sind? Wenn da nicht noch irgendetwas anderes und hier bisher unbekanntes konfiguriert ist, sollte der Paketzähler für diese Regel stur auf 0 stehen bleiben, weil es solche Pakete gar nicht geben dürfte. Denn das "-i" heißt bei "iptables" nun mal nicht "--interface" oder ähnliches ... es steht für "--in-interface" (-o bzw. --out-interface wäre das Pendant dazu) und das kann eigentlich nicht "enp0s10" sein, weil alle Clients im Netz 192.168.1.0/24 direkt an die 192.168.1.2 senden würden. Das ist auch der Unterschied zur UDP-Regel darüber - da wurde kein Interface angegeben und so wirkt diese Regel auch für Pakete, die auf dem Interface "wlp2s0" ankommen und an das Interface "enp0s10" gehen sollen.

Auch die Regel:
-A OUTPUT -p udp -m udp --dport 5060 -j CT --helper sip
ist (für mich zumindest) kaum nachvollziehbar ... die OUTPUT-Chain behandelt die Pakete, die auf dem lokalen System erzeugt wurden (jedenfalls nach allem, was ich dazu weiß) und würde für mich max. dann einen Sinn ergeben, wenn auf dem (Debian-)Router selbst irgendjemand SIP verwenden sollte.

==============================================================

Noch ein Tipp zum "iptables" - der Inhalt der Datei mit den "geplanten Einträgen" (/etc/iptables.up.rules) ist zwar schön und gut ... aber er zeigt natürlich nicht, was am Ende tatsächlich aktiv ist (auch und vor allem, wenn man weitere Einträge hinzufügt mit eigenen Kommandos). Dafür dient üblicherweise ein "iptables-save" (das generiert aus den aktiven Einträgen eine Datei, mit der man diese wiederherstellen könnte) und wenn man sein Regelwerk überprüfen will, sollte man auch immer einen Blick auf die Paketzähler werfen, denn nur dann kann man sich sicher sein, daß eine Regel auch tatsächlich zum Zuge kommt. Das geht (für alle vier Tabellen bei "netfilter") am besten mit etwas wie: for t in filter nat mangle raw; do iptables -t $t -L -v; done ... da bei diesen Einträgen ja auch die Reihenfolge eine entscheidende Rolle spielt (die werden "von oben nach unten" abgearbeitet), kann ein "jump" (-j) in einer vorhergehenden Regel auch ganz schnell dazu führen, daß eine später eingetragene Regel rein gar nichts bewirkt.

Wenn so ein Router mit "netfilter" dann eine Firewall für irgendwelche "internen" Netze bilden soll, ist es auch nicht wirklich ungefährlich, wenn man einfach irgendwo weitere Regeln hinzufügt. Ich bin z.B. einigermaßen ratlos, was:
vom *.1.*er ins *.2.*er Netz
am Ende heißen soll ... denn die Kombination aus:
Code:
-A FORWARD -m conntrack -i wlp2s0 -o enp0s10 -j ACCEPT  --ctstate NEW
-A FORWARD -m conntrack -j ACCEPT  --ctstate RELATED,ESTABLISHED
-t nat -A POSTROUTING -o enp0s10 -j MASQUERADE
-t nat -A POSTROUTING -o ppp0 -j MASQUERADE
würde man ja eher für eine solche Firewall (mit "wlp2s0" als internem Netz und "enp0s10" als extern, wo die Clients aus "wlp2s0" auf die Adresse des Router an "enp0s10" gemappt werden) verwenden und da wäre irgendeine Regel, die ein direktes Routing von 192.168.1.0/24 nach 192.168.2.0/24 zuläßt, ja der Tod jedes Schutzes. Andererseits ist für alle Chains (nach #3) der Standard ja ein "ACCEPT" und es ist auch nirgendwo etwas zu sehen, daß da eine letzte Regel in einer Chain dann auf ein "REJECT" oder "DROP" gehen würde. Damit ist das eigentlich gar keine Firewall-Konfiguration ... für einen Router ist das dann höchst ungewöhnlich (zumindest bei einem NAT-Router), aber sicherlich trotzdem "denkbar".

Aber wenn hier spätere Leser auf Basis der gezeigten Regeln an der eigenen Firewall herumschrauben wollen, sollten sie sich das noch einmal gründlich überlegen - für mich ist hier einiges in der Konfiguration dieses Debian-Routers zumindest "unklar", wenn nicht gar falsch (was man aufgrund mangelnder Infos zum Verwendungszweck aber nur vermuten kann).
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.