On Monday, June 03, 2013 05:57:32 PM Jeremy Porter wrote: > Ok here are some things to think about on your setup: > For digium server can ping the phones.
Yes.
> A Software Client
> X-Lite can be manually provisioned and works.
Yes.
> Digium hard phones will not provision.
Right.
> The quickest way to debug is going to be:
> Run a packet capture on both pfsense systems, with the IP
> address of one phone, as the match option. Go through
> reboot/provisioning. Look at those packet captures to
> determin, where the phone is trying to provision from,
> is it sending the requests to the Switchvox server?
Yes, I did this.
During the boot-up phase, DHCP assigns IP details to the
phone. All the phone tries to do at this stage is pull NTP
data from the Internet, as well as making some other DNS
requests. This works fine.
As there is no local Switchvox on the subnet, the phone
falls back to asking how it can be provisioned. This is when
we "manually" key in the Switchvox's IP address (and
optionally, the port number).
The local pfSense sees the 5060/udp request heading toward
the Switchvox, and creates state for it.
However, the remote pfSense doesn't see a thing. The traffic
literally disappears from the local pfSense. As though it
never leaves the local pfSense; and therein lies the issue.
I have created ingress ACL's on the Cisco router connected
to the Switchvox, and nothing hits the ACL's whose match
condition is the Switchvox.
> Does
> the pfsense located with the Switchvox see the provision
> requests?
No, nothing ever comes.
However, when I ping the phone from the Switchvox subnet
across the l3vpn, I can see state created for said ICMP
messages in both pfSense's, and ping works beautifully.
It's quite odd.
> Does the pfsense at the remote (phone) send
> the request?
That's the issue.
It looks like the pfSense on the phone subnet does not pass
the 5060/udp requests toward the other pfSense on the
Switchvox subnet.
Given requests from X-Lite work, it points toward some kind
of issue with how the hard phone provisions. It is one thing
for the packets to get to the Switchvox and fail due to a
configuration issue on it - but it's another for no packets
to arrive at all, i.e., the Switchvox has nothing to fail
about.
> Is the request being sent over the VPN?
Yes, it is the only available path.
> Is the switchvox system routing the provisoning requests
> back over the VPN, or trying to send them back over the
> public Internet?
The default gateway of the Switchvox is the local pfSense.
The pfSense has routing configured accordingly, so traffic
knows where to go.
I will say that at one of our offices, I have service with a
SIP Trunk provider using port forwarding from the pfSense
and into the Switchvox. So that works, in case anyone is
wondering.
> Without knowing what real protocol they
> are running over UDP port 5062, its hard to say what
> might be going on.
I don't really know either, but its certainly proprietary to
Digium.
The sequence is that the phone initially tries to register
to the Switchvox on 5060/udp. It then tries to provision the
phone and download firmware updates over 5062/udp. Since
5060/udp never completes, the next stage does not come
either.
> It sounds like you have only partial connetivity for some
> reason, either something in the firewalls is not sending
> the packets where they need to be, or the protocols the
> phones are using are trying to send the requests to the
> wrong IPs.
I'm more on the latter.
A packet capture on the pfSense located on the phone subnet
clearly shows the phone making the 5060/udp registration
request toward the remote Switchvox. Just that the remote
pfSense never creates any state for those packets, i.e., it
has nothing to pass on to the Switchvox because it never
sees it.
> Both switchvox and most VOIP phones have a "NAT" feature,
> where they can detect the public IP, and decided if to
> include that in the SIP header for replies. The
> provisioning protocol might have something similar. You
> didn't indicate if you had set the Switchvox system,
> (I've used switchvox before), so that the "local
> networks" (non-natted) were defined to include both the
> local site with the Switchvox and the remote site. (The
> setting is labeled a little counter intuitive, in that
> "local networks" really means don't NAT these IPs.
Switchvox, by default, has two local networks defined:
- Whatever subnet the Switchvox appliance is
configured in.
- Everything else, i.e., 0/0.
Even though manually creating an additional local network is
redundant (since 0/0 covers everything), we did it anyway,
and that didn't help either.
We're still debugging this on our end. As always, will let
you know if we find anything interesting. Thanks.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
