Trying adding 5090 to the port list, and reboot. And yes, nf_conntrack_sip and nf_nat_sip *will* rewrite INVITE's.
Though usually only outbound. There's no reason to inbound. On 01/24/2010 07:40 PM, Lonnie Abelbeck wrote: > James, > > I also have a SPA-3102 (voice, no FAX) behind NAT, behind AstLinux 0.7 > --- > SPA-3102 [SIP] > > NAT Support Parameters > Handle VIA received: yes Handle VIA rport: yes > Insert VIA received: yes Insert VIA rport: yes > Substitute VIA Addr: no Send Resp To Src Port: no > STUN Enable: no STUN Test Enable: no > > SPA-3102 [Line 1] > > NAT Settings > NAT Mapping Enable: yes NAT Keep Alive Enable: yes > --- > > I'm running firmware 5.1.7(GW). I see a bunch of changes occurred in 5.1.10 > http://www.cisco.com/en/US/docs/voice_ip_comm/csbpvga/spa3102/release/notes/SPA3102_V5-1-10_RN_OL-19096-01.pdf > > Possibly a SPA-3102 firmware problem? > > In my case, I don't NAT forward to the SPA-3102 (thought shouldn't hurt), and > it works. > > I can't think of anything in AstLinux that would rewrite SIP. > > Lonnie > > > On Jan 24, 2010, at 8:49 PM, James Babiak wrote: > > >> Hey, >> >> Thanks for the assistance everyone. >> . >> The reason why I left 5090 out of the firewall's SIP plugin was because I am >> port forwarding 5090 directly to the ATA to keep Asterisk out of the mix. >> When I initially began testing this, before I made any changes on the ATA or >> Astlinux box, I had the ATA setup to use port 5060, didn't forward any ports >> manually, and had the SIP plugin enabled for 5060. It was only after it not >> working with a standard configuration that I began making tweaks trying to >> get it functional. So having port forwarding turned on/off has no affect. >> And having the sip plugin turned on or off has no effect either. >> >> Based on Lonnie's suggestion, I tried making the changes again, but >> rebooting after each one. Still no change. >> >> What I don't understand is what could be changing the payload of these >> packets? I can understand a firewall configuration (or misconfiguration) >> blocking traffic, or redirecting it. But I did tcpdumps of both eth0 and >> eth1. Both sides are having their packet's contents changed by something >> running on the Asterisk box. And it's not even being changed to something >> valid. It's consistently those two IPs. The RTP IPs come in valid from the >> source, get processed by the box, and then leave with invalid information >> replaced. It makes no sense. The TCP/IP headers stay intact. It's the SIP >> data that is somehow being modified. >> >> Is there anything running inside of Astlinux that is designed to modify >> packet contents like that? >> >> Also, the RTP ports I'm using are not the sames ones that Asterisk is >> configured for. >> >> -James >> >> Philip A. Prindeville wrote: >> >>> Ok, you're misunderstanding how the plugin works. >>> >>> The signaling channel (SIP) terminates on your Asterisk box, and >>> Asterisk stays in the call for its duration. >>> >>> 5060 is the standard SIP port used by Asterisk (and most other SIP PBX's). >>> >>> The plugin configures a netfilter connection-tracker to *also* peer >>> inside SIP packets terminating (or originating) locally to "spy" the SDP >>> (i.e. RTP) information to the end-point addresses and port numbers, and >>> creates NAT "holes" on the fly to facilitate this. >>> >>> Unless you're *also* doing port forwarding of port 5090 directly to the >>> ATA so that it can communicate with outside devices (and not having the >>> Asterisk participate in a leg of the call), this shouldn't be necessary. >>> >>> >>> On 01/24/2010 03:56 PM, James Babiak wrote: >>> >>> >>> >>>> Hey, >>>> >>>> Yes, but only for UDP 5060, as this is the port that Asterisk is >>>> listening on. I have 5090 configured for the ATA, but didn't enable it >>>> in sip-voip.conf, figuring it's just being (supposedly) passed thru >>>> and NAT'd. >>>> >>>> Should I enable it for this port too or disable the plug-in altogether? >>>> >>>> I'll try both now just to test. >>>> >>>> -James >>>> >>>> Philip A. Prindeville wrote: >>>> >>>> >>>> >>>>> Have you enabled /etc/arno-iptables-firewall/plugins/sip-voip.conf ? >>>>> >>>>> >>>>> On 01/24/2010 01:11 PM, James Babiak wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> I'm running into a weird issue, and hopefully someone can assist me in >>>>>> finding out what's going on. >>>>>> >>>>>> I'm running Astlinux 0.7 on a box serving as my router, asterisk box and >>>>>> openvpn server (and a few other things) and I've run into a seemingly >>>>>> very unusual issue. I have an ATA setup behind my Astlinux box that is >>>>>> remotely connecting to a fax server at work running freeswitch. It will >>>>>> be using t.38 and connecting directly to this server, completely >>>>>> bypassing my Astlinux box (outside of it serving as a router+nat). It >>>>>> registers fine, and can make and receive calls. The issue occurs when >>>>>> the rtp is being setup. I discovered the problem because I couldn't get >>>>>> faxes to work at all, even though everyone else had no problem. Even >>>>>> other people behind a similar setup (though not running this version of >>>>>> Astlinux). I noticed in my nat table that my rtp was going from the ATA >>>>>> to 19.226.0.0. Very very unusual. So I started running tcpdump on both >>>>>> eth0 and eth1 (wan and lan respectively). It seems like something in my >>>>>> astlinux box is modifying the contents of the sip packets and changing >>>>>> the rtp IP addresses. Everything from the server on eth0 looks perfect, >>>>>> as does everything from the ATA on eth1. But when I look at eth1 from >>>>>> the server, the rtp address is being set to 19.226.0.0. And when I look >>>>>> at eth0 from the ATA, my rtp address is being set to 10.200.143.207. >>>>>> >>>>>> The specific SIP packet capture in question here from the egress >>>>>> interfaces: (with some slight IP/hostname/phone number obfuscations to >>>>>> protect the innocent ;) ) >>>>>> --==-- >>>>>> 15:23:38.985020 IP (tos 0x68, ttl 249, id 9380, offset 0, flags [none], >>>>>> proto: UDP (17), length: 726) my.public.address.5090 > >>>>>> remote.server.address.5060: SIP, length: 698 >>>>>> SIP/2.0 200 OK >>>>>> To: James Babiak FAX >>>>>> >>>>>> <sip:fax_xx...@remote.server.address> >>>>>> ;tag=63e72d1726ec8327o0 >>>>>> From: >>>>>> <sip:5551...@remote.server.address> >>>>>> ;tag=0aDa2FSmFDScc >>>>>> Call-ID: >>>>>> f12527d7-85e8c...@172.20.0.145 >>>>>> >>>>>> CSeq: 126063973 INVITE >>>>>> Via: SIP/2.0/UDP >>>>>> remote.server.address;branch=z9hG4bKKeXpa1my0UF0r >>>>>> Contact: James Babiak FAX >>>>>> <sip:fax_xx...@remote.server.address:5090> >>>>>> >>>>>> Server: Linksys/SPA3102-5.1.10(GW) >>>>>> Content-Length: 269 >>>>>> Content-Type: application/sdp >>>>>> >>>>>> v=0 >>>>>> o=- 128599 128599 IN IP4 10.200.143.207 >>>>>> s=- >>>>>> c=IN IP4 10.200.143.207 >>>>>> t=0 0 >>>>>> m=image 16434 udptl t38 >>>>>> a=T38FaxVersion:0 >>>>>> a=T38MaxBitRate:14400 >>>>>> a=T38FaxRateManagement:transferredTCF >>>>>> a=T38FaxMaxBuffer:200 >>>>>> a=T38FaxMaxDatagram:200 >>>>>> a=T38FaxUdpEC:t38UDPRedundancy >>>>>> --==-- >>>>>> and >>>>>> --==-- >>>>>> 15:19:24.575373 IP (tos 0x20, ttl 50, id 57433, offset 0, flags [none], >>>>>> proto: UDP (17), length: 1084) remote.server.address.5060 > >>>>>> SipuraSPA.routed.com.5090: SIP, length: 1056 >>>>>> INVITE >>>>>> sip:fax_xx...@172.20.0.145:5090 >>>>>> SIP/2.0 >>>>>> Via: SIP/2.0/UDP 38.101.17.105;rport;branch=z9hG4bKFarK3mHgcrpNa >>>>>> Max-Forwards: 70 >>>>>> From: >>>>>> <sip:xx...@remote.server.address> >>>>>> ;tag=e416y1XHNr42g >>>>>> To: James Babiak FAX >>>>>> >>>>>> <sip:fax_xx...@remote.server.address> >>>>>> ;tag=74f688c7b624f7dao0 >>>>>> Call-ID: >>>>>> 91cd090b-14d4d...@172.20.0.145 >>>>>> >>>>>> CSeq: 126063846 INVITE >>>>>> Contact: >>>>>> <sip:5551...@remote.server.address:5060;transport=udp> >>>>>> >>>>>> User-Agent: Star2Star Media >>>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, >>>>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE >>>>>> Supported: timer, precondition, path, replaces >>>>>> Session-Expires: 120;refresher=uac >>>>>> Min-SE: 120 >>>>>> Content-Type: application/sdp >>>>>> Content-Disposition: session >>>>>> Content-Length: 316 >>>>>> X-FS-Support: update_display >>>>>> >>>>>> v=0 >>>>>> o=Sonus_UAC 2924581275921585578 5556846930163024566 IN IP4 >>>>>> 19.226.0.0 >>>>>> s=SIP Media Capabilities >>>>>> c=IN IP4 19.226.0.0 >>>>>> t=0 0 >>>>>> m=image 11692 udptl t38 >>>>>> a=T38FaxVersion:0 >>>>>> a=T38MaxBitRate:14400 >>>>>> a=T38FaxRateManagement:transferredTCF >>>>>> a=T38FaxMaxBuffer:262 >>>>>> a=T38FaxMaxDatagram:176 >>>>>> a=T38FaxUdpEC:t38UDPRedundancy >>>>>> --==-- >>>>>> >>>>>> But like I said, the corresponding packets on the ingress interface does >>>>>> not reflect those above IP addresses. They have the proper ones. So >>>>>> something internal is changing them. I've spent hours trying to find >>>>>> some firewall rule/setting I needed to change, and even went so far as >>>>>> to disable everything that wasn't 'standard', but nothing works. I've >>>>>> tried changing SIP ports for the ATA, setting up port forwarding, etc. >>>>>> etc., but still no go. The remote freeswitch side seems to be ignoring >>>>>> my invalid IP, since the ATA still receives inbound audio, just no >>>>>> outbound audio. >>>>>> >>>>>> Everything else, IP's included, in the SIP packets are fine. It only >>>>>> breaks after the call is setup. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Thanks >>>>>> >>>>>> -James >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
