[c-nsp] PIX NAT traversal issue
FAHAD ALI KHAN
fahad.alikhan at gmail.com
Fri Nov 17 04:24:23 EST 2006
Well Oliver
I have already define fixup for h323 and h225 over port 80 and RTP for
49152-65535
fixup protocol h323 h225 80
fixup protocol rtsp 49152-65535
And i dont want my internal traffic to use HTTP traffic....no worries of
it....but the main issue is still unresolved and im unable to understand
that.....why Internet IP returning traffic towards NAT inside address
instead of NAT outside address.
kindly check the log....
305005: No translation group found for udp src outside:Source-IP
(A.A.A.A)/49152
dst inside:192.168.0.2/49158
On 11/17/06, Oliver Dewdney <oliver.dewdney at lbicon.co.uk> wrote:
>
> i beleive the fixup config lines do the magic of opening the rtp ports,
> and
> doing packet re-writes to fix up the dst address in the h323 response to
> translate it to the external address. running it over port 80 will mean
> that
> it will be confused with http traffic - except you have switched off that
> fixup.
>
> i think you could put:
>
> fixup protocol h323 h225 80
>
> in, but i dont know what that will do to other typical traffic (http?)
> over
> port 80.
>
> Oli Dewdney.
>
> -----Original Message-----
> From: FAHAD ALI KHAN [mailto:fahad.alikhan at gmail.com]
> Sent: 17 November 2006 05:06
> To: James Sneeringer
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] PIX NAT traversal issue
>
>
> Well Guys
>
> Here is a little more detail of my test....and ACL is set perfectly...but
> checkout my findings....!
>
> *Background:*
>
> im trying to implement a scenario but got stucked in a problem, here is my
> scenario.
>
> Internet -- (H323 call on port X) -- PIX -- (H323 call PAT to 1720) -- PC
> (
> 192.168.0.2 : running H323 softphone)
>
> My task is to generate H323 call on port 80 from Internet and it will be
> translated to 1720 on my PIX and connect to PC H323 application.
>
> I have successfully configured this using static NAT as
>
> *static (inside,outside) tcp X.X.X.X 80 192.168.0.2 1720 nemask
> 255.255.255.255
> 0 0*
> **
> Call has been successfully terminated from internet to my PC but i got
> stucked in NAT traversal issue (as i found it on internet).
> This call is one way only i.e. voice media (RTP) packets goes only from
> inside to outside but not vice versa.
>
> Can you check the PIX configuration and help me to solve this issue....i
> have Cisco PIX 515 running 6.3(5)
>
> PIX Version 6.3(5)
> nameif ethernet0 outside security0
> nameif ethernet1 inside security100
> enable password 8Ry2YjIyt7RRXU24 encrypted
> passwd 2KFQnbNIdI.2KYOU encrypted
> hostname PIX
> fixup protocol ftp 21
> no fixup protocol http 80
> fixup protocol ils 389
> fixup protocol rsh 514
> fixup protocol rtsp 554
> fixup protocol smtp 25
> fixup protocol sqlnet 1521
> fixup protocol sip 5060
> fixup protocol skinny 2000
> fixup protocol h323 ras 1718-1719
> no fixup protocol h323 h225 1720
> fixup protocol h323 h225 80
> fixup protocol rtsp 49152-65535
> fixup protocol sip udp 5060
> names
> access-list 101 permit icmp any any
> access-list 101 permit udp any host X.X.X.X gt 1024
> access-list 101 permit tcp any host X.X.X.X eq 80
> access-list 101 permit ip any host X.X.X.X
> access-list 101 deny ip any any log 7
> pager lines 24
> interface ethernet0 auto
> interface ethernet1 auto
> mtu outside 1500
> mtu inside 1500
> ip address outside X.X.X.Y 255.255.255.248
> ip address inside 192.168.0.1 255.255.255.248
> ip audit info action alarm
> ip audit attack action alarm
> pdm history enable
> arp timeout 14400
> global (outside) 1 X.X.X.X
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> static (inside,outside) tcp X.X.X.X 80 192.168.0.2 1720 netmask
> 255.255.255.255 0 0
> access-group 101 in interface outside
> route outside 0.0.0.0 0.0.0.0 X.X.X.W 1
> timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
> 0:05:00 sip 0:30:00 sip_media 0:02:00
> timeout uauth 0:01:00 absolute
> timeout xlate 0:01:00
> telnet 192.168.0.0 255.255.255.0 inside
> telnet timeout 5
> end
>
>
> The issue i diagnose from logs is that, the RTP traffic (UDP) is comming
> from internet IP to inside NAT IP (private one) not on the public IP.
>
> PIX# sh access-list 101
> access-list 101; 5 elements
> access-list 101 line 1 permit icmp any any (hitcnt=0)
> access-list 101 line 2 permit udp any host X.X.X.X gt 1024 (hitcnt=0)
> access-list 101 line 3 permit tcp any host X.X.X.X eq www (hitcnt=1)
> access-list 101 line 4 permit ip any host X.X.X.X (hitcnt=0)
> access-list 101 line 5 deny ip any any log 7 (hitcnt=20104)
>
> and the los proof that....
>
> sh logs
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP (
> A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP (
> A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP (
> A.A.A.A)/49152
> dst inside:192.168.0.2/49158
> 305005: No translation group found for udp src outside:Source-IP
> (A.A.A.A)/49152
> dst inside:192.168.0.2/49158
>
> but it is really hard to tell how why the UDP RTP traffic is comming
> towards
> PIX with destination address of 192.168.0.2...it has to be X.X.X.X. But
> this
> is the main issue....!
>
> I think, When H323 session is negotiated and Media capabilities are
> exchanged than PC sends its local (pirvate) address to send RTP pckts.
> well
> Error says i have to provide the Translation group than RTP ports are not
> fixed and normally range from 4500 to 65535 so how can i define the STATIC
> NAT or other to map these ports to my NAT outside and inside IPs.
>
> Kindly can u suggest any solution.
>
>
> Regards
>
> Fahad
>
>
> On 11/14/06, James Sneeringer <jsneeringer at jupiterimages.com> wrote:
> >
> > On November 14, 2006, FAHAD ALI KHAN wrote:
> > > I have successfully configured this using static NAT as
> > >
> > > *static (inside,outside) tcp X.X.X.X 80 Z.Z.Z.Z 1720 nemask
> > > 255.255.255.2550 0
> > > *
> > > **
> > > Call has been successfully terminated from internet to my PC
> > > but i got stucked in NAT traversal issue (as i found it on internet).
> > > This call is one way only i.e. voice media packets goes only
> > > from inside to outside but not vice versa.
> >
> > You probably need to put an access-list on the outside interface to
> > allow inbound traffic on port 80. The static entry only affects NAT
> > and does not do anything with security policy. Maybe something like
> > this:
> >
> > access-list acl_outside permit tcp any host X.X.X.X eq 80
> > access-group acl_outside in interface outside
> >
> > -James
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> This e-mail is only intended for the person(s) to whom it is addressed and
> may contain confidential information. LBi does not accept responsibility
> for
> any loss or damage caused by this email or any attachments. Unless clearly
> stated to the contrary, any opinions or comments are personal to the
> writer
> and are not made on behalf of LBi. If you have received this e-mail in
> error, please notify us immediately at info at lbicon.co.uk and then delete
> this message from your system. Please do not copy it or use it for any
> purposes, or disclose its contents to any other person. Thank you for your
> co-operation.
>
> LBi is the business name of Aspect Internet Holdings Limited, Aspect
> Technologies Limited, LB Icon Limited and Escador Limited.
>
More information about the cisco-nsp
mailing list