Höre Angerufenen nicht

[aberhallo]

Hi,

wenn ich über SIP (GMX) rausrufe läutet es und das fli4l zeigt etwa 10kB/s Up- und Downtraffic - OK.

Wenn der Angerufene abhebt hört er mich aber er mich nicht. Der Uptraffic hat immer noch 10KB/s der Downtraffic aber 0KB/s.

- die 'externip' stimmt.
- Portweiterleitung 5060, 5070, 5072, 3478, 10000-20000 (RTP), 30000-30019 UDP ist eingestellt zusätzlich 10000-20000 TCP

Kann mir jemand einen Tipp geben?

Viele Grüße!
Konrad

 

[britzelfix]

Hi aberhallo!

Sieht danach aus, daß die Firewall noch die
Pakete blockiert.

Bei der Port-Weiterung muß man auch zwischen
sport/dport unterscheiden.

D.H. wenn Dich jemand anruft, connectet er über
Deinen Port 5060, wenn Du jemanden anrufst, dann
connectest Du seinen Port 5060. Das gilt auch für
andere Ports.

Kurzgesagt: für jede PORTFW_x_SOURCE muß auch
eine PORTFW_x_TARGET existieren.

Gruß
britzelfix

 

[aberhallo]

Hi britzlfix,

hm, verstehe ich nicht. Ist wohl bei UDP anders als bei TCP.

Wenn mein Target so ausschaut
PORTFW_1_TARGET='5060'
PORTFW_1_NEW_='192.168.88.88'
PORTFW_1_PROTOCOL='udp'
wie schaut dann die Source aus?

Hast Du eine Ahnung, welche Ports/Protokolle ich wirklich brauche?

Viele Grüße!
aberhallo

 

[betateilchen]

das ist nur der Port für die SIP-Signalisierung, also für den Verbindungsaufbau. Du solltest auch den RTP-Port weiterleiten, über den die Sprachübertragung läuft.

 

[ploieel]

@ aberhallo:
schau bitte mal diesen Thread, da kannst du den Anfang machen,damit es läuft. Hinterher kannst du dann wieder abhängig vom jeweiligen Provider nicht benötigte Ports sperren:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=13143&highlight=

@betateilchen:
Deine Signatur ist spitzenmäßig, besonders die zwei roten Zeilen am Ende. Sie zeigen mir deutlich, wie borniert und überheblich dieses politische System heute ist. Es wird Zeit, dass es hinweggefegt und durch ein neues besseres ersetzt wird. Reformen werden da nicht mehr viel bringen...

 

[aberhallo]

das ist nur der Port für die SIP-Signalisierung, also für den Verbindungsaufbau. Du solltest auch den RTP-Port weiterleiten, über den die Sprachübertragung läuft.

.. ist klar ich habe folgende Ports weitergeleitet:
5060, 5070, 5072, 3478, 10000-20000 (RTP), 30000-30019 UDP+TCP
Aber nur mit PORTFW_X_TARGET.

Meine Frage zielt auf PORTFW_X_SOURCE, weil ich das nicht verstehe und nicht anwenden kann.

Gruß
aberhallo

 

[betateilchen]

@ploieel diese Gerichtsentscheidung ist von heute ... traurig aber wahr. (Ok - offtopic)

 

[ploieel]

@aberhallo:
versuche doch bitte mal, die target- und source-Zeilen auszukommentieren und stattdessen einfach die new-style-packet filter-config-Zeilen einzufügen. dann den Fli neu starten und VoIP probieren.

@betateilchen:
O.T. aber trotzdem: nicht nur traurig, beschämend ist das! Derartige Entscheidungen treffen hochbezahlte Beamte, Staatsanwälte und Richter. Aus Steuermitteln bezahlte Leute sind das, die bezahlst Du und ich und alle anderen Steuerzahler mit! Wieviel derartigen Käse wollen wir uns eigentlich noch gefallen lassen?

 

[aberhallo]

Wichtige Ergänzung zu meiner Frage:
der Router ist ein fli4l 2.1.9p6
asterisk läuft auf einer anderen Maschine eisfair 1.1.1, asterisk-Paket 0.0.9

Gruß aberhallo

 

[britzelfix]

@ploieel wie geht den new-style-packet ?

@bt
sorry offtopic, aber
wie ist das gemeint:

Doppelbett && gemeinsame Nutzung des Bades
oder
Doppelbett || gemeinsame Nutzung des Bades

Im ersten Fall kann man doch zwei einzelne Betten aufstellen, oder?

Gruß
britzelfix

 

[ploieel]

@britzelfix:
ich habe einfach ganz cool ein new-style-paket-filter von Netview übernommen, was in dem o. g. Thread enthalten ist; ich poste es hier nochmal:

#------------------------------------------------------------------------------
# new style packet filter config
#------------------------------------------------------------------------------
NEW_FW_CONFIG='yes' # use new style packet filter config
INPUT_POLICY='REJECT' # be nice and use reject as policy
INPUT_ACCEPT_DEF='no' # use default rule set
INPUT_LOG='yes' # log anything
INPUT_LIST_N='5'
INPUT_LIST_1='state:ESTABLISHED,RELATED ACCEPT' # drop ping
INPUT_LIST_2='if:lo:any ACCEPT' # allow local communication
INPUT_LIST_3='prot:udp 5060 ACCEPT NOLOG' # allow sip -> asterisk
INPUT_LIST_4='prot:udp 10000-20000 ACCEPT NOLOG' # allow rtp -> asterisk
INPUT_LIST_5='IP_NET_1 ACCEPT' # allow all hosts in the local
FORWARD_POLICY='REJECT' # be nice and use reject as policy
FORWARD_ACCEPT_DEF='yes' # use default rule set
FORWARD_LOG='no' # don't log anything
FORWARD_LIST_N='2'
FORWARD_LIST_1='tmpl:samba DROP' # drop samba traffic if it tries
# to leave the subnet
FORWARD_LIST_2='IP_NET_1 ACCEPT' # accept everything else

POSTROUTING_LIST_N='1'
POSTROUTING_LIST_1='IP_NET_1 MASQUERADE' # masquerade traffic leaving
# the subnet

Das ist für die base.txt von fli4l 2.1.9p6, bei mir hat es bis jetzt problemlos funktioniert. Gut, es werden eine große Anzahl ports geöffnet, aber doch nur für das Protokoll, was für VoIP benötigt wird, und das auch nur für Asterisk. Wenn Ihr hier Sicherheitslücken vermutet oder solche bereits erkennt, bitte lasst es mich wissen.


@all: ich weiß, dass bt eigentlich seine Signatur dazu gemacht hat, dass man darüber schmunzeln sollte. Ich sehe die Sache vielleicht auch ein wenig zu verbissen... sorry.

Grüße
Günter

 

[ploieel]

Nachtrag:
die portrange für VoIP muss dann natürlich auch Asterisk in der rtp.conf bekannt gemacht werden.

 

[aberhallo]

@ploieel

so wie ich das sehe hast Du asterisk auf den fli4l laufen.
Dann hast Du natürlich keinen Bedarf an Portweitetleitung.

@britzelfix

kannst Du mir das noch mal genauer erklären mit den PORTFW_x_SOURCE?

 

[ploieel]

PORTFW_x_SOURCE --> source = ip-Adresse Fli4l:Quellport bzw. Quellportrange
target = ip-Adresse Deines Asterisk:zielport bzw. zielportrange (10000-2000)

z B.

PORTFW_N='5'                          # how many portforwardings to set up
PORTFW_1_TARGET='8080'                # sample 1: forward ext. port 8080
PORTFW_1_NEW_TARGET='192.168.xxx.yyy:80' # ...to int. host 192.168.6.15 port 80
PORTFW_1_PROTOCOL='tcp'               # ...using tcp
PORTFW_2_TARGET='3000-3010'           # sample 2: forward portrange 3000-3010
PORTFW_2_NEW_TARGET='192.168.xxx.yyy'    # ...to int. host 192.168.6.15
PORTFW_2_PROTOCOL='tcp'               # ...using tcp

PORTFW_3_TARGET='20'                # sample 1: forward ext. port 20
PORTFW_3_NEW_TARGET='192.168.xxx.yyy:20' # ...to int. host 192.168.6.15 port 20
PORTFW_3_PROTOCOL='tcp'               # ...using tcp

PORTFW_4_TARGET='21'                # sample 1: forward ext. port 21
PORTFW_4_NEW_TARGET='192.168.yyy.yyy:21' # ...to int. host 192.168.6.15 port 21
PORTFW_4_PROTOCOL='tcp'               # ...using tcp

PORTFW_5_TARGET='119'                # sample 1: forward ext. port 119
PORTFW_5_NEW_TARGET='192.168.xxx.yyy:119' # ...to int. host 192.168.6.15 port 119
PORTFW_5_PROTOCOL='tcp'               # ...using tcp

 

[britzelfix]

hmm,
ich habe da etwas anderes gesehen, nämlich
PORTFW_1_SOURCE='10000-20000'

Allerdings bin ich mir ziemlich sicher, daß die
Firewall die Ports nicht durchlässt.

@aberhallo, kannst Du bitte testweise mal die Firewall
öffnen und es noch mal so versuchen:

INPUT_POLICY='ACCEPT'
OUTPUT_POLICY='ACCEPT'
FORWARD_POLICY='ACCEPT'

Dann kann man sehen ob die Firewall daran schuld ist.

Gruß
britzelfix

BTW: Bei den Doppelbetten habe ich mich etwas verlesen. Jedenfalls
hat Stadt Mönchengladbach gegen das Urteil Einspruch eingelegt.

 

[ploieel]

Britzelfix hat jetzt absolut den Vortritt hier, ich habe mich da etwas verrannt.

btw. Na dann ist die Stadt Mönchengladbach, soweit sie durchkommt, wenigstens in dieser Hinsicht kinderfreundlich. ;-)

 

[aberhallo]

mit
INPUT_POLICY='ACCEPT' und FORWARD_POLICY='ACCEPT' und POSTROUTING_LIST_1='IP_NET_1 MASQUERADE'
gleicher Effekt .

OUTPUT_POLICY='ACCEPT' ging nicht (NEW_STYLE)

Gruß aberhallo

 

[britzelfix]

hmm, kannst Du bitte mal die rules.log posten mit:
cd /tmp; iptables -L -n -v|tee rules.log

I Moment fällt mir auch nicht mehr ein.

@ploieel
wie soll ich das verstehen ?

 

[britzelfix]

Ich habe hier noch einen interessanten Artikel zu
dem Thema gelesen, er könnte etwas zum
Verständniss beitragen.

http://www.ip-phone-forum.de/spip/article.php3?id_article=12

Gruß
britzelfix