How to replace source IP address with another

[ajlindy]

1. Brekeke Product Name and Version: 3.x

2. Java version: 8.1

3. OS type and the version: Win Server 2k16

4. UA (phone), gateway or other hardware/software involved: N/A

5. Your problem:


We have servers with two NIC cards. Each NIC has two ports. We team the ports together so we have A team and B team.

USUALLY, A team is the public facing IP address (10.10.10.10 for example). B team is a private IP address (192.168.1.1) we use to create a UDP backplane so two servers can talk to each other.

What we have found is Microsoft will make its own decisions on outbound SIP requests sometimes, so instead of an Invite coming from 3175555555@10.10.10.10 it will come from @192.168.1.1.

So you can imagine when the outside world responds, it responds to 192.168.1.1 and the call fails.

This doesn't happen all the time on all the systems we send out, but when it does the ONLY thing we have ever found that fixes it is to take the network connections for A and B team and physically swap them, then swap the IP addresses for A and B team.

So, how do I set a dialing plan rule that if it sees and invite from @192.168.1.1 it goes out instead with @10.10.10.10?

This way, no matter what happens the SIP invite will always work and traffic goes to the public IP address.

I have several problems when trying to troubleshoot this myself.
1. I have no real testing system I can fully manipulate and run captures on to test my changes. What I do have is Brekeke SIP Proxy version 2.4.X on a computer I can literally NOT access except through a web browser.
2. The only thing I've ever managed to get sorted out with replacing pieces of an Invite is the outbound caller ID. I think I could change it up to make the IP change instead of the caller ID but I'd like to run it by somebody first.

This replaces a caller ID of ten zeroes with a real phone number:

Matching Patterns

$request = ^INVITE $getURI(From) = sip:(0000000000)@(.+) Remote-Party-ID = (.+)@(.+)>(.+)

Deploy Patterns

$b2bua = true To = sip:%1@11.12.13.14 (outside Cisco PBX) $replaceuri = true Remote-Party-ID = "3175551234"<sip:3175551234@%2>;party=calling;screen=yes;privacy=off

So, what would happen if I made a new dialing plan rule that looked like this:

Matching Patterns

$request = ^INVITE $getURI(From) = sip:(.+)@(192.168.1.1) Remote-Party-ID = (.+)@(.+)>(.+)

Deploy Patterns

$b2bua = true To = sip:%1@11.12.13.14 (outside Cisco PBX) $replaceuri = true Remote-Party-ID = <sip:(.+)@10.10.10.10>;party=calling;screen=yes;privacy=off

Would that cause the Invite to go out as though it's coming from 10.10.10.10 instead of 192.168.1.1?

And if so, is that enough to trick the system into sending responses back to the correct NIC?

Follow-up question is, if my original system is sending out Invites from the wrong IP address, will it even know what to do with the return messages if they hit the right NIC?

[Laurie]

The "route" command on the OS will help you.

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/route_ws2008
https://www.computerhope.com/routehlp.htm

[ajlindy]

Thank you, I will dive in!

[ajlindy]

So, some more information and then a question.

One, we have an A Team and B Team. Both have a literal Front and Back NIC available, and only the A Front and B Front are plugged in.

The Automatic Metrics were set for the Private connection NIC, so I changed it to 5. It was also set for Automatic for the Public connection NIC so I changed it to 1.

The gateway for the Public NIC was defined and had an automatic metric so I changed it to 2. There is no gateway defined for private NIC.

I then rebooted and started a WireShark trace on my contact platform. The issue is the SIP invite literally comes out the 172 public NIC but the header is from @192. private NIC. Still.

We have a small utility that shows on the Desktop the IP addresses and it lists 192.168.1.1 first.

C:\>route print
===========================================================================
Interface List
19...00 c0 07 06 58 12 ......Microsoft Network Adapter Multiplexor Driver
20...00 c0 07 06 58 13 ......Microsoft Network Adapter Multiplexor Driver #2
15...00 c0 07 06 58 14 ......Intel(R) PRO/1000 PT Dual Port Server Connection #
4
12...00 c0 07 06 58 15 ......Intel(R) PRO/1000 PT Dual Port Server Connection
1...........................Software Loopback Interface 1
23...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
22...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.30.238.250 172.30.238.154 2
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.30.238.0 255.255.255.0 On-link 172.30.238.154 257
172.30.238.154 255.255.255.255 On-link 172.30.238.154 257
172.30.238.255 255.255.255.255 On-link 172.30.238.154 257
192.168.1.0 255.255.255.0 On-link 192.168.1.1 261
192.168.1.1 255.255.255.255 On-link 192.168.1.1 261
192.168.1.255 255.255.255.255 On-link 192.168.1.1 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.30.238.154 257
224.0.0.0 240.0.0.0 On-link 192.168.1.1 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.30.238.154 257
255.255.255.255 255.255.255.255 On-link 192.168.1.1 261
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 172.30.238.250 1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
1 306 ff00::/8 On-link
===========================================================================
Persistent Routes:
None

The public NIC is weighted lower than the Private. I would think for all kinds of everything, the public NIC would be the one to use.

Here is the kicker. If I swap the IP for A Team and B Team and the physical cables, so now the old Public NIC is private and vice versa, then the SIP Invites STILL go out 172.X public AND the SIP Header is from @172 public.


So I have no idea how to keep the private IP as a valid address, usable for our purposes, but COMPLETELY OUT of the SIP Invites and all other responses without a physical swap of network cables and IP addresses.

[Laurie]

> 172 public NIC but the header is from @192. private NIC. Still.

Do you have a DialPlan rule for the route which you want to use a 172.x.x.x IP address?
so put $ifdst with a 172.x.x.x in the Deploy Pattern of the rule.

For example,
$ifdst = 172.30.238.154