VCS-Control in production environment 10.100.100.33 /24 GW .1
VCS-Expressway in the DMZ.
Dual NIC option installed
LAN1 is our externally facing interface
192.168.100.33 /24 (DMZ IP address in DMZ A)
static nat mode ON
public IP 65.xx.xx.xx NAT'd to LAN1 IP Address
Static NAT address defined on this interface
set to 100/full (same on switchport)
LAN2 is our internal facing interface
192.168.200.33 /24 (DMZ IP address in DMZ B)
static nat mode OFF
Set to 100/full (same on swtichport)
I added the following route in the VCS-Expressway to allow VCS-Expressway to reach the VCS-Control
xCommand RouteAdd Address: "10.100.100.33" PrefixLength: 32 Gateway: "192.168.200.1" interface: "Lan2"
The VCS Control traversal zone is pointed to the LAN 2 IP Address of VCS-E. Both SIP and H323 are active.
We have 2 seperate DMZs in our environment and they both have a /24 subnet.
I configured each LAN interface on the Expressway to be in seperate subnets.
My question is that the 2 subnets on the VCS Expressway are seperated by a FW. Are there any appropriate rules I need to put in place on this firewall since LAN1 and LAN2 on the VCS-E straddle this FW?
I initially tried to place the LAN1 and LAN2 interface of VCS-E in a single subnet DMZ but was not succesfull in placing an outbound call.
I place a call from my EX90 registered to the VCS-Control and i see in the logs on the VCS Expressway that the call is being rejected.
Is there any other debugs i can run to figure out what is going on? Unfortunately i do not have access to the firewall so i cannot look at those logs.
When i use the DNS tool within the VCS-E i am able to resolve the Domain i am trying to call and see the SRV records.
Any thoughts would be appreciated.
couple of questions for you:
- Is there any NAT in between the VCS-C subnet and VCS-E LAN2 subnet?
- What is the default GW on VCS-E configured as? (It should be configured as 192.168.100.1)
The VCS-E will not require any routing whatsoever between the LAN1 and LAN2 subnets (192.168.100.0/24, 192.168.200.0/24).
Can you describe in more detail how you are seeing the VCS-E rejecting the outbound calls?
I assume you've created a DNS zone on the VCS-E and added an appropriate search rule for this zone?
There is no NAT configuration between the VCS-C and the LAN2 interface of VCS-E.
The Default GW on the VCS-E is 192.168.100.1
The only NAT enabled is to the LAN1 interface on the VCS-E and the public IP Address we have assigned to our A record for our VCS-E.
I have external DNS zone configured on VCS-E. I have verified the search rule with the "Check Pattern" tool. The external endpoint i am trying to call can recieves calls from other companies.
I see in the debug logs that the pattern is matching the external DNS zone and trying to resolve but i get a hostname could not resolve error as seen below.
(I scrubbed the output as i didn't want to post the SIP URI of the person i am trying to dial. His EX90 unit is set to auto answer.)
Detail="Considering search rule 'DNS Zone Search Rule' towards target 'External_DNS_Zone' at priority '150' with alias 'email@example.com'"
Detail="Sending DNS Query for someone.com"
Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"
Module="network.dns" Level="DEBUG": Detail="Sending DNS Query for _sips._tcp.someone.com"
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to: ['IPv4''TCP''64.XX.XX.XXX:5061'] (A/AAAA) Number of relevant records retrieved: 1"
Module="network.dns" Level="DEBUG": Detail="Sending DNS Query for _sip._tcp.someone.com"
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to: ['IPv4''TCP''64.XXX.XX.XXX:5060'] (A/AAAA) Number of relevant records retrieved: 1"
Module="network.dns" Level="DEBUG": Detail="Sending DNS Query for _sip._udp.someone.com"
you should see in the diagnostic log (With network log level set to 'DEBUG') that the VCS-E is attempting to connect to 64.XX.XX.XXX on TCP port 5061 (Search for "TCP connecting" or for the IP address itself.)
My guess is that this connection attempt fails, and that this is what's causing the call to fail.
You were correct. I do see in the diag log the tcp connection is failing. Does this type of error indicate a FW issue? I will ask our FW admin to check the rules while i make a test call.
Module="network.tcp" Level="DEBUG":Src-ip="192.x.x.x" Src-port="25003" Dst-ip="64.x.x.x" Dst-port="5061" Detail="TCP Connecting"
Module="network.tcp" Level="ERROR": Src-ip="192.x.x.x" Src-port="25003" Dst-ip="64.x.x.x" Dst-port="5061" Detail="TCP Connection Failed"
yes this is normally a firewall issue.
For the firewall outside the VCS-E, in addition to allowing normal network services such as DNS and NTP, you normally want to open all highports (1025-65535) on UDP and TCP in the outgoing direction, since you can not control which ports the far end (In Internet side) will request for H323 and SIP signaling and UDP media.
Andreas thanks for the help.
I am going to have the FW Admin check the ports to ensure they are open. I provided that guide to my admin when i initially asked for the ports so they would know what needed to be opened.
According to FW admin the ports are open except for the one needed for inbound from internet for TURN Server control (3478) and TURN Server media (60000 - 61799) and the same for Turn Server Media in the outbound (to internet).
Interenstingly enough i can recieve inbound calls from my Cisco SE. He calls me via my SIP URI and we are able to connect but at 15 minutes the call is disconnected without us doing anything. There must be some keepalive or something which is missed and the call gets disconnected.
I am still investigating this issue as well. I will post back with my findings.
the disconnect at the 15 minute mark probably means that your SIP endpoint is trying to send a session refresh/re-INVITE towards the Cisco SE and that this is failing due to the same reason as discovered earlier. This indicates that inbound connections towards your VCS-E are working while outbound fails.
If the firewall blocks the outbound connection attempt on 5061/TCP, this should be evident in the firewall logs, unless the block is occuring further upstream of the firewall.
I placed a call which the FW admin was watching and sure enough they are blocking some ports outbound from our Expresssway to the internet.
They are going to make the updates during a change window and i will test after that. Hopefully this will resolve our issue with outbound dial.
I will post back once confirmed.