Re: just the mark

Re: just the mark

[Bob Miller]

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...

Re: just the mark

[Andy Furniss]

Bob Miller wrote:

You could ask on the netfilter user list -

http://www.netfilter.org/mailinglists.html#ml-user

> 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...
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>