Your outbound Nat type needs to be set for "static port" before your Nat rules are created. On Jul 20, 2012 8:03 PM, "Kurt Albershardt" <k...@nv.net> wrote:
> Forgot to mention that it does not appear to be doing port randomization. > Running tcpdump from the pfSense box itself shows source ports of 5080, > which should effectively open the hole for their inbound UDP: > > 17:47:36.868729 IP sipx.domain.com.5080 > 66.241.X.X.5060: SIP, length: 4 > 17:47:56.875211 IP sipx.domain.com.5080 > 66.241.X.X.5060: SIP, length: 4 > 17:48:16.882387 IP sipx.domain.com.5080 > 66.241.X.X.5060: SIP, length: 4 > 17:48:36.889707 IP sipx.domain.com.5080 > 66.241.X.X.5060: SIP, length: 4 > 17:48:56.896991 IP sipx.domain.com.5080 > 66.241.X.X.5060: SIP, length: 4 > > > > > On Jul 20, 2012, at 17:36 , Tony Graziano wrote: > > What is the firewall? > On Jul 20, 2012 7:22 PM, "Kurt Albershardt" <k...@nv.net> wrote: > >> Packets appear not to be making it out of the firewall, despite the fact >> that it is logging them. The sipx box does not receive the packets (at >> all.) Both tcpdump and sipXbridge.log show no packets coming from the ITSP >> gateway address (tcpdump does show keepalives we are sending to them every >> 20 seconds.) I can ping the sipx box from pfsense, and I can send >> UDP/5080 packets using netcat which get picked up both by sipxbridge.log >> and by tcpdump. >> >> I'm starting to suspect that the keepalives we're sending might be >> messing up the firewall state table. Is there some way to turn off the >> keepalives since we have a static NAT mapping to allow inbound? Or is >> there a good reason to leave them running? >> >> >> >> >> On Jul 20, 2012, at 15:46 , Tony Graziano wrote: >> >> You will need to make sure the DID call number format in sipx is the >> correct format +1npanxxyyyy 1npanxxyyyy npanxxyyyy etc. >> >> I would look through the sipXbridge log (tail -f) when the call comes in >> to see what is in the invite. >> On Jul 20, 2012 5:11 PM, "Kurt Albershardt" <k...@nv.net> wrote: >> >>> Vitelity sending invites on 5080 now >>> Firewall NAT/PAT reconfigured to forward 5080 to 5080 >>> >>> >>> Firewall says it's sending packets to sipx: >>> >>> Jul 20 14:55:31 NG0 66.241.X.X:5060 192.168.X.24:5080 UDP >>> Jul 20 14:55:29 NG0 66.241.X.X:5060 192.168.X.24:5080 UDP >>> Jul 20 14:55:28 NG0 66.241.X.X:5060 192.168.X.24:5080 UDP >>> Jul 20 14:55:27 NG0 66.241.X.X:5060 192.168.X.24:5080 UDP >>> >>> >>> >>> Nothing hitting the logs (both sipviewer and grepping for the external >>> IP show nothing), and nothing showing in tcpdump other than what appear to >>> be keepalives we are sending to them? >>> >>> root@sipx sipxpbx]# tcpdump host 66.241.X.X >>> tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back >>> to cooked socket >>> tcpdump: verbose output suppressed, use -v or -vv for full protocol >>> decode >>> listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 >>> bytes >>> 15:00:34.923739 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:00:54.924269 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:01:14.923785 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:01:34.924285 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:01:54.923618 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:02:14.924102 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> 15:02:34.923555 IP sipx.domain.com.5080 > 66.241.X.X.sip: SIP, length: 4 >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: helpdesk@voice.myitdepartment.**net<helpd...@voice.myitdepartment.net> >> >> Helpdesk Customers: >> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> >> Blog: http://blog.myitdepartment.net >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpdesk@voice.myitdepartment.**net<helpd...@voice.myitdepartment.net> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> > Blog: http://blog.myitdepartment.net > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
