All of lore.kernel.org
 help / color / mirror / Atom feed
* policy based routing question
@ 2007-12-06  2:19 Neal Becker
  2007-12-06  3:41 ` FTP Wierdness Toby Chamberlain
  2007-12-06  3:43 ` policy based routing question Andrew Kraslavsky
  0 siblings, 2 replies; 5+ messages in thread
From: Neal Becker @ 2007-12-06  2:19 UTC (permalink / raw)
  To: netfilter

I'm interested in implementing policy based routing on a system with
multiple interfaces.  I'd like to use some kind of classifier to determine
the type of traffic associated with a packet.  I know iptables/mark + ip
route can be used to classify packets by port #, but that isn't always
sufficient.

I wonder if anyone has implemented anything like this and can give me any
advice?


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

* FTP Wierdness
  2007-12-06  2:19 policy based routing question Neal Becker
@ 2007-12-06  3:41 ` Toby Chamberlain
  2007-12-06  3:43 ` policy based routing question Andrew Kraslavsky
  1 sibling, 0 replies; 5+ messages in thread
From: Toby Chamberlain @ 2007-12-06  3:41 UTC (permalink / raw)
  To: netfilter

After working fine for years, I am suddenly experiencing intermittent 
failures with my NAT box (Debian stable) failing to identify some incoming 
ftp-data packets as belonging to an existing connection. The failures seem 
random and can happen at any time in the FTP connection - for example an 
"mget" will receive the NLIST ok but then fail in the subsequent GET

Logging all port 20 traffic from the remote host with "FTP:" shows this in 
the syslog:
(remote is 202.55, internal is 172.16, the NAT box is 203.38)

Dec  4 15:37:19 rc1 kernel: FTP:IN=eth0 OUT=eth0 SRC=202.55.x.x 
DST=172.16.x.x LEN=73 TOS=0x00 PREC=0x00 TTL=113 ID=9526 DF PROTO=TCP SPT=20 
DPT=5005 WINDOW=65535 RES=0x00 ACK PSH URGP=0
Dec  4 15:37:19 rc1 kernel: FTP:IN=eth0 OUT=eth0 SRC=202.55.x.x 
DST=172.16.x.x LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=9527 DF PROTO=TCP SPT=20 
DPT=5005 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Dec  4 15:37:20 rc1 kernel: FTP:IN=eth0 OUT=eth0 SRC=202.55.x.x 
DST=172.16.x.x LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=9528 DF PROTO=TCP SPT=20 
DPT=5005 WINDOW=65535 RES=0x00 ACK URGP=0
Dec  4 15:37:20 rc1 kernel: FTP:IN=eth0 OUT= MAC=00:13:xx:xx:etc 
SRC=202.55.x.x DST=203.38.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=9539 DF 
PROTO=TCP SPT=20 DPT=5006 WINDOW=65535 RES=0x00 SYN URGP=0
Dec  4 15:37:20 rc1 kernel: Input:IN=eth0 OUT= MAC=00:13:xx:xx:etc 
SRC=202.55.x.x DST=203.38.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=9539 DF 
PROTO=TCP SPT=20 DPT=5006 WINDOW=65535 RES=0x00 SYN URGP=0
Dec  4 15:37:23 rc1 kernel: FTP:IN=eth0 OUT= MAC=00:13:xx:xx:etc 
SRC=202.55.x.x DST=203.38.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=9580 DF 
PROTO=TCP SPT=20 DPT=5006 WINDOW=65535 RES=0x00 SYN URGP=0
Dec  4 15:37:23 rc1 kernel: Input:IN=eth0 OUT= MAC=00:13:xx:xx:etc 
SRC=202.55.x.x DST=203.38.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=9580 DF 
PROTO=TCP SPT=20 DPT=5006 WINDOW=65535 RES=0x00 SYN URGP=006

This is from an mget - the first 3 packets are presumably from the 
successful NLIST, the next 2 are the failed GET - as you can see they aren't 
being un-NATted and are thus blocked by the firewall (the "Input:" lines). 
Eventually the connection times out.

The system exchanges files with the FTP server every 10-20 minutes - it goes 
put, get, put, mget in separate sessions with a second or two in between. 
The failure can occur in any of the operations and it is rare to see 3 
successful completions is a row.

As I said the system has been running perfectly for years. The only recent 
change was upgrading of the client box to a Core2 Duo - it ran fine for a 
few days before the problems started.

Are there any know issues or bugs that could cause this sort of behaviour? 
Does anybody have any idea how to go about fixing it?
Toby


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

* RE: policy based routing question
  2007-12-06  2:19 policy based routing question Neal Becker
  2007-12-06  3:41 ` FTP Wierdness Toby Chamberlain
@ 2007-12-06  3:43 ` Andrew Kraslavsky
  2007-12-06 11:33   ` Neal Becker
  1 sibling, 1 reply; 5+ messages in thread
From: Andrew Kraslavsky @ 2007-12-06  3:43 UTC (permalink / raw)
  To: Neal Becker, netfilter


> I'm interested in implementing policy based routing on a system with
> multiple interfaces. I'd like to use some kind of classifier to determine
> the type of traffic associated with a packet. I know iptables/mark + ip
> route can be used to classify packets by port #, but that isn't always
> sufficient.
>

Perhaps I have misunderstood your question but...all of the matches that are valid/meaningful in the mangle table's PREROUTING chain are at your disposal!

For example, assuming you define advanced routing rules that use mark 0x01 for your primary interface and mark 0x02 for your secondary interface and you wanted all outgoing HTTP traffic fron local subnet 192.168.10.0/24 to go out your primary interface and you wanted all outgoing HTTP traffic from local subnet 192.168.20.0/24 to go out your secondary interface you could use:

iptables -t mangle -A PREROUTING -s 192.168.10.0/24 -p tcp --dport 80 -j MARK --set-mark 0x01
iptables -t mangle -A PREROUTING -s 192.168.20.0/24 -p tcp --dport 80 -j MARK --set-mark 0x02

The appropriate matches to use would of course depend on what your interests are (classify by source IP address? source MAC address? input interface? destiantion port? etc...).

Putting it another way, beyond port number and the examples listed above or all that is covered on the iptables man page, what kind of classification are you after?

- Andrew
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007

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

* RE: policy based routing question
  2007-12-06  3:43 ` policy based routing question Andrew Kraslavsky
@ 2007-12-06 11:33   ` Neal Becker
  2007-12-06 11:43     ` Pascal Hambourg
  0 siblings, 1 reply; 5+ messages in thread
From: Neal Becker @ 2007-12-06 11:33 UTC (permalink / raw)
  To: netfilter; +Cc: fedora-list

Andrew Kraslavsky wrote:

> 
>> I'm interested in implementing policy based routing on a system with
>> multiple interfaces. I'd like to use some kind of classifier to determine
>> the type of traffic associated with a packet. I know iptables/mark + ip
>> route can be used to classify packets by port #, but that isn't always
>> sufficient.
>>
> 
> Perhaps I have misunderstood your question but...all of the matches that
> are valid/meaningful in the mangle table's PREROUTING chain are at your
> disposal!
> 
> For example, assuming you define advanced routing rules that use mark 0x01
> for your primary interface and mark 0x02 for your secondary interface and
> you wanted all outgoing HTTP traffic fron local subnet 192.168.10.0/24 to
> go out your primary interface and you wanted all outgoing HTTP traffic
> from local subnet 192.168.20.0/24 to go out your secondary interface you
> could use:
> 
> iptables -t mangle -A PREROUTING -s 192.168.10.0/24 -p tcp --dport 80 -j
> MARK --set-mark 0x01 iptables -t mangle -A PREROUTING -s 192.168.20.0/24
> -p tcp --dport 80 -j MARK --set-mark 0x02
> 
> The appropriate matches to use would of course depend on what your
> interests are (classify by source IP address? source MAC address? input
> interface? destiantion port? etc...).
> 
> Putting it another way, beyond port number and the examples listed above
> or all that is covered on the iptables man page, what kind of
> classification are you after?
> 

Having done a bit more research, I think what I'm interested in is L7.  Now
what I'm trying to figure out is what is needed for L7 userspace on fedora
f8 kernel.

I have kernel-2.6.23.8-63.fc8.x86_64.  According to
http://l7-filter.sourceforge.net/HOWTO-userspace
I need to figure out if fedora f8 kernel has "Layer 3 Dependent Connection
tracking (OBSOLETE)".  Looking
in /lib/modules/2.6.23.8-63.fc8/build/.config I don't see anything that
obviously corresponds to this.

If I just try anyway, it doesn't seem to work:
sudo /sbin/modprobe -v ip_conntrack_netlink
insmod /lib/modules/2.6.23.8-63.fc8/kernel/net/ipv4/netfilter/nf_nat.ko 
insmod /lib/modules/2.6.23.8-63.fc8/kernel/net/netfilter/nf_conntrack_netlink.ko 
[nbecker@nbecker1 l7-filter-userspace-v0.4]$ /usr/bin/l7-filter --help

                      ***WARNING***
The ip_conntrack_netlink module does not appear to be loaded.
Unless you have it compiled into your kernel, please load it
and run l7-filter again.





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

* Re: policy based routing question
  2007-12-06 11:33   ` Neal Becker
@ 2007-12-06 11:43     ` Pascal Hambourg
  0 siblings, 0 replies; 5+ messages in thread
From: Pascal Hambourg @ 2007-12-06 11:43 UTC (permalink / raw)
  To: netfilter

Hello,

Neal Becker a écrit :
> 
> I have kernel-2.6.23.8-63.fc8.x86_64.  According to
> http://l7-filter.sourceforge.net/HOWTO-userspace
> I need to figure out if fedora f8 kernel has "Layer 3 Dependent Connection
> tracking (OBSOLETE)".

Legacy IPv4-only connection tracking was removed from kernel 2.6.22.

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

end of thread, other threads:[~2007-12-06 11:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-06  2:19 policy based routing question Neal Becker
2007-12-06  3:41 ` FTP Wierdness Toby Chamberlain
2007-12-06  3:43 ` policy based routing question Andrew Kraslavsky
2007-12-06 11:33   ` Neal Becker
2007-12-06 11:43     ` Pascal Hambourg

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.