Hi Tony, Just a few question about your implementation.
Seeing your scenario means you only have 1 sipxecs server? Is the IPSEC tunnel created via pfsense or from your router? Best regards, Rhon On Thu, Apr 22, 2010 at 9:18 PM, Tony Graziano <[email protected] > wrote: > > > On Thu, Apr 22, 2010 at 9:09 AM, JOLY, ROBERT (ROBERT) <[email protected]>wrote: > >> > I am curious as to whether the following "should" work in 4.2 >> > under the following: >> > >> > sipxecs >> > server<----firewall--->|Internet|<---firewall---><remote >> > branch, users: thing1 and thing2> >> >> This is definitely a scenario that is working. Support for this kind of >> deployment was one of the major justifications for doing the far-end NAT >> traversal feature in the first place. >> >> I you can, I would be *very* interested in seeing the tcpdump output of >> your failing scenario. The 'tcpdump' command you need to run can be found >> in >> http://wiki.sipfoundry.org/display/xecsuserV4r0/Remote+User+NAT+Traversal(along >> with other troubleshooting and config tips). >> >> In my instance I have a pfsense firewall at both sides, and there is a > known issue with sip. I nailed up an IPSEC connection between the two and it > works. I could have enabled sipxroxd at the other end, but that type of > scenario is "contraindicative" since now there is an ALG in the way, so I > declined to do it that way. pfsense at the remote side is provisioning the > dhcp options so the phone setups are as "automatic" as the local ones, which > is great. > > What I am trying to do here is setup a remote branch "without" an ipsec > connection (or pfsense) firewall at the other end. Something basic, like a > linksys/netgear/dlink (generic stuff) that will support more than one phone > in a scenario as described above. > > I know some of the routers have features that need to be turned off (some > that can't). So if it "is" working as I described, can you share "what" you > use at the far end? > >> > >> > Should thing1 and thing2 be able to call each other? Setting >> > the media relay to aggressive did not seem to help. >> > >> > Has anyone been able to use it in a scenario as described >> > above? There is no SPI or ALG at the location where the >> > remote users are. All other functions (registration, media >> > services, vm, PSTN calls, etc., seem to work). >> > >> > -- >> > ====================== >> > Tony Graziano, Manager >> > Telephone: 434.984.8430 >> > Fax: 434.984.8431 >> > >> > Email: [email protected] >> > >> > LAN/Telephony/Security and Control Systems Helpdesk: >> > Telephone: 434.984.8426 >> > Fax: 434.984.8427 >> > >> > Helpdesk Contract Customers: >> > http://www.myitdepartment.net/gethelp/ >> > >> > Why do mathematicians always confuse Halloween and Christmas? >> > Because 31 Oct = 25 Dec. >> > >> > >> > >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
