2 IP address

[Francois La Rochelle]

I would like to add a 2nd IP address to my system, is there any special setting somewhere ?

I am using Static IP Authentication and I will need a 2nd IP to give alternate Outbound route

 

[DigitalDaz]

Can you clarify this please? I do not understand what you are asking.

 

[Francois La Rochelle]

My VoIP provider works with Static IP Authentication, so my IP address is my password for my main trunk, I don't need to register, I need to add a 2nd trunk and I need to add a 2nd IP address to my PBX.

do I need to modify something in the PBX to add the 2nd IP address

 

[DigitalDaz]

No, but why do you need to add a second IP address to the PBX?

 

[Francois La Rochelle]

I can't use the same IP address for a 2nd trunk, each trunk is 23 simultaneous calls Inbound and outbound

 

[DigitalDaz]

So you need a second trunk to same carrier using a different source IP?

 

[Francois La Rochelle]

Yes that's the way they work unless I use a sip channel with login and password. The problem I have is the caller ID gets modified by Canadian cellphone provider and that caller ID gets block.

With the Static IP Authentication the caller ID works fine and no call block.

 

[DigitalDaz]

That would technically not be the easiest thing to do at all, you are talking about changing the source IP address of the packets on a potentially call by call basis, put it this way, I'm quite good at networking but I certainly wouldn't fancy trying that.

 

[Herbert Whistlefjord]

Here is how I handle something vaguely similar to what you are doing. Some notes about the scenario:

• The provider I'm using [Gamma Telecom] only offer IP authentication
• The provider gives me an Active and a Standby SBC to send/receive calls from
• My server is always NATed by a firewall that usually has two [or more] WANs
• Fusion talks to the Active SBC out of one WAN and the Standby SBC out of the other WAN.
• The SIP endpoints are only ever internal.

Not sure how much applies to you but hopefully something in this post is useful to you.

Two alias IPs in addition to the normal IP on the NIC, eg in /etc/network/interfaces:

auto eth0
iface eth0 inet static
        address 10.10.3.193
        netmask 255.255.255.0
        gateway 10.10.3.1

auto eth0:pri
iface eth0:pri inet static
        address 10.10.3.194
        netmask 255.255.255.0

auto eth0:sec
iface eth0:sec inet static
        address 10.10.3.195
        netmask 255.255.255.0

I then create a SIP profile for each of the alias IPs, by copying the default External profile. My External Active and External Standby profiles have the ext-*-ip set to whatever I am NATing back from on the appropriate WAN. The rtp-ip and sip-ip are set to match the relevant eth0:alias IP address. I always set the SIP port to 5060.
The SIP endpoints only ever talk to the base eth0 address, not the aliases. If there is only one WAN then I only have one alias IP and one external profile.
Outbound resilience is handled by setting a ping interval on the Gateway so Freeswitch tracks the state of the provider's SBC, and then having action bridge the two gateways as the last two entries on the outbound route. If the Active gateway becomes unreachable then the Standby gateway is used. Inbound resilience is achieved by the provider basically doing the same thing to me in reverse.

 

[DigitalDaz]

Surely if you ngrep this traffic the source IP is always: 10.10.3.193 ??

 

[Herbert Whistlefjord]

Thankfully not, or it wouldn't work!

 

[DigitalDaz]

I can well understand this putting the other IPs in the SIP packets but I don't savvy how it changes the underlying network source address.

 

[DigitalDaz]

I have achieved similar in the past but always had to use iptables to switch out the source address.

At the very least, the unprivileged user www-data should NEVER be able to change anything in the networking stack.

 

[Herbert Whistlefjord]

To fill in some potential blanks:

• The firewall has static routes to the Active SBC and the Standby SBC out of the appropriate WAN
• The Active Gateway configuration has the external-Active SIP Profile assigned so it knows which IP to talk out of when speaking to the Active SBC, the Standby Gateway similarly has the external-Standby profile

 

[DigitalDaz]

My bad, I didn't read right, of course, this is natted traffic.

 

[Herbert Whistlefjord]

I don't lack for hatred of NAT, but NAT actually makes things simpler in this scenario.
I am not likely to ever need to try this with actual public IPs on the server running Fusion, but I can't think of any obstacles here - surely everything you need is handled by the abilities of the SIP profiles?

 

[DigitalDaz]

Yes, if you are behind NAT, the source public IP address will be handles further down the line if configured to do so.

As an example though, one time I had to do this with a mailserver, I cannot remember what the deal was exactly, but there was already another mail server listening on port 25. I had to do the same and add a new eth interface with a new IP.

The server listened on this new IP just fine and received traffic perfectly. The problem was though that when it SENT traffic, the source ip was still the main eth0 ip.

You should be able to verify this quite easily with:

ngrep -dany port 5060 -W byline

and then examine the network source address, NOT the sip stuff.

U 192.168.1.114:10776 -> 192.168.1.182:5060 <----------------------------
INVITE sip:*97@192.168.1.182 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.114:10776;branch=z9hG4bK-d8754z-ce5223051f04875f-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:200@192.168.1.114:10776>.
To: <sip:*97@192.168.1.182>.
From: "200"<sip:200@192.168.1.182>;tag=e55b3d7e.
Call-ID: ODBkNGJiODA0NzUwN2VlNzBmZmViMzA5OWM5YWZiZjI..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
Proxy-Authorization: Digest username="200",realm="192.168.1.182",nonce="2d96e618-0365-47e8-b5a1-ba7da70d38a4",uri="sip:*97@192.168.1.182",response="5bd329253efe29cd6f3a14404559d37c",cnonce="45fd515cb602e0eb82b423fb17c429a6",nc=00000001,qop=auth,algorithm=MD5.
Supported: replaces.
User-Agent: Bria Professional release 2.4 stamp 49381.
Content-Length: 399.

 

[Herbert Whistlefjord]

I know FreeSWITCH must be sending the packets out with the right L3 source IP, because if it wasn't, the firewall wouldn't be NATing the packets to the correct public IP, and if it didn't NAT the packets to the correct L3 IP then Gamma would be sending back a 403 and nothing would work.

 

[Francois La Rochelle]

I have added a new Ip to my server, by the way it is a cloud server so there is no internal IP address only 127.0.0.1

auto lo
iface lo inet loopback

# Auto generated venet0 interfaces
auto venet0
iface venet0 inet static
address 127.0.0.1
netmask 255.255.255.255
broadcast 0.0.0.0
up route add default dev venet0

iface venet0 inet6 static
address ::2
netmask 128
up ip -6 r a default dev venet0
auto venet0:0
iface venet0:0 inet static
address 200.00.200.003 <-- NOT the real IP

auto venet0:1
iface venet0:1 inet static
address 200.00.200.005 <-- NOT the real IP
netmask 255.255.255.0

Now I have copy Internal Sip profile and now what do I need to change and where.

 

[Francois La Rochelle]

I keep getting Invalid profile when I try to start the profile. I have tried to flush reload etc