[Gelöst] [Gelöst] OpenVPN on 7330. Wrong routing

[stefanoIT]

Hello.
I used freetz to create a new firmware with OpenVPN for my 7330 to connect the FB to a PBX using VPN.
I configured OpenVPN in client mode and it works properly.
From FB I can ping the PBX.
The weird thing is that SIP packet do not go through the tun0 interface but they go through the dsl interface.
I suppose there is some kind of policy routing in it.
How can I fix this?

Thanks

Routing

root@fritz:/var/mod/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.4.5     0.0.0.0         255.255.255.255 UH    2      0        0 dsl
194.243.192.5   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.4.0     0.0.0.0         255.255.255.0   U     2      0        0 dsl
194.243.192.0   194.243.192.5   255.255.255.0   UG    0      0        0 tun0
192.168.189.0   0.0.0.0         255.255.255.0   U     0      0        0 guest
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

root@fritz:/var/mod/root# ip route list
192.168.180.1 dev dsl  metric 2
192.168.180.2 dev dsl  metric 2
192.168.4.5 dev dsl  metric 2
194.243.192.5 dev tun0  src 194.243.192.6
192.168.178.0/24 dev lan  src 192.168.178.1
192.168.4.0/24 dev dsl  metric 2
194.243.192.0/24 via 194.243.192.5 dev tun0
192.168.189.0/24 dev guest  src 192.168.189.1
169.254.0.0/16 dev lan  src 169.254.1.1
default dev dsl  metric 2

Ping

root@fritz:/var/mod/root# ping 194.243.192.1
PING 194.243.192.1 (194.243.192.1): 56 data bytes
64 bytes from 194.243.192.1: seq=0 ttl=64 time=43.583 ms
64 bytes from 194.243.192.1: seq=1 ttl=64 time=44.194 ms

But SIP goes to eth0

root@fritz:/var/mod/root# tcpdump -i eth0 host 194.243.192.1
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:37:46.050233 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:37:47.050306 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:37:49.050361 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:37:53.050485 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:37:57.050576 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:38:01.050916 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:38:05.051254 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:38:09.051307 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660
17:38:13.051409 IP 192.168.4.59.55060 > 194.243.192.1.sip: SIP, length: 660

The ping is OK

root@fritz:/var/mod/root# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
17:43:55.244040 IP 194.243.192.1 > 194.243.192.6: ICMP echo request, id 18652, seq 1, length 64
17:43:55.244187 IP 194.243.192.6 > 194.243.192.1: ICMP echo reply, id 18652, seq 1, length 64
17:43:56.245339 IP 194.243.192.1 > 194.243.192.6: ICMP echo request, id 18652, seq 2, length 64
17:43:56.245504 IP 194.243.192.6 > 194.243.192.1: ICMP echo reply, id 18652, seq 2, length 64
17:43:57.246371 IP 194.243.192.1 > 194.243.192.6: ICMP echo request, id 18652, seq 3, length 64
17:43:57.246480 IP 194.243.192.6 > 194.243.192.1: ICMP echo reply, id 18652, seq 3, length 64
17:43:58.246271 IP 194.243.192.1 > 194.243.192.6: ICMP echo request, id 18652, seq 4, length 64
17:43:58.246380 IP 194.243.192.6 > 194.243.192.1: ICMP echo reply, id 18652, seq 4, length 64

 

[PeterPawn]

I'm a little bit confused ... why do you think, eth0 is your DSL interface? I don't own a 7330 myself, but usually the eth0 interface is only the physical interface for one (or all - on some devices) ethernet switch port(s), while the "dev lan" interface is a brigde combining the ethernet switch ports with the WLAN port.

I would assume, your 'tun0' interface is a member of the 'lan' bridge ('brctl show' should reveal this) and therefore it's the expected behaviour, that the traffic to 194.something is visible on 'eth0' too, while it's sent to 'tun0' for encryption.

Running the 'tcpdump' utility for 'tun0' should show the SIP packets too ... don't they arrive on the remote site? Your routing table looks fine for this purpose ...

 

[MaxMuster]

As far as I remember this "strange" behaviour is part of the voip daemon, so there seems no simple workaround (also see here [in german]). You might try to force the outgoing interface with iptables?!?

EDIT The linked thread was about the voip server inside the FritzBox.
But I am quite sure I remember other threads about this "problem".

EDIT 2:My memory was not that bad ;-) , it was in that tread, but later, e.g. in #57 and the following posts.

 

[stefanoIT]

@PeterPawn my internet connection is throught LAN1

I read the thread. There is no a solution at this moment. That's shame.

 

[PeterPawn]

my internet connection is throught LAN1

Because I still got no 7330 until now (not even a single donation offer :-(), I'm able have a deaper look only into the 7390 model.

root@FB7390:/# brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.bc0543cafebe       no              [COLOR="#FF0000"]eth0[/COLOR]
guest           8000.bc0543cafebe       no              ethgbr3
root@FB7390:/# showdsldstat
time: 2015-01-16 20:23:14
0: sync_ata: ATA (showtime)
 manual       32000000    2000000  32.00Mbit/s   2.00Mbit/s
 maxspeed     32000000    2000000  32.00Mbit/s   2.00Mbit/s
 actual            240          0     240bit/s       0bit/s
                                         0.00%           0
cpmacconfig:special
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled

0: name internet
0: sync_group: sync_ata
0: iface wan RBE/14/dsl bc:05:43:ca:fe:be stay online 1 (prop: default internet) (prop6: default internet)
0: IPv6: automatic (ra)
0: IPv6: connected since 2015-01-15 02:52:47 (setup time 362648 secs) (connect cnt 1)
0: IPv6: no address
0: IPv6: no prefix (0)
0: IPv6: mtu 1500
0: IPv6: dns fd00::3631:c4ff:feca:feab valid 0 (ra)
0: IPv4: native
0: IPv4: connected since 2015-01-10 22:08:51 (setup time 12 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.nnn.7 mask 255.255.255.240 gw 192.168.nnn.1 dhcp mtu 1500
0: IPv4: masqaddr 192.168.nnn.7
0: IPv4: dns 192.168.nnn.2
0: IPv4: ntp 192.168.mmm.254
0: route 192.168.nnn.0/28 protocol iface
0: route 192.168.nnn.2/32 protocol dns
0: RX bytes:18145140 pkt error:0 discard:0 filtered:0 dropped:68468
0: RX pkts:71351 unicast:1203 multicast:50692 broadcast:19456
0: TX bytes:270384 pkt error:0 discard:0 filtered:0 dropped:9
0: TX pkts:1751 unicast:942 multicast:160 broadcast:649
root@FB7390:/#

This box is configured for LAN1 mode and connected to a 6490 as border router.

As you can see, the eth0 interface is still a member of the lan bridge. The interfaces are simply reconfigured in case of mode switching. Are you sure, that's not the same procedure for your router, only because it uses another CPU and chipset? Why won't you try to find it out with a single "brctl show" command?

Such a reconfiguration makes sense, because every little piece of code could be sure, that eth0 is always a local cable-based interface (bridged to lan as needed and therefore a good sink for local area traffic) and on the other hand, the dsl interface is always the current wan connection (it doesn't even matter, if the device does not contain a DSL modem at all like the LTE or DOCSIS models ... for FRITZ!OS it's always "dev dsl", where the threats come from) as long as the device is running in router mode. I'm really sure, the default gateway on a 7330 router in "LAN1 routing mode" points to "dev dsl" too.

If it's set to "IP client mode", the whole routing part is unused and it doesn't matter anymore, where the good (LAN) and the evil (WAN) part of the network may be found.

Due to such reconfiguration techniques, there's no need anymore to check an interface name first ...
(Better: Usally there's no need, but it could be abused for threats too, if somebody is able to change the interface names with success ... then it could be a nightmare.)
And - as far as it may be proved by searching for strings in binary files - some closed source components (ddnsd for example) rely on the eth0 name. There's a single "eth0" string within, but no (single) "lan" occurence. That's not a sufficient proof ... but an important clue.

Please don't mix up the eth0 network interface name with other settings. The command "ctlmgr_ctl r eth0 settings/mode" returns the mode of the wan interface indeed ... but this "eth0 thing" has nothing in common with the eth0 network interface. It's only a settings name and a leftover from earlier versions.

I'm not sure, how your device works and I did not read the the linked thread from #3 so far ... but if your 'tun0' interface is bridged to 'lan' and 'eth0' is there a member too, it's hardly surprising if the SIP traffic is visible on 'eth0'. It's only my (justified) opinion and it would be up to you now to refute it with the output from your device.

I'm not skeptical you're having trouble ... but I doubt whether it can be proven by watching traffic on 'eth0'.

 

[stefanoIT]

Command brctl show is not working on my FB.
Firmware version il 6.20

root@fritz:/var/flash# showdsldstat
time: 2015-01-16 22:50:16
0: sync_ata: ATA (showtime)
 manual       32000000    2000000  32.00Mbit/s   2.00Mbit/s
 maxspeed     32000000    2000000  32.00Mbit/s   2.00Mbit/s
 actual           3024       1736   3.02Kbit/s   1.74Kbit/s
                                         0.01%        0.09%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled

0: name internet
0: sync_group: sync_ata
0: iface eth0 RBE/14/dsl bc:05:43:fa:d6:3d stay online 1 (voip) (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2015-01-16 13:38:23 (setup time 2 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.4.59 mask 255.255.255.0 gw 192.168.4.5 dhcp mtu 1500
0: IPv4: masqaddr 192.168.4.59
0: IPv4: dns 192.168.4.5
0: IPv4: ntp 192.168.4.5
0: route 192.168.4.0/24 protocol iface
0: route 192.168.4.5/32 protocol dns
0: mc from wan 192.168.10.1
0: mc from wan 192.168.178.1
0: mc from wan 192.168.4.5
0: mc to wan 239.192.152.143 (unknown)
0: RX bytes:549365629 pkt error:0 discard:0 filtered:0 dropped:10068
0: RX pkts:9073884 unicast:12063 multicast:9053032 broadcast:8789
0: TX bytes:4738573 pkt error:0 discard:0 filtered:0 dropped:0
0: TX pkts:14051 unicast:13176 multicast:781 broadcast:94

root@fritz:/var/flash# ifconfig
adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.178.1  P-t-P:192.168.178.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:16594 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12338 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2568427 (2.4 MiB)  TX bytes:4486017 (4.2 MiB)

eth0      Link encap:Ethernet  HWaddr BC:05:43:FA:D6:3A
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:9075021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9048637 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:422522768 (402.9 MiB)  TX bytes:583035993 (556.0 MiB)

eth1      Link encap:Ethernet  HWaddr BC:05:43:FA:D6:3B
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:9069747 errors:0 dropped:1 overruns:0 frame:0
          TX packets:9046458 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:420299174 (400.8 MiB)  TX bytes:586116863 (558.9 MiB)

guest     Link encap:Ethernet  HWaddr BC:05:43:FA:D6:3A
          inet addr:192.168.189.1  Bcast:192.168.189.255  Mask:255.255.255.0
          inet6 addr: fe80::be05:43ff:fefa:d63a/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:368 (368.0 B)

lan       Link encap:Ethernet  HWaddr BC:05:43:FA:D6:3A
          inet addr:192.168.178.1  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::be05:43ff:fefa:d63a/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:9061458 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11957 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:419618102 (400.1 MiB)  TX bytes:7856815 (7.4 MiB)

lan:0     Link encap:Ethernet  HWaddr BC:05:43:FA:D6:3A
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5042 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5042 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:768606 (750.5 KiB)  TX bytes:768606 (750.5 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:194.243.192.6  P-t-P:194.243.192.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:147 errors:0 dropped:0 overruns:0 frame:0
          TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8398 (8.2 KiB)  TX bytes:9005 (8.7 KiB)

 

[PeterPawn]

it was in that tread, but later, e.g. in #57 and the following posts.

Did I miss an information?

If the voipd routing problem persists, how am I able to register one FRITZ!Box as SIP client to another one ? It's documented by AVM here ... but it's German only and I don't know, if an english version exists.

The problem reported 18 months ago seems to be solved ... at least to me.

And if the voipd is able to communicate with a SIP server via the lan bridge, why should it deny to talk with lan-side clients/servers behind an OpenVPN tunnel? Besides the different subnet address (which could be even another local subnet behind an additional routing gateway), there's no difference the voipd could use to judge about, if a subnet behind the lan interface is directly connected or via any VPN solution.

Command brctl show is not working on my FB.

May be your busybox binary is missing some applets. That's interesting, 'cause one configuration option for Freetz's OpenVPN GUI (v1 afaik) is built on top of the 'brctl' utility (something with "Bridge interface to LAN" - only analogous, I do not use the GUI to configure connections).

I think it's possible, that voipd sends internal SIP traffic immediately to "dev lan" and bypasses the "normal" routing (even if I don't understand, why he should do that), but if you really add tun0 to the bridge, the traffic should be visible on tun0 too and for each SIP packet arriving there from LAN (or CPU) side, there should be a corrensponding encrypted packet on "dev dsl". I've no idea, how you can detect bridge members without "brctl show" ... but in my opinion you have to check this first and - if I didn't miss it - you've not tried a packet dump on tun0 so far. We're (or I'm) able to provide some ideas or clues, but you've to run the necessary tests yourself. If you prefer to quit here, it's solely your own decision too.

If you want to continue, you've to provide details regarding your OpenVPN settings (the "bridge" option is not visible within the client configuration file, it's part of Freetz settings) and perhaps you need to build a new image with a better suited busybox too.

 

[MaxMuster]

If the voipd routing problem persists, how am I able to register one FRITZ!Box as SIP client to another one .

First: I don't own a box with the problem reported here, but there was at least another person reporting the same (I don't recall when so it might indeed be fixed).
But to answer your question: The Problem would only be present, if the voipd has to use an interface different to the "dsl" one, if the SIP-Server is "outside" his LAN.

The AVM-Guide states ("Voraussetzungen / Einschränkungen: [...]FRITZ!Box B muss die Betriebsart "Vorhandene Internetverbindung mitbenutzen (IP-Client-Modus) " eingerichtet sein. [...] Beide FRITZ!Boxen müssen sich im gleichen IP-Netzwerk befinden") in other words: NO dsld should be used. This might(!) indicate, voipd will do somethig special if dsld is used.

Its just a try for a possible cause, as I said...

 

[stefanoIT]

Here is my openvpn configuration. I use /dev/tun mode, so bridging should be not necessary.

root@fritz:/var/mod/root# cat /var/mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Sat Jan 17 09:53:34 CET 2015
proto tcp-client
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote ***
nobind
pull
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

 

[PeterPawn]

First: I don't own a box with the problem reported here, but there was at least another person reporting the same (I don't recall when so it might indeed be fixed).
But to answer your question: The Problem would only be present, if the voipd has to use an interface different to the "dsl" one, if the SIP-Server is "outside" his LAN.

As mentioned some postings above, I don't own a 7330 too.

To explain my configuration here (see below) a little bit further:
Most of my phone devices are connected to the "main" phone router, my 7490. The 6490 is configured to accept a single SIP client registration from 7490, each external number there is routed to this internal device. The two subnets used have nothing in common, they're completely isolated using different VLANs. The central router does not only transfer the traffic from net A to net B, it hides every internal client (that means the presence of other subnets too) from the access routers using SNAT targets with iptables. Each access router is using a default route to the connected provider and a second internal class C net route (192.168.0.0/16) to its only internal contact, the central router (it was set up using the GUI as usual). This routing table entry is the source for some other problems regardings AVM IPSec connections, but there's no relation to the current question here.

As a result, my 7490 registers as SIP client to the 6490 without any knowledge, how far the 6490 is away ... it's behind the internal gateway and that's all it needs to know. That's it, what I liked to explain in the previous posting, as I wrote, the voipd is simply unable to decide, how far its SIP registrar for this account is away and if there's an additional VPN connection in between or not.

If I didn't misunderstood anything, that's really a broad hint, that there's no routing problem inflicted by voipd anymore (at least for my 7490 and 6490 devices and because I'm using another SIP registration for the opposite direction too, it's really true for both models). That's all I wanted to explain to the thread initiator, with another try of a detailed explanation. Even if he has no more interest to solve the problem (my impression, 'cause there's no real attempt to try some clues), further readers could be fooled by the statement: "It's not possible." and therefore I'd like to track down the problem to its roots and refute the theory "voipd is the source of the wrong routing and there's nothing we can do here." at least, to avoid such references/impacts. If it's really impossible, I can accept this too ... but please do not reference an old thread and summarize it with the wrong conclusion.

@MaxMuster:
You're aware of OpenVPN configurations (even if configured from within the Freetz GUI) and you've shown excellent network knowledge in the past ... where's my wrong approach/explanation/suggestion above? I've tried to explain, why I simply cannot see the reason, that watching eth0 traffic is meaningful to judge anything in this context and that bridging from lan to the tun0 device (a foreign and unexpected interface for voipd) may be needed. The only way to prove this, is a network dump for the tun0 device. If there's no visible SIP traffic and the routing table looks good (ping works as expected, he wrote above), then one (logical) reason could be, the voipd bypasses the routing stack and sends SIP traffic directly "to the cable" (dev lan, usually a bridge). I've tried to explain this already. It's simple to verify and the only tool needed to do it, is a network sniffer and a full functioning brctl command to add/remove and (possibly) show bridge members. I did suggest this already ... there's nothing to say anymore. If you can't see anything wrong with my thoughts, the questioner could/should try to validate or refute them ... as mentioned above, he's the only one with the ability to do this, because both of us have lack of required hardware.

The AVM-Guide states ("Voraussetzungen / Einschränkungen: [...]FRITZ!Box B muss die Betriebsart "Vorhandene Internetverbindung mitbenutzen (IP-Client-Modus) " eingerichtet sein. [...] Beide FRITZ!Boxen müssen sich im gleichen IP-Netzwerk befinden") in other words: NO dsld should be used. This might(!) indicate, voipd will do somethig special if dsld is used.

@stefanoIT: Sorry, I'd like to answer this in German, to avoid any possible misunderstanding between MaxMuster and myself here (and it's not an important point for a solution, what I'd like to write now):

Das wäre aber auch nicht das erste Mal, daß die AVM-Howtos nur den einfachsten Lösungsweg beschreiben. Da selbstverständlich im Router-Modus das ganze nicht so leicht ist (schon die allgemeingültige Erklärung, wie ein passendes Routing über "dev lan" aussehen müßte, dürfte selbst Dir schwer fallen und normalerweise nur für einen konkreten Anwendungsfall gültig sein), wäre das auch nicht das erste Mal, daß AVM einfach behauptet, eine Voraussetzung müsse unbedingt erfüllt sein und es ginge nicht anders. Wobei ich selbst das da gar nicht einmal lese ... für mich ist das eine etwas unglückliche Überschrift ("Voraussetzungen / Einschränkungen"), wo - zumindest für einige Punkte - nicht klar wird, ob es sich um eine Eingangsvoraussetzung handelt, damit der vorgeschlagene Ablauf so (in der beschriebenen Abfolge von Handlungen) funktioniert oder ob es tatsächlich eine Rahmenbedingung ist, die immer erfüllt sein muß. Schon der erste Punkt ist ein solches Beispiel, denn selbstverständlich kann man Box B auch einrichten, wenn Box A weder existiert noch mit Box B verbunden ist. Es funktioniert dann eben erst, wenn man Box A nachträglich passend eingerichtet und verbunden hat.

Ich habe selbstverständlich auch verstanden, daß Du ihm nur eine mögliche Ursache aufzeigen wolltest - in meinen Augen eine, die ein älteres und nicht mehr bestehendes Problem (das könnte zwar bei der 7330 tatsächlich so sein, aber warum sollte sich deren voipd denn nun anders verhalten, als bei anderen Modellen, die Version 06.20 ist es bei ihm ja auch) als Erklärung heranzog für jemanden, der schon bei den Basics einfach falsche Vorstellungen hat und so seine Vorurteile/Irrtümer nur noch einmal bestätigt bekam.

Das war also eher keine direkte Frage an Dich persönlich, ich wollte mehr zum Ausdruck bringen, daß es keine - logische - Begründung für solchermaßen abweichendes Verhalten gibt und das frühere Verhalten nicht als Beleg herangezogen werden sollte. Es geht ja auch niemand mehr hin und behauptet, daß bei der Verwendung von 06.05 bei der 6360 das RTP-Routing fälschlicherweise (zumindest für eine Richtung) immer über die IPSec-Verbindung erfolgt und damit VPN und IP-Telefonie (und zwar auch die, die über dev dsl erfolgt) parallel nicht möglich ist, nur weil das bei der 06.03 (oder 06.04, ich will mich da nicht festlegen) einmal so war.

Für mich passen also ganz einfach die Annahmen des TE nicht zur Situation und die daraus resultierenden falschen Schlußfolgerungen, daß es gar nicht funktionieren könne, will ich ehrlich gesagt so nicht stehen lassen, denn das ergibt dann am Ende nicht nur beim TE Resignation, sondern auch bei späteren Lesern.

Wenn er selbst etwas "maulfaul" ist (und für mich zuwenig Eigeninitiative entwickelt, das habe ich ja oben im Text an ihn auch schon versucht zum Ausdruck zu bringen) und aus meinen Anmerkungen nicht die richtigen Schlüsse zieht - zugegebenermaßen bei einer jeweils als Fremdsprache anzunehmenden "common language" (ich tippe auch einen Italiener) manchmal etwas schwierig - bzw. das nicht als Anregung für eigene systematische Tests versteht, kann man ihm selbst wahrscheinlich nicht helfen ... aber man kann - meine Meinung - sehr wohl verhindern, daß am Ende eine falsche Begründung für das Nicht-Funktionieren übrig bleibt.

Wenn es tatsächlich nicht funktioniert, kann man es nicht ändern ... aber die Begründung: "Da steht auch, daß es nicht geht." ist für mich etwas schmal. Im verlinkten Thread finden sich nämlich genauso die Hinweise, daß es noch im 05.5x-Laborzweig wieder behoben war (so ab #67).

 

[stefanoIT]

I found the parameter

sipiface = sipiface_automatic;

in /var/flash/voip.conf
I changed it in

sipiface = tun0;

but nothing happened.
Usually the sipiface is voip

ua3 ([email protected], sipiface=voip): not registered ok 0  -- reachability 0 % (overvoip)
3: RX: 0 bytes, 0 pkts, TX: 0 bytes, 0 pkts, Lost packets: 0
3: Outgoing Calls: 0 attempted, 0 answered, 0 connected, 0 failed
3: Incoming Calls: 0 received, 0 answered, 0 connected, 0 failed
3: Overall Calls: 0 dropped, Total Call Time = 0:00

 

[PeterPawn]

I'll start one last try to explain my opinion. If you prefer to ignore it, please simply tell it ... and I may stop writing anymore. Up until now I can assume only, you do not really understand what I want to tell you.

You've shown us a tcpdump output in #1 showing SIP traffic on eth0 as an argument, that SIP traffic is routed to the dsl interface. But that was wrong, not the output, only your conclusion.

After I've proved (with an elaboration), that eth0 isn't your dsl interface but instead the local side of the router, my suggestion was that you check yourself, if eth0 is a member of the lan bridge on your device too. Your only answer was, that 'brctl show' is not working for you. Did you ever try to get a working version of brctl ? If you look into the original busybox from manufacturer's firmware, you'll find a working busybox binary - including the brctl applet with a show command. Who has made a mistake there, if your Freetz image was built without this command ? Do you guess it ?

And that's not all ... after an even longer explanation, why it could[/B] be necessary to bridge the tun0 device to lan bridge, you tell me

I use /dev/tun mode, so bridging should be not necessary.

Could you give an explanation please, beside the meaning "I use TUN mode." ? Where is the relationship between TUN vs. TAP mode and my suggestion, that the traffic - which is visible on eth0 already - should/could be bridged to the tun0 device too and therefore this interface should be added to the lan bridge (the option to do this, can be found in the Freetz GUI for OpenVPN) ? This are different facts. Especially because you're using a TUN device, your OpenVPN daemon will not see any layer2 traffic and if voipd really bypasses the normal routing and sends SIP packets directly to eth0/lan (so it will never match the routing table entry which would direct it to dev tun0), the obvious solution is to add the tun device to the lan bridge, where eth0 is usually a member. This may still not be the final solution, if voipd is bypassing the bridge code too, but you should try to investigate it step by step. If the SIP traffic does still not arrive on openvpn daemon, use a TAP device instead.

But you're playing around with options from your configuration file instead, without any knowledge about the meaning of this option ... and your setting "sipiface = tun0;" is simply not a valid one. Possible values for sipiface are:

sipiface_automatic
sipiface_internet
sipiface_voip
sipiface_mta
sipiface_homenet
sipiface_vpn
sipiface_tunnel

The only different setting, which could make sense in your case is "sipiface_homenet".

Your device has no mta interface, internet/voip are logical interfaces to the WAN connection, vpn is AVM's IPSec VPN solution (which is built on top of 'dev dsl' too) and tunnel is - my own interpretation - a L2TP interface. Personally I can't see any useful changes to this setting, you could investigate/try further.

Your SIP traffic was routed to the right interface in the past (you've seen it already in #1). If the output shown above is a current one, your configuration is messed up meanwhile and it looks like the default settings are used now. 'voip' is the default interface, if "route_always_over_internet = yes;" is not set, in which case 'internet' is used. Beside of such "presets", the interface decision is made using the routing table and voipd needs a clue of this, if it has to modify SIP headers to handle NAT traversals and other special situations. Even if I change the "route_always..." setting of my internal SIP registration, 'showvoipdstat' shows "sipiface=homenet" in its output. That's why I think, it's only a hint which is used, if two different logical interfaces are present on the final destination device.

Routes are set to 'dev dsl' (not 'dev internet' or 'dev voip') and if there are multiple interfaces to this device, voipd still needs a hint, which interface it should use to reach the target server. Both of them (there are situations too, where more than two logical interfaces are built on top of the WAN connection) have external IP addresses and usually only one of them may be used to connect to internal SIP servers of an access provider. In most cases it's the voip interface and if anyone uses an own SIP account from a different provider on a FRITZ!Box, where the voip interface has an internal address - valid on the provider network only - and that's why the external provider cannot be reached over the voip interface, you have to specify "route_always...=yes" and the other interface will be used. If the target interface of a routing table entry lacks "logical interfaces" (like eth0/lan do), there's no need for such a decision.

If your earlier settings are restored and the voipd registers to the SIP server after the routing table is complete (that means voipd may find out, that there's a special route to 194.243.192.1 and it should not use the default one), the output should show "sipiface=homenet". If it's not shown as expected, you could try to reinit the voidp after the OpenVPN connection is established with a "msgsend voipd reload" command, afterwards the voipd should reregister every SIP client account. If the interface decision is made again this time (if not, you can even kill and start the voipd daemon again), it should be shown as expected. And only if this is stll not the case, you should try to set sipiface to sipiface_homenet ... but I would still not understand, how the SIP traffic could be watched on eth0 in #1, if this is really necessary.

In my imagination (that's not a hard fact) voipd's special handling/knowledge of routes is the reason too, why it sounds possible, that the normal routing code may be bypassed while sending SIP packets. If there were additional changes to SIP packets inflicted by the routing part, the NAT traversal logic of voipd may become confused. It has to rewrite SIP headers to incorporate changes of addresses into them (via headers etc.), therefore it needs to know the "raw" addresses, before they have been "mangled" by any NAT logic or other potential pitfalls.

If you want to continue poking around in the fog and playing with unknown and opaque settings, it's your decision and I'm not able to force any useful action upon you. But please stop to cause further confusion for later readers. That does not mean, I'm able to provide you a working solution for your problem ... but I'm expecting I'm able to give you some hints, where you could investigate it further. If you don't want to get (any or even only my) help, it's no problem to tell it. It wouldn't bother me and - as mentioned above - I would stop writing useless posts.

 

[stefanoIT]

I tried sipiface = sipiface_tunnel and it works!!!!

ua3 ([email protected], sipiface=tunnel): registered ok 0  -- reachability 100 % (overinternet)
3: RX: 0 bytes, 0 pkts, TX: 0 bytes, 0 pkts, Lost packets: 0
3: Outgoing Calls: 0 attempted, 0 answered, 0 connected, 0 failed
3: Incoming Calls: 0 received, 0 answered, 0 connected, 0 failed
3: Overall Calls: 0 dropped, Total Call Time = 0:00

 

[PeterPawn]

I tried sipiface = sipiface_tunnel and it works

Congratulations. Period.

But ... one single additional try with this change as the only one? Sorry, i can't believe this.

And I find it regrettable that another chance is lost. There was the opportunity to explain the correct settings together with needed preconditions (when and how to set up the tunnel, restarting voipd is necessary or not, and so on). That could be useful for others too, if they find this thread later while searching for their own solution. While playing around with unknown/opaque settings and eventually getting the right combination is surely pleasant ... it's still not a reproduceable solution, if you do not explain, what you have done with details. Or may the next one, who reads this thread, change his own account to "sipiface = sipiface_tunnel;" and it will work as expected too?

As I mentioned above, the meaning of "sipiface_tunnel" was my own imagination only. It could be even the case, this option leads to a delayed routing decision from voipd (because tunnel interfaces are set up after voipd was started in most cases and usually they may change their addresses during their "lifetime") ... so voipd could examine the routing table for each packet immediately before/while the packet is processed. Another theory would be, voipd registers as an event sink for notifications about changes to an interface, if it finds an account with "sipiface_tunnel" and incorporates such changes into its internal routing accordingly. These theories/ideas and the consolidated results of your own other tries (and I'm sure, there were many more of them without the wanted results) ... this could have been summarized and published here to build a guide or even a check list for other readers.

Anyway, it's only my own opinion and your decision ... but would you please do me (and other readers too) a favor and change this thread to "solved"? Thank you for your cooperation.

 

[stefanoIT]

Anyway, it's only my own opinion and your decision ... but would you please do me (and other readers too) a favor and change this thread to "solved"? Thank you for your cooperation.

Thank you very much for your help. Without your informations I never could fix that.
All necessary to reproduce the solution is in the thread:

1) use a firmware from freetz with OpenVPN
2) configure openvpn as client (I posted my openvpn.conf)
3) modify the account section in /var/flash/voip.cfg using sipiface_tunnel
(if you change voip configuration using wheb interface the modification is deleted)

Only the account modified uses OpenVPN so you can have normal accounts too.

That's all.

P.S. Only one problem remains: I need to do the command voipd -R when OpenVPN comes up. I'm trying to find a way to do that.
OpenVPN is chrooted so I cannot do the command by the up script.

 

[MaxMuster]

If it's sufficient to do it once, an up script should be fine, it should be run once before changing user or chroot. If it has to be repeated e.g. after a reconnect, this will fail.
If you can live with the lower security you might try a configuration without "chroot" (and possibly without setting a non-privileged "user").

The simplest way to do this would be to copy your desired config to "/tmp/flash/openvpn/own_openvpn.conf", if this configuration file is present it will be taken during startup (ignoring any configurations made in the GUI).

 

[stefanoIT]

The simplest way to do this would be to copy your desired config to "/tmp/flash/openvpn/own_openvpn.conf", if this configuration file is present it will be taken during startup (ignoring any configurations made in the GUI).

That is why I love freetz

 

[PeterPawn]

:gruebel:
I'm a little bit surprised ... is reloading the voipd configuration needed, to get your setup running or is it a "nice to have" feature ?

Anyway ... you could try to use the msgsend command, as I wrote some posts above. The msgsend binary may be copied into your chroot jail and the needed socket file (/var/tmp/me_voipd.ctl) may be mounted (bind option) too into your jail. That should not weaken your security too much, sending messages to voipd is one-way and only a few commands are recognized.

EDIT: Ok, the -R option reregisters the SIP accounts only. Afaik there's a command to do this using msgsend too ... but I've to search this first, I can't remember it.
EDIT2:
Ok, two corrections of my thoughts/writings:

1. I cannot find a command to reregister SIP accounts using IPC.

2. My ideas regarding any mechanisms for a different handling of "sipiface_tunnel" seem to be wrong. Instead voipd uses - as far as I could find it now - 'tun0' as a fixed device name for each tunnel and therefore (same name of OpenVPNs tun/tap device) it uses the right device with this option too. If this finding is correct, a second connection using an additional tun device (two client connections to different servers, sharing a tun device is not possible in client mode as far as I know) would not function any longer (with voipd). There the solution with the bridge should solved the problem.

 

[MaxMuster]

Just one remark: To make this file (to be precise: any file in /tmp/flash) reset proof, you will need to do a "modsave flash" once (this will be called also with every config change you "apply", so you don't even need to call this command "by hand" on console).

 

[stefanoIT]

:gruebel:
I'm a little bit surprised ... is reloading the voipd configuration needed, to get your setup running or is it a "nice to have" feature ?

Anyway ... you could try to use the msgsend command, as I wrote some posts above. The msgsend binary may be copied into your chroot jail and the needed socket file (/var/tmp/me_voipd.ctl) may be mounted (bind option) too into your jail. That should not weaken your security too much, sending messages to voipd is one-way and only a few commands are recognized.

I made other tests. After the openVPN is up I need to stop and restart voipd in order to make it working (voipd -s && voipd). voipd -R is not enought. after voipd do the registration but the calls still fail. This is my experience.

Right now I'm using the following script in debug.cfg to restart voipd after the vpn is up

cat > /var/ckip.sh << EOF
while ! /bin/ping -c1 194.243.192.1 &> /dev/null; do :; done
/bin/voipd -s
/bin/voipd
EOF
/bin/sh /var/ckip.sh &