All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thhoep" <thhoep@gmx.de>
To: netfilter@lists.netfilter.org
Subject: iproute2 and fwmark usage
Date: Thu, 8 Jan 2004 15:31:01 +0100	[thread overview]
Message-ID: <000a01c3d5f4$0ad343e0$1684188d@Kiste> (raw)
In-Reply-To: BAY10-F90LqDkgyDzS20002923f@hotmail.com

hi,

i have problems with the usage if netfilter marks in connection with
advanced routing using the iproute2 package. standing alone and using its
(lousy) inbuilt filter thingy iproute works normal, but trying to use
netfilter marks for routing decisions some pretty odd things happen. see for
yourself.


Routing tables (for this case uninteresting tables left out):

 router:~# ip route show table test
 217.5.98.133 dev ppp4  scope link  src 80.144.178.206
 192.168.0.0/24 dev eth4  scope link
 default via 217.5.98.133 dev ppp4

 router:~# ip route show table offline
 192.168.0.0/24 dev eth4  scope link
 unreachable default

 router:~# ip route show table main
 217.5.98.133 dev ppp0  proto kernel  scope link  src 80.144.190.200
 217.5.98.133 dev ppp1  proto kernel  scope link  src 80.144.188.142
 217.5.98.133 dev ppp2  proto kernel  scope link  src 80.144.179.55
 217.5.98.133 dev ppp5  proto kernel  scope link  src 80.144.184.186
 217.5.98.133 dev ppp4  proto kernel  scope link  src 80.144.178.206
 217.5.98.133 dev ppp3  proto kernel  scope link  src 80.144.188.180
 192.168.0.0/24 dev eth4  scope link
 default via 217.5.98.133 dev ppp0

Routing policies (for this case uninteresting rules left out):

 router:~# ip rule
 0:      from all lookup local
 1000:    from all fwmark        1 lookup test
 2000:   from 192.168.0.0/24 lookup offline
 32766:  from all lookup main
 32767:  from all lookup default

Netfilter configuration (for this case uninteresting rules left out,
uninteresting chain counters zeroed):

 - filter chains empty, policies = ACCEPT

 router:~# iptables -t nat -L -n -x -v
 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination

 Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination
     0   0 MASQUERADE  all  --  *      ppp4    0.0.0.0/0
0.0.0.0/0

 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination


 router:~# iptables -t mangle -L -n -x -v
 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination
      0    0 MARK       all  --  eth4   *       192.168.0.22
141.24.12.2/0          MARK set 0x1

 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination

 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination

 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination

 Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source
destination

the test:

 i ran a ping on my internal host 192.168.0.22 to a known external host
141.24.12.2.

 iptables shows, that the requests get marked correctly. for testing reasons
added just counting rules also show, that replies are getting in but dont
reach the FORWARD chain. so i assume they get lost while doing the routing.

  router:~# iptables -t mangle -L -n -x -v -Z
  Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         2      120            all  --  ppp4   *       141.24.12.2
0.0.0.0/0
         2      120 MARK       all  --  eth4   *       192.168.0.22
141.24.12.2        MARK set 0x1

  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination

  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         0        0            all  --  ppp4   *       141.24.12.2
0.0.0.0/0

  Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination

  Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         0        0            all  --  *      eth4    141.24.12.2
0.0.0.0/0

 tcpdump verifies, that indeed replies are coming in and shows, that no icmp
error messages are sent out, what should be the case if no route back could
be found due to incorrect routing.

  router:~# tcpdump -n -i ppp4
  tcpdump: listening on ppp4
  15:06:59.512539 80.144.178.206 > 141.24.12.2: icmp: echo request
  15:06:59.579680 141.24.12.2 > 80.144.178.206: icmp: echo reply (DF)

 changing from "fwmark" usage to the inbuilt filter of iproute the routing
works absolutely fine.

  router:~# ip rule del fwmark 1
  router:~# ip rule add from 192.168.0.22 table test

  <doing some pings from the internal host>

  router:~# iptables -t mangle -L -n -x -v -Z
  Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         4      240            all  --  ppp4   *       141.24.12.2
0.0.0.0/0
         4      240 MARK       all  --  eth4   *       192.168.0.22
141.24.12.2        MARK set 0x1

  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination

  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         4      240            all  --  ppp4   *       141.24.12.2
0.0.0.0/0

  Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination

  Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
      pkts      bytes target     prot opt in     out     source
destination
         4      500            all  --  *      eth4    141.24.12.2
0.0.0.0/0

router:~# iptables
iptables v1.2.6a: no command specified
Try `iptables -h' or 'iptables --help' for more information.
router:~# ip -V
ip utility, iproute2-ss010824
router:~# cat /proc/version
Linux version 2.4.22 (root@dslrouter) (gcc version 2.95.4 20011002 (Debian
prerelease)) #1 SMP Wed Nov 12 23:08:31 CET 2003


i am grateful for any help. thanks.

thomas hoeppler



  reply	other threads:[~2004-01-08 14:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-08 14:20 Filter out broadcast messages Gabby James
2004-01-08 14:31 ` Thhoep [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-08 23:05 Iproute2 and fwmark usage Thhoep
2004-01-09 16:47 ` Ramin Dousti
2004-01-09 16:17   ` Thhoep
2004-01-09 17:35     ` Ramin Dousti
2004-01-09 16:50       ` Thhoep
2004-01-09 19:42         ` Ramin Dousti
2004-01-09 19:06           ` Thhoep
2004-01-09 20:47             ` Ramin Dousti
2004-01-09 20:09               ` Thhoep
2004-01-09 21:22                 ` Ramin Dousti
2004-01-09 21:30                   ` Thhoep
2004-01-09 22:02                     ` Thhoep
2004-01-11 20:57                       ` Thhoep
2004-01-11 21:07                         ` Antony Stone
2004-01-11 21:50                           ` Thhoep
2004-01-11 23:12                             ` Thhoep
2004-01-11 23:22                               ` Antony Stone
2004-01-13 23:46                               ` Thhoep

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000a01c3d5f4$0ad343e0$1684188d@Kiste' \
    --to=thhoep@gmx.de \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.