Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 21 replies
  • Subscribers 2 subscribers
  • Views 15564 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Newbie/RED phone sytem problem\

MikeSwann
We have a 3com V3000 phone system. Our office network is DCHP'ed by the fire wall and has a .1.1 domain. The RED hardware has a .4.1 domain and DCHP's locally.


We have a  3com 3102 handset  that we configured in the office by auto discovery. We took it to the remote office and get the error message "wait for NCP M". System is set up for IP on the Fly.

 

We have the RED device set for "any" communication each direction with the "in office" system.  

The phone is the only thing connected to the VPN device. Angry IP reports no ip address for any of the handsets when scanned from the .1.1 or .4.1 domain. The NBX Telephone configuration>Telephones>IP settings is not reporting an address for the remote phone.  I tried forcing setting an IP address, subnet and gateway at the correct domain to the hand set, but this did not work either. 

The odd thing is if I plug in my laptop in the RED that has a soft phone installed, it works fine.  SBS communicates fine too.

Here is a traffic monitor that is going on at the VPN device with only the handset connected:

Proto Source IP Port Destination IP Port Bytes in Pkt in Bytes out Pkt out

udp 0.0.0.0 68 255.255.255.255 67 1146 3 0 0

icmp 192.168.4.1 - 192.168.4.254 - 48 1 0 0 (I am guessing this is the hand set)

Something that is troubling, is the udp 0.0.0.0 response on the packet monitor. Its always paired with the vpn device, 1628 times a day.

Another thing is I cant ping any of the known devices, laptop or handset on the RED from the office. Is this normal?

Any recommendations?

thanks in advance.


This thread was automatically locked due to age.
Parents
  • 0
    Sounds like your reseller isn't very helpful to you.  Here are my two suggestions:

    1)  Call up Astaro sales and let them know that you want to switch resellers.  They will be able to suggest some knowledgeable resellers that you can try.  Call them up and interview before you commit to switching to one.  Also ask for customer references that you can contact.

    2)  I realize that times are tight, but in your situation I think that it would definitely save you time/money to upgrade your support contract from Standard to Premium.  Depending on how much time you have on your subscriptions, it should cost you in the realm of $250-$300 per year (less if you are using a software version with a low number of users license).  Much nicer to get a problem looked into in 4 hours than having to beat your head into a wall for weeks.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 0 in reply to Scott_Klassen
    I'm a certified 3COM NBX Installer (well, I was in a former life, LOL) ... the NBX is a great system, but some folks misunderstand some of its' intricacies.

    The NBX "IP on the Fly" feature is used to assign phones LOCAL to the NBX a temporary IP (the phones with this system are often provisioned as layer 2 devices .. no IPs .. in local situations--it's actually pretty cool, makes for an easy setup) IF it needs to communicate with a phone on a remote subnet...  IP on the Fly does not act as a DHCP server.

    You will need to configure DHCP for that remote network (behind the RED), either using a standalone DHCP server, or by setting up a DHCP server instance on the ASG to be serviced by the RED.  You will also need to manually configure the NBX IP (Call Processor) on the remote phones so they can communicate with the NBX Call Processor, or you can configure a DHCP option (not available on the ASG, you'd have to have a standalone DHCP server for this) to provide that voice gateway IP to the phone.

    Incidentally, if you want to use static IPs (we did for most remote deployments anyway), you only need to set them on the phone via the onboard menu... the changes, once it connects to the NBX, will automatically populate the admin console.  You mainly need a valid IP, Mask, Gateway, and NBX Call Processor IP input into the phone... after it connects up, you can manage it from the NBX Admin Console (web management).

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0 in reply to Scott_Klassen
    I'm a certified 3COM NBX Installer (well, I was in a former life, LOL) ... the NBX is a great system, but some folks misunderstand some of its' intricacies.

    The NBX "IP on the Fly" feature is used to assign phones LOCAL to the NBX a temporary IP (the phones with this system are often provisioned as layer 2 devices .. no IPs .. in local situations--it's actually pretty cool, makes for an easy setup) IF it needs to communicate with a phone on a remote subnet...  IP on the Fly does not act as a DHCP server.

    You will need to configure DHCP for that remote network (behind the RED), either using a standalone DHCP server, or by setting up a DHCP server instance on the ASG to be serviced by the RED.  You will also need to manually configure the NBX IP (Call Processor) on the remote phones so they can communicate with the NBX Call Processor, or you can configure a DHCP option (not available on the ASG, you'd have to have a standalone DHCP server for this) to provide that voice gateway IP to the phone.

    Incidentally, if you want to use static IPs (we did for most remote deployments anyway), you only need to set them on the phone via the onboard menu... the changes, once it connects to the NBX, will automatically populate the admin console.  You mainly need a valid IP, Mask, Gateway, and NBX Call Processor IP input into the phone... after it connects up, you can manage it from the NBX Admin Console (web management).

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
  • 0 in reply to BrucekConvergent
    I'm a certified 3COM NBX Installer (well, I was in a former life, LOL) ... the NBX is a great system, but some folks misunderstand some of its' intricacies.

    The NBX "IP on the Fly" feature is used to assign phones LOCAL to the NBX a temporary IP (the phones with this system are often provisioned as layer 2 devices .. no IPs .. in local situations--it's actually pretty cool, makes for an easy setup) IF it needs to communicate with a phone on a remote subnet...  IP on the Fly does not act as a DHCP server.

    You will need to configure DHCP for that remote network (behind the RED), either using a standalone DHCP server, or by setting up a DHCP server instance on the ASG to be serviced by the RED.  You will also need to manually configure the NBX IP (Call Processor) on the remote phones so they can communicate with the NBX Call Processor, or you can configure a DHCP option (not available on the ASG, you'd have to have a standalone DHCP server for this) to provide that voice gateway IP to the phone.

    Incidentally, if you want to use static IPs (we did for most remote deployments anyway), you only need to set them on the phone via the onboard menu... the changes, once it connects to the NBX, will automatically populate the admin console.  You mainly need a valid IP, Mask, Gateway, and NBX Call Processor IP input into the phone... after it connects up, you can manage it from the NBX Admin Console (web management).


    Bruce, Wow, this is getting exciting!

    I agree about the NBX, on interal networks, its really simple to administer and set up for people with limited skills.

    Pardon me for my limited skill set on the firewall, but am learning.

    The NBX "IP on the Fly" feature is used to assign phones LOCAL to the NBX a temporary IP (the phones with this system are often provisioned as layer 2 devices .. no IPs .. in local situations--it's actually pretty cool, makes for an easy setup) IF it needs to communicate with a phone on a remote subnet...  IP on the Fly does not act as a DHCP server.


    This makes sense!

    You will need to configure DHCP for that remote network (behind the RED), either using a standalone DHCP server, or by setting up a DHCP server instance on the ASG to be serviced by the RED.  You will also need to manually configure the NBX IP (Call Processor) on the remote phones so they can communicate with the NBX Call Processor, or you can configure a DHCP option (not available on the ASG, you'd have to have a standalone DHCP server for this) to provide that voice gateway IP to the phone.


    This is a pretty complicated statement. Can you explain this a little more thouroughly? The ASG is the DHCP server in the internal network and the RED is the DHCP server for the PC and 3102 handset thats plugged into it. Since the PC gets an IP address on the RED, I am assuming that it is doing the DHCP locally. However, when I interrogate the 3012 handset, 0's and 255's; why is this happening?

    You mainly need a valid IP, Mask, Gateway, and NBX Call Processor IP input into the phone

     Is that the RED gateway or the ASG/internal gateway that the V3000 uses?


    I can handle the manual programming of the static IP's, but it would be nice to plug n play/auto discover. Fits will into plans of future office deployment when the economy picks up.

    Any comments on port rules?

    thanks,

    Mike
  • 0 in reply to MikeSwann
    Hello Mike

    Here's another possible solution - if the RED is used solely for the VOIP Phone, or if it doesn't matter, if your remote RED Network is integrated in the same IP range as your HQ / PBX.

    I assume, that the "on the fly" configuration of the softphone is done every boot / startup. I also assume, that this feature is limited to work into the broadcast domain (same subnet), where the PBX is sitting.

    In this specific case a cool workaround could be to remove the .4.x IP Adress from the redsx Interface (delete the interface), and create a bridge between the eth interface of your network, where the pbx sits, and the reds interface.

    As packetfilterrule you have to create following rule, that all communication (including DHCP / BOOTP traffic) will be transferred between those two networks

    Source Network 0.0.0.0 (bound to the bridge BRx Interface - Service ANY - Destination Network 0.0.0.0 (bound to the bridge BRx Interface

    This scenario allows broadcasts etc. through the RED tunnel and should solve your - maybe routing related - issues between your phone and PBX

    /Sascha

    Layer2 with RED is cool...[:D]
Unfiltered HTML