All of lore.kernel.org
 help / color / mirror / Atom feed
* Try to NAT a RTP stream
@ 2003-04-27  6:24 Nils Ohlmeier
  2003-04-30  3:26 ` Tom Marshall
  0 siblings, 1 reply; 6+ messages in thread
From: Nils Ohlmeier @ 2003-04-27  6:24 UTC (permalink / raw)
  To: netfilter

Hello,

i try to NAT RTP streams with my own application (i do not use iptables to 
insert the rules -> should i go to netfilter-devel?).

Scenario:
192.168.0.114 <-----> 192.168.0.2
                      Netfilter NAT
                     217.224.223.167 <--------------> 195.37.77.110

The result is that packets go from private to public but not vice versa. And 
the ruleset looks like this (empty chains omitted, ruleset is only for 
debuging, masquerade rule is for keeping my existing connections):

Chain FORWARD (policy ACCEPT 237 packets, 47356 bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 ACCEPT     udp  --  *      *       195.37.77.110        
192.168.0.114      udp spts:18554:18555 dpts:8766:8767
  399 79648 ACCEPT     udp  --  *      *       192.168.0.114        
195.37.77.110      udp spts:8766:8767 dpts:18554:18555

Chain PREROUTING (policy ACCEPT 3481 packets, 552K bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 DNAT       udp  --  *      *       195.37.77.110        
217.224.223.167    udp spts:18554:18555 dpts:32790:32791 
to:192.168.0.114:8766-8767

Chain POSTROUTING (policy ACCEPT 660 packets, 52480 bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 SNAT       udp  --  *      *       192.168.0.114        
195.37.77.110      udp spts:8766:8767 dpts:18554:18555 
to:217.224.223.167:32790-32791
    9  1835 MASQUERADE  all  --  *      *       192.168.0.0/23       0.0.0.0/0

What i do not understand is why the packets from internal hit the rule in 
FORWARD but do not hit the same rule in POSTROUTING.
The second strange thing is that packets come in on the external interface 
(observed with ngrep) but to not hit the PREROUTING rule.
I fear i missed something obvious :-(

Any help/ideas appreciated.

Greetings
  Nils Ohlmeier


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Try to NAT a RTP stream
  2003-04-27  6:24 Try to NAT a RTP stream Nils Ohlmeier
@ 2003-04-30  3:26 ` Tom Marshall
  2003-04-30 11:12   ` Michael J. Tubby B.Sc. (Hons) G8TIC
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Marshall @ 2003-04-30  3:26 UTC (permalink / raw)
  To: Nils Ohlmeier; +Cc: netfilter

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

What application are you using to setup the RTP stream?  If you are using
RTSP, I posted an RTSP NAT module for kernel 2.4.21-preX a couple of weeks
ago that may solve your problem.

On Sun, Apr 27, 2003 at 08:24:31AM +0200, Nils Ohlmeier wrote:
> Hello,
> 
> i try to NAT RTP streams with my own application (i do not use iptables to 
> insert the rules -> should i go to netfilter-devel?).
> 
> Scenario:
> 192.168.0.114 <-----> 192.168.0.2
>                       Netfilter NAT
>                      217.224.223.167 <--------------> 195.37.77.110
> 
> The result is that packets go from private to public but not vice versa. And 
> the ruleset looks like this (empty chains omitted, ruleset is only for 
> debuging, masquerade rule is for keeping my existing connections):
> 
> Chain FORWARD (policy ACCEPT 237 packets, 47356 bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 ACCEPT     udp  --  *      *       195.37.77.110        
> 192.168.0.114      udp spts:18554:18555 dpts:8766:8767
>   399 79648 ACCEPT     udp  --  *      *       192.168.0.114        
> 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> 
> Chain PREROUTING (policy ACCEPT 3481 packets, 552K bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 DNAT       udp  --  *      *       195.37.77.110        
> 217.224.223.167    udp spts:18554:18555 dpts:32790:32791 
> to:192.168.0.114:8766-8767
> 
> Chain POSTROUTING (policy ACCEPT 660 packets, 52480 bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 SNAT       udp  --  *      *       192.168.0.114        
> 195.37.77.110      udp spts:8766:8767 dpts:18554:18555 
> to:217.224.223.167:32790-32791
>     9  1835 MASQUERADE  all  --  *      *       192.168.0.0/23       0.0.0.0/0
> 
> What i do not understand is why the packets from internal hit the rule in 
> FORWARD but do not hit the same rule in POSTROUTING.
> The second strange thing is that packets come in on the external interface 
> (observed with ngrep) but to not hit the PREROUTING rule.
> I fear i missed something obvious :-(
> 
> Any help/ideas appreciated.
> 
> Greetings
>   Nils Ohlmeier

-- 
Guilty until proven innocent: abusing the legal system in the name of the
war on terror.  http://www.wired.com/news/conflict/0,2100,58326,00.html

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Try to NAT a RTP stream
  2003-04-30  3:26 ` Tom Marshall
@ 2003-04-30 11:12   ` Michael J. Tubby B.Sc. (Hons) G8TIC
  2003-04-30 14:28     ` Tom Marshall
  0 siblings, 1 reply; 6+ messages in thread
From: Michael J. Tubby B.Sc. (Hons) G8TIC @ 2003-04-30 11:12 UTC (permalink / raw)
  To: Tom Marshall, Nils Ohlmeier; +Cc: netfilter

Tom,

I also want to get NAT of RTP/RTSP working for Cisco (Selsius)
Voice over IP (VOIP), ie. a Cisco/Selsius phone on the inside NAT'ted
out to a Cisco Call Manager (CCM).

The phone uses a TCP connection on port 2000 for Skinny Client
Control Protocol (SCCP) to the CCM (SCCP is beleived to be based
on an ASN1 derrived version of ISDN Q.931 signalling) to setup/
clear down calls and RTS/RTSP traffic for the duration of the actual
call.

Again, the problem is that the outgoing RTP/RTSP (which is really UDP
with a particular ToS value - 0xB8 if I remember my tcpdumps correctly)
works fine with current NAT but the inbound replies which are on an
unrelated port number fail.

I suspect that this means that a contrack_sccp module would be required
to watch the SCCP/ASN1 on port 2000 and prime in the inbound NAT
of the subsequent RTS/RTSP ?

Mike


----- Original Message -----
From: "Tom Marshall" <tommy@home.tig-grr.com>
To: "Nils Ohlmeier" <lists@ohlmeier.de>
Cc: <netfilter@lists.netfilter.org>
Sent: Wednesday, April 30, 2003 4:26 AM
Subject: Re: Try to NAT a RTP stream

What application are you using to setup the RTP stream?  If you are using
RTSP, I posted an RTSP NAT module for kernel 2.4.21-preX a couple of weeks
ago that may solve your problem.

On Sun, Apr 27, 2003 at 08:24:31AM +0200, Nils Ohlmeier wrote:
> Hello,
>
> i try to NAT RTP streams with my own application (i do not use iptables to
> insert the rules -> should i go to netfilter-devel?).
>
> Scenario:
> 192.168.0.114 <-----> 192.168.0.2
>                       Netfilter NAT
>                      217.224.223.167 <--------------> 195.37.77.110
>
> The result is that packets go from private to public but not vice versa.
And
> the ruleset looks like this (empty chains omitted, ruleset is only for
> debuging, masquerade rule is for keeping my existing connections):
>
> Chain FORWARD (policy ACCEPT 237 packets, 47356 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 ACCEPT     udp  --  *      *       195.37.77.110
> 192.168.0.114      udp spts:18554:18555 dpts:8766:8767
>   399 79648 ACCEPT     udp  --  *      *       192.168.0.114
> 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
>
> Chain PREROUTING (policy ACCEPT 3481 packets, 552K bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 DNAT       udp  --  *      *       195.37.77.110
> 217.224.223.167    udp spts:18554:18555 dpts:32790:32791
> to:192.168.0.114:8766-8767
>
> Chain POSTROUTING (policy ACCEPT 660 packets, 52480 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 SNAT       udp  --  *      *       192.168.0.114
> 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> to:217.224.223.167:32790-32791
>     9  1835 MASQUERADE  all  --  *      *       192.168.0.0/23
0.0.0.0/0
>
> What i do not understand is why the packets from internal hit the rule in
> FORWARD but do not hit the same rule in POSTROUTING.
> The second strange thing is that packets come in on the external interface
> (observed with ngrep) but to not hit the PREROUTING rule.
> I fear i missed something obvious :-(
>
> Any help/ideas appreciated.
>
> Greetings
>   Nils Ohlmeier



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Try to NAT a RTP stream
  2003-04-30 11:12   ` Michael J. Tubby B.Sc. (Hons) G8TIC
@ 2003-04-30 14:28     ` Tom Marshall
  2003-05-01  9:17       ` Michael J. Tubby B.Sc. (Hons) G8TIC
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Marshall @ 2003-04-30 14:28 UTC (permalink / raw)
  To: Michael J. Tubby B.Sc. (Hons) G8TIC; +Cc: Nils Ohlmeier, netfilter

[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]

I'm sorry, but your message does not quite make sense to me.  Keep in mind
that RTP and RTSP are two very different protocols.  RTSP is a TCP based
protocol that looks quite similar to HTTP.  It is used to control the media
data streams.  It has methods like setup, play, pause, teardown.  RTP is a
UDP based protocol that is used to communicate media (eg. audio and video)
packets.  It's unfortunate that they have such similar abbreviations.

If your application is using SCCP to setup the RTP data stream, then yes, it
would appear that ip_conntrack_sccp and ip_nat_sccp modules are required.

On Wed, Apr 30, 2003 at 12:12:15PM +0100, Michael J. Tubby B.Sc. (Hons) G8TIC wrote:
> Tom,
> 
> I also want to get NAT of RTP/RTSP working for Cisco (Selsius)
> Voice over IP (VOIP), ie. a Cisco/Selsius phone on the inside NAT'ted
> out to a Cisco Call Manager (CCM).
> 
> The phone uses a TCP connection on port 2000 for Skinny Client
> Control Protocol (SCCP) to the CCM (SCCP is beleived to be based
> on an ASN1 derrived version of ISDN Q.931 signalling) to setup/
> clear down calls and RTS/RTSP traffic for the duration of the actual
> call.
> 
> Again, the problem is that the outgoing RTP/RTSP (which is really UDP
> with a particular ToS value - 0xB8 if I remember my tcpdumps correctly)
> works fine with current NAT but the inbound replies which are on an
> unrelated port number fail.
> 
> I suspect that this means that a contrack_sccp module would be required
> to watch the SCCP/ASN1 on port 2000 and prime in the inbound NAT
> of the subsequent RTS/RTSP ?
> 
> Mike
> 
> 
> ----- Original Message -----
> From: "Tom Marshall" <tommy@home.tig-grr.com>
> To: "Nils Ohlmeier" <lists@ohlmeier.de>
> Cc: <netfilter@lists.netfilter.org>
> Sent: Wednesday, April 30, 2003 4:26 AM
> Subject: Re: Try to NAT a RTP stream
> 
> What application are you using to setup the RTP stream?  If you are using
> RTSP, I posted an RTSP NAT module for kernel 2.4.21-preX a couple of weeks
> ago that may solve your problem.
> 
> On Sun, Apr 27, 2003 at 08:24:31AM +0200, Nils Ohlmeier wrote:
> > Hello,
> >
> > i try to NAT RTP streams with my own application (i do not use iptables to
> > insert the rules -> should i go to netfilter-devel?).
> >
> > Scenario:
> > 192.168.0.114 <-----> 192.168.0.2
> >                       Netfilter NAT
> >                      217.224.223.167 <--------------> 195.37.77.110
> >
> > The result is that packets go from private to public but not vice versa.
> And
> > the ruleset looks like this (empty chains omitted, ruleset is only for
> > debuging, masquerade rule is for keeping my existing connections):
> >
> > Chain FORWARD (policy ACCEPT 237 packets, 47356 bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 ACCEPT     udp  --  *      *       195.37.77.110
> > 192.168.0.114      udp spts:18554:18555 dpts:8766:8767
> >   399 79648 ACCEPT     udp  --  *      *       192.168.0.114
> > 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> >
> > Chain PREROUTING (policy ACCEPT 3481 packets, 552K bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 DNAT       udp  --  *      *       195.37.77.110
> > 217.224.223.167    udp spts:18554:18555 dpts:32790:32791
> > to:192.168.0.114:8766-8767
> >
> > Chain POSTROUTING (policy ACCEPT 660 packets, 52480 bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 SNAT       udp  --  *      *       192.168.0.114
> > 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> > to:217.224.223.167:32790-32791
> >     9  1835 MASQUERADE  all  --  *      *       192.168.0.0/23
> 0.0.0.0/0
> >
> > What i do not understand is why the packets from internal hit the rule in
> > FORWARD but do not hit the same rule in POSTROUTING.
> > The second strange thing is that packets come in on the external interface
> > (observed with ngrep) but to not hit the PREROUTING rule.
> > I fear i missed something obvious :-(
> >
> > Any help/ideas appreciated.
> >
> > Greetings
> >   Nils Ohlmeier

-- 
Guilty until proven innocent: abusing the legal system in the name of the
war on terror.  http://www.wired.com/news/conflict/0,2100,58326,00.html

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Try to NAT a RTP stream
  2003-04-30 14:28     ` Tom Marshall
@ 2003-05-01  9:17       ` Michael J. Tubby B.Sc. (Hons) G8TIC
  2003-05-02  6:55         ` IP-tables with authentication Yogesh Talekar (M.T.S.@C.N.C.)
  0 siblings, 1 reply; 6+ messages in thread
From: Michael J. Tubby B.Sc. (Hons) G8TIC @ 2003-05-01  9:17 UTC (permalink / raw)
  To: Tom Marshall; +Cc: Nils Ohlmeier, netfilter

Tom,

Sorry - my last post wasn't very clear :-(

Yes, I think we're agreed - for Cisco VOIP to work through a Linux
NAT box what is needed is ip_conntrack_sccp and ip_nat_sccp modules.

It is interesting to note that Cisco VOIP (SCCP + RTP) only works
correctly through a Cisco IOS 12.2.xx box running as a NAT router if
you enable support for RTSP, for example:

    ip inspect name myfw rtsp timeout 5

there is no direct support for SCCP in IOS which I find odd.

Mike


[PS. why do your postings come through as AT000nnn.TXT ???]




I'm sorry, but your message does not quite make sense to me.  Keep in mind
that RTP and RTSP are two very different protocols.  RTSP is a TCP based
protocol that looks quite similar to HTTP.  It is used to control the media
data streams.  It has methods like setup, play, pause, teardown.  RTP is a
UDP based protocol that is used to communicate media (eg. audio and video)
packets.  It's unfortunate that they have such similar abbreviations.

If your application is using SCCP to setup the RTP data stream, then yes, it
would appear that ip_conntrack_sccp and ip_nat_sccp modules are required.





On Wed, Apr 30, 2003 at 12:12:15PM +0100, Michael J. Tubby B.Sc. (Hons)
G8TIC wrote:
> Tom,
>
> I also want to get NAT of RTP/RTSP working for Cisco (Selsius)
> Voice over IP (VOIP), ie. a Cisco/Selsius phone on the inside NAT'ted
> out to a Cisco Call Manager (CCM).
>
> The phone uses a TCP connection on port 2000 for Skinny Client
> Control Protocol (SCCP) to the CCM (SCCP is beleived to be based
> on an ASN1 derrived version of ISDN Q.931 signalling) to setup/
> clear down calls and RTS/RTSP traffic for the duration of the actual
> call.
>
> Again, the problem is that the outgoing RTP/RTSP (which is really UDP
> with a particular ToS value - 0xB8 if I remember my tcpdumps correctly)
> works fine with current NAT but the inbound replies which are on an
> unrelated port number fail.
>
> I suspect that this means that a contrack_sccp module would be required
> to watch the SCCP/ASN1 on port 2000 and prime in the inbound NAT
> of the subsequent RTS/RTSP ?
>
> Mike
>
>
> ----- Original Message -----
> From: "Tom Marshall" <tommy@home.tig-grr.com>
> To: "Nils Ohlmeier" <lists@ohlmeier.de>
> Cc: <netfilter@lists.netfilter.org>
> Sent: Wednesday, April 30, 2003 4:26 AM
> Subject: Re: Try to NAT a RTP stream
>
> What application are you using to setup the RTP stream?  If you are using
> RTSP, I posted an RTSP NAT module for kernel 2.4.21-preX a couple of weeks
> ago that may solve your problem.
>
> On Sun, Apr 27, 2003 at 08:24:31AM +0200, Nils Ohlmeier wrote:
> > Hello,
> >
> > i try to NAT RTP streams with my own application (i do not use iptables
to
> > insert the rules -> should i go to netfilter-devel?).
> >
> > Scenario:
> > 192.168.0.114 <-----> 192.168.0.2
> >                       Netfilter NAT
> >                      217.224.223.167 <--------------> 195.37.77.110
> >
> > The result is that packets go from private to public but not vice versa.
> And
> > the ruleset looks like this (empty chains omitted, ruleset is only for
> > debuging, masquerade rule is for keeping my existing connections):
> >
> > Chain FORWARD (policy ACCEPT 237 packets, 47356 bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 ACCEPT     udp  --  *      *       195.37.77.110
> > 192.168.0.114      udp spts:18554:18555 dpts:8766:8767
> >   399 79648 ACCEPT     udp  --  *      *       192.168.0.114
> > 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> >
> > Chain PREROUTING (policy ACCEPT 3481 packets, 552K bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 DNAT       udp  --  *      *       195.37.77.110
> > 217.224.223.167    udp spts:18554:18555 dpts:32790:32791
> > to:192.168.0.114:8766-8767
> >
> > Chain POSTROUTING (policy ACCEPT 660 packets, 52480 bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >     0     0 SNAT       udp  --  *      *       192.168.0.114
> > 195.37.77.110      udp spts:8766:8767 dpts:18554:18555
> > to:217.224.223.167:32790-32791
> >     9  1835 MASQUERADE  all  --  *      *       192.168.0.0/23
> 0.0.0.0/0
> >
> > What i do not understand is why the packets from internal hit the rule
in
> > FORWARD but do not hit the same rule in POSTROUTING.
> > The second strange thing is that packets come in on the external
interface
> > (observed with ngrep) but to not hit the PREROUTING rule.
> > I fear i missed something obvious :-(
> >
> > Any help/ideas appreciated.
> >
> > Greetings
> >   Nils Ohlmeier

--
Guilty until proven innocent: abusing the legal system in the name of the
war on terror.  http://www.wired.com/news/conflict/0,2100,58326,00.html



^ permalink raw reply	[flat|nested] 6+ messages in thread

* IP-tables with authentication
  2003-05-01  9:17       ` Michael J. Tubby B.Sc. (Hons) G8TIC
@ 2003-05-02  6:55         ` Yogesh Talekar (M.T.S.@C.N.C.)
  0 siblings, 0 replies; 6+ messages in thread
From: Yogesh Talekar (M.T.S.@C.N.C.) @ 2003-05-02  6:55 UTC (permalink / raw)
  To: netfilter

hi

Is this possible ...

I have a IP-tables firewall on a machine "A". I have LDAP database on 
machine "B". And I want all the traffic going out of my firewall(A) to be 
authenticated against this LDAP server(B).

Consider following scenario (network diagram)...

********************************FIGURE********************************

Internet <--> Router (realIP-X.X.X.254) <--> Linux FW (Bridge-No IP) 
					|	
					|
					|
		------------------ switch---------------
		|			|		|
	LDAP Server(X.X.X.100)		|		|
	     			     server-1	    server-2
			(RealIP-X.X.X.10)    	(RealIP-X.X.X.3)
			(FakeIP-192.168.1.X) 	(FakeIP-192.168.2.X
				|
				|
				|
				Intranet

**********************************************************************

The question is, can I keep log and count the traffic per user if he 
(from Intranet) uses any type of service (http,ssh,telnet,ftp) via the 
Linux firewall. And Can I authenticate this user against the LDAP server 
(which has a realIP)

Please advice

--yogesh



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-05-02  6:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-27  6:24 Try to NAT a RTP stream Nils Ohlmeier
2003-04-30  3:26 ` Tom Marshall
2003-04-30 11:12   ` Michael J. Tubby B.Sc. (Hons) G8TIC
2003-04-30 14:28     ` Tom Marshall
2003-05-01  9:17       ` Michael J. Tubby B.Sc. (Hons) G8TIC
2003-05-02  6:55         ` IP-tables with authentication Yogesh Talekar (M.T.S.@C.N.C.)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.