All of lore.kernel.org
 help / color / mirror / Atom feed
* advanced routing with NAT: returning UDP traffic
@ 2014-09-23 12:46 Maarten
  2014-09-23 17:41 ` Eliezer Croitoru
  0 siblings, 1 reply; 9+ messages in thread
From: Maarten @ 2014-09-23 12:46 UTC (permalink / raw)
  To: netfilter

Hi,

until now, i've done multiple ISPs with nexthop default route, 2 extra tables, 
ip rule and TCP connmark.

but, how does this involve UDP traffic...

if for example i have in my NAT LAN an NTP server, how would i get the udp 
packet out the same interface where it was originally coming in from?

please advise...

Maarten
-- 
BA NV
IT & Security

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-23 12:46 advanced routing with NAT: returning UDP traffic Maarten
@ 2014-09-23 17:41 ` Eliezer Croitoru
  2014-09-24  9:35   ` Maarten Vanraes
  0 siblings, 1 reply; 9+ messages in thread
From: Eliezer Croitoru @ 2014-09-23 17:41 UTC (permalink / raw)
  To: Maarten, netfilter

Hey Maarten,

As long as I remember conntrack and conntrack are working together.
Which means that udp traffic will be distinguished the same way as TCP 
as long the connection tracking categorized it under the same connection 
stream.
(I think for unestablished connection 30 secs and more for an 
"established" one)

Eliezer

On 09/23/2014 03:46 PM, Maarten wrote:
> Hi,
>
> until now, i've done multiple ISPs with nexthop default route, 2 extra tables,
> ip rule and TCP connmark.
>
> but, how does this involve UDP traffic...
>
> if for example i have in my NAT LAN an NTP server, how would i get the udp
> packet out the same interface where it was originally coming in from?
>
> please advise...
>
> Maarten


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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-23 17:41 ` Eliezer Croitoru
@ 2014-09-24  9:35   ` Maarten Vanraes
  2014-09-24  9:49     ` Pascal Hambourg
  0 siblings, 1 reply; 9+ messages in thread
From: Maarten Vanraes @ 2014-09-24  9:35 UTC (permalink / raw)
  To: Eliezer Croitoru; +Cc: netfilter

conntrack and conntrack ? i'm assuming this is a typo?

so, even some kind of odd udp reply will still be the same connection if it's 
within 30seconds?

so, i can use connmark on not just TCP, but on all protocols?

Regards,

Maarten

Op dinsdag 23 september 2014 20:41:08 schreef Eliezer Croitoru:
> Hey Maarten,
> 
> As long as I remember conntrack and conntrack are working together.
> Which means that udp traffic will be distinguished the same way as TCP
> as long the connection tracking categorized it under the same connection
> stream.
> (I think for unestablished connection 30 secs and more for an
> "established" one)
> 
> Eliezer
> 
> On 09/23/2014 03:46 PM, Maarten wrote:
> > Hi,
> > 
> > until now, i've done multiple ISPs with nexthop default route, 2 extra
> > tables, ip rule and TCP connmark.
> > 
> > but, how does this involve UDP traffic...
> > 
> > if for example i have in my NAT LAN an NTP server, how would i get the udp
> > packet out the same interface where it was originally coming in from?
> > 
> > please advise...
> > 
> > Maarten
-- 
BA NV
IT & Security

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-24  9:35   ` Maarten Vanraes
@ 2014-09-24  9:49     ` Pascal Hambourg
  2014-09-24 10:16       ` Maarten Vanraes
  0 siblings, 1 reply; 9+ messages in thread
From: Pascal Hambourg @ 2014-09-24  9:49 UTC (permalink / raw)
  To: Maarten Vanraes; +Cc: netfilter

Maarten Vanraes a écrit :
> 
> so, even some kind of odd udp reply will still be the same connection if it's 
> within 30seconds?

Not odd. The reply packet has to match the addresses and ports in the
original packet (with source and destination swapped).

> so, i can use connmark on not just TCP, but on all protocols?

Not all protocols, but any protocol implementation which behaves in the
way expected by conntrack.

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-24  9:49     ` Pascal Hambourg
@ 2014-09-24 10:16       ` Maarten Vanraes
  2014-09-24 12:38         ` Eliezer Croitoru
  0 siblings, 1 reply; 9+ messages in thread
From: Maarten Vanraes @ 2014-09-24 10:16 UTC (permalink / raw)
  To: Pascal Hambourg; +Cc: netfilter

Op woensdag 24 september 2014 11:49:02 schreef Pascal Hambourg:
> Maarten Vanraes a écrit :
> > so, even some kind of odd udp reply will still be the same connection if
> > it's within 30seconds?
> 
> Not odd. The reply packet has to match the addresses and ports in the
> original packet (with source and destination swapped).
> 
> > so, i can use connmark on not just TCP, but on all protocols?
> 
> Not all protocols, but any protocol implementation which behaves in the
> way expected by conntrack.

ok, thanks,

so, this is why streaming/voip stuff will still have issues...
-- 
BA NV
IT & Security

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-24 10:16       ` Maarten Vanraes
@ 2014-09-24 12:38         ` Eliezer Croitoru
  2014-09-24 12:52           ` Maarten Vanraes
  0 siblings, 1 reply; 9+ messages in thread
From: Eliezer Croitoru @ 2014-09-24 12:38 UTC (permalink / raw)
  To: Maarten Vanraes, Pascal Hambourg; +Cc: netfilter

On 09/24/2014 01:16 PM, Maarten Vanraes wrote:
> ok, thanks,
>
> so, this is why streaming/voip stuff will still have issues...
Yes indeed.
and I Meant conntrack and connmark...
VOIP and STREAMING are beasts!!!
There are modules which analyze them and also recognize them but you 
will need to enable them first.

The issue is not UDP by itself as you understand.
It's a well known issue with multi IP nat machines in ISPS.
In many cases a SIP proxy helps to fix couple things.
I haven't tried it yet but it seems like there are commercial products 
that implement these SIP proxy.

Eliezer

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-24 12:38         ` Eliezer Croitoru
@ 2014-09-24 12:52           ` Maarten Vanraes
  2014-09-26 13:18             ` Pascal Hambourg
  0 siblings, 1 reply; 9+ messages in thread
From: Maarten Vanraes @ 2014-09-24 12:52 UTC (permalink / raw)
  To: Eliezer Croitoru; +Cc: Pascal Hambourg, netfilter

Op woensdag 24 september 2014 15:38:26 schreef Eliezer Croitoru:
> On 09/24/2014 01:16 PM, Maarten Vanraes wrote:
> > ok, thanks,
> > 
> > so, this is why streaming/voip stuff will still have issues...
> 
> Yes indeed.
> and I Meant conntrack and connmark...
> VOIP and STREAMING are beasts!!!
> There are modules which analyze them and also recognize them but you
> will need to enable them first.
> 
> The issue is not UDP by itself as you understand.
> It's a well known issue with multi IP nat machines in ISPS.
> In many cases a SIP proxy helps to fix couple things.
> I haven't tried it yet but it seems like there are commercial products
> that implement these SIP proxy.

i've used siproxd before... but it's limited, i could set up an asterisk in 
between, but that might be overkill and i'm not sure i could intercept it 
without configuring stuff on the other side...

what kind of modules do you know that help conntracking this kind of stuff?

and... what about ipv6 and multiple ISPs? (but without natting, but still no 
bgp or something), won't i still have the same problem?

Regards,

Maarten
-- 
BA NV
IT & Security

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-24 12:52           ` Maarten Vanraes
@ 2014-09-26 13:18             ` Pascal Hambourg
  2014-09-26 14:02               ` Maarten Vanraes
  0 siblings, 1 reply; 9+ messages in thread
From: Pascal Hambourg @ 2014-09-26 13:18 UTC (permalink / raw)
  To: Maarten Vanraes; +Cc: netfilter

Maarten Vanraes a écrit :
> Op woensdag 24 september 2014 15:38:26 schreef Eliezer Croitoru:
>> VOIP and STREAMING are beasts!!!
>> There are modules which analyze them and also recognize them but you
>> will need to enable them first.
> 
> what kind of modules do you know that help conntracking this kind of stuff?

For SIP : nf_conntrack_sip. There is a nf_conntrack_<protocol> helper
for each supported "complex" protocol (FTP, IRC, PPTP...). Their purpose
is to set the state of the first packet of the data connection to
RELATED, and copy the connmark of the control connection to the data
connection. On a box doing NAT, you also need the related
nf_nat_<protocol> module.

> and... what about ipv6 and multiple ISPs? (but without natting, but still no 
> bgp or something), won't i still have the same problem?

Yes.

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

* Re: advanced routing with NAT: returning UDP traffic
  2014-09-26 13:18             ` Pascal Hambourg
@ 2014-09-26 14:02               ` Maarten Vanraes
  0 siblings, 0 replies; 9+ messages in thread
From: Maarten Vanraes @ 2014-09-26 14:02 UTC (permalink / raw)
  To: Pascal Hambourg; +Cc: netfilter

Op vrijdag 26 september 2014 15:18:42 schreef Pascal Hambourg:
> Maarten Vanraes a écrit :
> > Op woensdag 24 september 2014 15:38:26 schreef Eliezer Croitoru:
> >> VOIP and STREAMING are beasts!!!
> >> There are modules which analyze them and also recognize them but you
> >> will need to enable them first.
> > 
> > what kind of modules do you know that help conntracking this kind of
> > stuff?
> 
> For SIP : nf_conntrack_sip. There is a nf_conntrack_<protocol> helper
> for each supported "complex" protocol (FTP, IRC, PPTP...). Their purpose
> is to set the state of the first packet of the data connection to
> RELATED, and copy the connmark of the control connection to the data
> connection. On a box doing NAT, you also need the related
> nf_nat_<protocol> module.
> 
> > and... what about ipv6 and multiple ISPs? (but without natting, but still
> > no bgp or something), won't i still have the same problem?
> 
> Yes.


awesome, this makes it totally clear... thx!
-- 
BA NV
IT & Security

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

end of thread, other threads:[~2014-09-26 14:02 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-23 12:46 advanced routing with NAT: returning UDP traffic Maarten
2014-09-23 17:41 ` Eliezer Croitoru
2014-09-24  9:35   ` Maarten Vanraes
2014-09-24  9:49     ` Pascal Hambourg
2014-09-24 10:16       ` Maarten Vanraes
2014-09-24 12:38         ` Eliezer Croitoru
2014-09-24 12:52           ` Maarten Vanraes
2014-09-26 13:18             ` Pascal Hambourg
2014-09-26 14:02               ` Maarten Vanraes

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.