IPSEC Brekeke answers with public address

tschaikowskinksi · Post by **tschaikowskinksi** » Thu Jun 16, 2011 6:57 am

1. Brekeke Product Name and version:
2.4.8.6/286.3
2. Java version:

3. OS type and the version:
Linux
4. UA (phone), gateway or other hardware/software involved:
PhonerLite
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :6

6. Your problem:

We have an IPsec tunnel terminating on the same machine as SIP-Server.

SIP-Server has public address 1.1.1.1 and an internal interface 10.99.99.1
I do the registration form my machine with ip 10.22.17.101

When I try to register the trace looks like:

10.22.17.101 -> 10.99.99.1 SIP Request: REGISTER sip:10.99.99.1
1.1.1.1 -> 10.22.17.101 SIP Status: 100 Trying (0 bindings)

The problem is that brekeke is anwering with the public (1.1.1.1) instead with the privat IP (10.99.99.1). Thus the packets will not traverse the tunnle and I don't get any reply from the SIP-Server.

I've already tried to remove 1.1.1.1 form the network interface config of the SIP-Server -> no change.

Any suggestions?

Thanks Marco

Harold · Post by **Harold** » Thu Jun 16, 2011 10:38 am

Try the binding-address settings.
http://wiki.brekeke.com/wiki/Bind-Breke ... IP-address

tschaikowskinksi · Post by **tschaikowskinksi** » Fri Jun 17, 2011 12:37 am

binding to one address is not the solution because SIP-Server should answer to both address ranges (private and public).

I think the problem is that SIP-Server sees the packets coming form the external interface but with a Private IP address. That is due to IPsec packet decryption.

SIP-Server should answer with the pivate address to which the packet was send to not with the address of the interface.

Harold · Post by **Harold** » Fri Jun 17, 2011 11:17 am

Are they physical interfaces?

If you run an IPsec tunnel on different machine, does the same problem happen?

tschaikowskinksi · Post by **tschaikowskinksi** » Sat Jun 18, 2011 5:05 am

yes it's physical interfaces. It should not happen on two different machines, but that ist not my usecase neither I have tested it.

Thanks Marco

Harold · Post by **Harold** » Sat Jun 18, 2011 4:16 pm

Have you tried the "route" command to define preferred route?

tschaikowskinksi · Post by **tschaikowskinksi** » Mon Jun 20, 2011 12:20 am

I have not found such a command in the documentation. The Routing is not the problem. SIP-Server simply answers with the wrong IP. I think that is kind of wrong implementation inside SIP-Server.

I could do a workaround using snat but that shouldn't be necessary if the system would react in the right way.

Harold · Post by **Harold** » Mon Jun 20, 2011 12:36 pm

I mean Linux's "route" command.
It will allow you to use a certain interface.

tschaikowskinksi · Post by **tschaikowskinksi** » Tue Jun 21, 2011 12:57 am

Routing is working no problems here, but as I said!! Sip-Server should answer with that source IP-Address to that the the request was issued:

e.g.

Request (From UA)

Source: Dest (Sip-Server)
1.1.1.1 -> 10.88.88.1

Answer (From Sip-Server)

2.2.2.2 -> 1.1.1.1

That is clearly worng Behavior!! Or am I worng on that?

Best Marco

janP · Post by **janP** » Tue Jun 21, 2011 10:25 am

it is not SIP server's issue. it is your setting issue..

tschaikowskinksi · Post by **tschaikowskinksi** » Tue Jun 21, 2011 11:29 pm

Oh fine, then tell me please what should I change.

Thanks

voipwell.com · Post by **voipwell.com** » Wed Jun 22, 2011 7:37 pm

Hello,

I would point you at $ifsrc and $ifdst in the sip server administration guide. It appears with these commands you can detect packets coming in from an interface and direct it back using your choice of the two interfaces($ifdst)($ifdst).

It's on page 75 of sip server administration guide. See if that will give you the control you need to send the packets back from the ipsec interface instead of the default wan interface. You will need to put these into the sip server dial plan. You will have to read it over a few times but it will make sense after a while.

CastB · Post by **CastB** » Tue May 01, 2012 3:24 am

Hello Tschaikowskinksi,

We do have the same situation. Were you able to solve it or does someone else knows how to do this?

Thanks

ambrosio · Post by **ambrosio** » Tue May 01, 2012 1:39 pm

The "route" command will solve the problem.
Execute this command to check the current setting and tune it.