0004472: SIP Proxy Endian 2.5.1

Please see now our new Bugtracker system: JIRA

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004472

Endian Firewall

Uncategorized

public

2012-10-22 23:43

2013-05-08 05:44

Reporter

marioeirea

Assigned To

luca-endian

Priority

normal

Severity

major

Reproducibility

always

Status

resolved

Resolution

no change required

Platform

OS Version

Product Version

2.5

Target Version

Fixed in Version

Summary

0004472: SIP Proxy Endian 2.5.1

Description

Endian 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.

Tags

No tags attached.

Attached Files

tap1 capture.jpg [^] (258,270 bytes) 2012-10-22 23:43

Relationships

Notes
(0008251) 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.

(0008254) 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.

(0008429) 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