SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0004472: SIP Proxy Endian 2.5.1 - MantisBT Endian Bugtracker
Endian Issue Tracker

Please see now our new Bugtracker system: JIRA

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004472Endian FirewallUncategorizedpublic2012-10-22 23:432013-05-08 05:44
Assigned Toluca-endian 
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version2.5 
Target VersionFixed in Version 
Summary0004472: SIP Proxy Endian 2.5.1
DescriptionEndian 2.5.1 rewrites sip packets exiting tap1 with the IP to main interface. It also makes the changes inside the SIP packet which makes me believe there is some sort of SIP proxy action. The problem is I cannot find a sip proxy installed and this was a fresh install of Endian 2.5.1 not an upgrade. Is there some daemon running in the back that does these rewrites? Please see attached wire shark sniff. I have removed public IP information. Please note this capture was taken issuing the command: "tcpdump -s 0 -i tap1 -w tap1.pcap" The correct flow show have the internal IP of the phone as the source and not the external IP of the Endian uplink interface. I believe this started happening when I enabled the web proxy in transparent mode with dansguardian but cannot be sure. When the server replies, it replies to the endian public IP address over the public internet.
TagsNo tags attached.
Attached Filesjpg file icon tap1 capture.jpg [^] (258,270 bytes) 2012-10-22 23:43

- Relationships

-  Notes
luca-endian (developer)
2012-10-29 17:31

sip proxy has been removed long time ago now this stuff is handled by linux kernel with conntrack modules.
marioeirea (reporter)
2012-10-29 18:43

Right. However, it should not be changing the connections leaving the tap1 interface. Especially not with Endian's red IP as the source address. If a sip device is supposed to connect over the VPN there should not be a rewrite.
marioeirea (reporter)
2013-05-08 05:43

So this is what happens: When the EFW is restarted, the phones attempt to reconnect before the VPN is established. At this point, conntrack intercepts the connection, rewriting all packets leaving the TAP interface with the RED address. To fix the issue, one must flush the conntrack table issuing the command "conntrack -F conntrack". To prevent this from happening in the future, enable the outgoing firewall and block the destination IP the sip connections will connect to over the VPN. This way the connection is not intercepted with conntrack until the proper interface comes up.

- Issue History
Date Modified Username Field Change
2012-10-22 23:43 marioeirea New Issue
2012-10-22 23:43 marioeirea File Added: tap1 capture.jpg
2012-10-29 17:31 luca-endian Note Added: 0008251
2012-10-29 17:35 marioeirea Note Added: 0008252
2012-10-29 17:59 luca-endian Status new => closed
2012-10-29 17:59 luca-endian Assigned To => luca-endian
2012-10-29 17:59 luca-endian Resolution open => no change required
2012-10-29 18:43 marioeirea Note Added: 0008254
2012-10-29 18:43 marioeirea Status closed => feedback
2012-10-29 18:43 marioeirea Resolution no change required => reopened
2012-10-29 18:43 marioeirea Note Deleted: 0008252
2013-05-08 05:43 marioeirea Note Added: 0008429
2013-05-08 05:43 marioeirea Status feedback => new
2013-05-08 05:44 marioeirea Status new => resolved
2013-05-08 05:44 marioeirea Resolution reopened => no change required

Copyright © 2005-2008 Endian, SRL. All rights reserved.

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker