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. |
------------------------------------------------------------------------------ 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.