All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Miller <bob@computerisms.ca>
To: lartc@vger.kernel.org
Subject: Re: just the mark
Date: Wed, 04 Mar 2015 19:51:08 +0000	[thread overview]
Message-ID: <54F7622C.5080306@computerisms.ca> (raw)

I have been reading man pages and googling and I am not finding 
understanding.  maybe somebody can explain:

under my mangle table (using iptables-restore to load):

-A PREROUTING -p udp -m udp --dport 4500 -j MARK --set-mark 30
-A PREROUTING -s 192.168.171.0/24 -m mark ! --mark 30 -j MARK --set-mark 40
-A PREROUTING -m mark --mark 30 -j LOG --log-prefix vpnX30
-A PREROUTING -m mark --mark 40 -j LOG --log-prefix vpnX40

This logs packets with both marks.

If I change the LOG target to POSTROUTING, like so:

-A POSTROUTING -m mark --mark 30 -j LOG --log-prefix vpnX30
-A POSTROUTING -m mark --mark 40 -j LOG --log-prefix vpnX40

only packets with the mark 40 are logged.  I think it should log both.

If I consult the nfpacket flow chart, nat/PREROUTING comes after 
mangle/PREROUTING, and I cannot log packets with a mark of 30 there 
either.

Traffic keeps flowing, so the packets themselves are not being dropped, 
but the mark apparently is not passed from the initial chain. 
Everything I have read indicates it should be.  what could I have done 
(or not done) to make this happen?  Or better yet, what should I be 
reading that would explain this?  I get the feeling I am overlooking 
something really obvious...





On 15-03-02 12:10 PM, Bob Miller wrote:
> Hello,
>
> I read a few posts that it is possible to mark a packet with iptables,
> and then shape it as it leaves on an ipsec tunnel.  So far I am having
> limited success with the idea.
>
> I am using libreswan with netkey.  I tried marking the packets in
> mangle/PREROUTING, but I had zero joy with that; I suspect that when the
> kernel does its netkey magic the mark is lost.  I tried marking at a
> number of other spots in the nfpacket flow, I only got results at
> mange/POSTROUTING.  But it doesn't seem to grab all the packets.
>
> I have 6 remote users on the vpn, I give each of them a mark based on
> the IP address they get, and I mark all non-vpn packets with a 7th mark.
>   I set up 7 classes to match each mark.  I determine by the command
> `watch -n 1 -d tc -s class show dev eth0` that some packets do go
> through each class, but it is only a very small percentage of them
> (after watching it for a while now I suspect it is initial syn packets).
>   The rest all go into the 7th non-vpn class, even though I can log the
> packets marked to go to one of the vpn users.
>
> So I am wondering if I have missed a piece of the theory, or if what I
> am trying to accomplish just isn't possible.  Perhaps it would be better
> to setup a class based on src/dst port 500, but I would like to
> guarantee each vpn user a fair share of the limited bandwidth (which I
> think pretty much requires a separate class for each user), and I am not
> sure how that can be accomplished with dynamic remote addresses.
>
> comments or suggestions would be highly appreciated...

             reply	other threads:[~2015-03-04 19:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 19:51 Bob Miller [this message]
2015-03-04 21:48 ` just the mark Andy Furniss

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=54F7622C.5080306@computerisms.ca \
    --to=bob@computerisms.ca \
    --cc=lartc@vger.kernel.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.