I tried adding 5090 to the plugin, restarting firewall, and tested. Didn't work same 19.226.0.0 IP.

Then I tried disabling the plugin altogether, restarting firewall, and tested. Still didn't work with same result.

I shouldn't need to restart the system for those changes to go into effect, right?

-James

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.

Reply via email to