* Routing locally generated traffic on fwmark
@ 2011-09-28 22:20 Andrew Beverley
2011-09-29 6:51 ` Andrew Beverley
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Beverley @ 2011-09-28 22:20 UTC (permalink / raw)
To: netfilter
Hi,
I'd like to route locally generated traffic via a particular interface
based on its mark value.
From what I have researched, this is theoretically possible and lots of
people have tried it, but nobody has got it working.
Here's my rules:
# Mark the packets
iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
# Route the marked packets via routing table T2:
ip rule add fwmark 0x800/0xffff table T2
# Force T2 packets out of the interface ppp1
ip route add table T2 default dev ppp1 via 94.30.127.76
# Flush the cache, just in case
ip route flush cache
However, the packets still go out of the default route (ppp0).
cwdwr:~# ip rule
0: from all lookup local
32765: from all fwmark 0x800/0xffff lookup T2
32766: from all lookup main
32767: from all lookup default
cwdwr:~# ip route show table T2
default via 94.30.127.76 dev ppp1
Any ideas? Should this be possible?
Thanks,
Andy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-28 22:20 Routing locally generated traffic on fwmark Andrew Beverley
@ 2011-09-29 6:51 ` Andrew Beverley
2011-09-29 7:32 ` Pandu Poluan
2011-09-29 10:28 ` Jan Engelhardt
0 siblings, 2 replies; 10+ messages in thread
From: Andrew Beverley @ 2011-09-29 6:51 UTC (permalink / raw)
To: netfilter
On Wed, 2011-09-28 at 23:20 +0100, Andrew Beverley wrote:
> Hi,
>
> I'd like to route locally generated traffic via a particular interface
> based on its mark value.
>
> From what I have researched, this is theoretically possible and lots of
> people have tried it, but nobody has got it working.
>
> Here's my rules:
>
> # Mark the packets
> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
>
> # Route the marked packets via routing table T2:
> ip rule add fwmark 0x800/0xffff table T2
>
> # Force T2 packets out of the interface ppp1
> ip route add table T2 default dev ppp1 via 94.30.127.76
>
> # Flush the cache, just in case
> ip route flush cache
>
> However, the packets still go out of the default route (ppp0).
I've also added the following, which makes no difference:
iptables -t nat -A POSTROUTING -o ppp1 \
-j SNAT --to-source 109.224.134.110
And I've done a test with:
ip rule add to 89.16.176.81 table T2
which *does* work.
So, I assume the problem is that the packet is marked too late to affect
the routing. Looking at the packet flow diagram[1] though, there should
be a re-route check after the mangle table, which should re-route if a
packet's mark has changed. Does this feature need enabling?
Andy
[1] http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-29 6:51 ` Andrew Beverley
@ 2011-09-29 7:32 ` Pandu Poluan
2011-09-29 7:53 ` [SOLVED] " Andrew Beverley
2011-09-29 10:28 ` Jan Engelhardt
1 sibling, 1 reply; 10+ messages in thread
From: Pandu Poluan @ 2011-09-29 7:32 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter
On Thu, Sep 29, 2011 at 13:51, Andrew Beverley <andy@andybev.com> wrote:
> On Wed, 2011-09-28 at 23:20 +0100, Andrew Beverley wrote:
>> Hi,
>>
>> I'd like to route locally generated traffic via a particular interface
>> based on its mark value.
>>
>> From what I have researched, this is theoretically possible and lots of
>> people have tried it, but nobody has got it working.
>>
>> Here's my rules:
>>
>> # Mark the packets
>> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
>>
>> # Route the marked packets via routing table T2:
>> ip rule add fwmark 0x800/0xffff table T2
>>
>> # Force T2 packets out of the interface ppp1
>> ip route add table T2 default dev ppp1 via 94.30.127.76
>>
>> # Flush the cache, just in case
>> ip route flush cache
>>
>> However, the packets still go out of the default route (ppp0).
>
> I've also added the following, which makes no difference:
>
> iptables -t nat -A POSTROUTING -o ppp1 \
> -j SNAT --to-source 109.224.134.110
>
> And I've done a test with:
>
> ip rule add to 89.16.176.81 table T2
>
> which *does* work.
>
> So, I assume the problem is that the packet is marked too late to affect
> the routing. Looking at the packet flow diagram[1] though, there should
> be a re-route check after the mangle table, which should re-route if a
> packet's mark has changed. Does this feature need enabling?
>
> Andy
>
> [1] http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
>
Can you post the complete table, i.e., the output of iptables-save ?
Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~
• LOPSA Member #15248
• Blog : http://pepoluan.tumblr.com
• Linked-In : http://id.linkedin.com/in/pepoluan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] Routing locally generated traffic on fwmark
2011-09-29 7:32 ` Pandu Poluan
@ 2011-09-29 7:53 ` Andrew Beverley
2011-09-29 8:29 ` Pandu Poluan
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Beverley @ 2011-09-29 7:53 UTC (permalink / raw)
To: Pandu Poluan; +Cc: netfilter
On Thu, 2011-09-29 at 14:32 +0700, Pandu Poluan wrote:
> On Thu, Sep 29, 2011 at 13:51, Andrew Beverley <andy@andybev.com> wrote:
> > On Wed, 2011-09-28 at 23:20 +0100, Andrew Beverley wrote:
> >> Hi,
> >>
> >> I'd like to route locally generated traffic via a particular interface
> >> based on its mark value.
> >>
> >> From what I have researched, this is theoretically possible and lots of
> >> people have tried it, but nobody has got it working.
> >>
> >> Here's my rules:
> >>
> >> # Mark the packets
> >> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
> >>
> >> # Route the marked packets via routing table T2:
> >> ip rule add fwmark 0x800/0xffff table T2
> >>
> >> # Force T2 packets out of the interface ppp1
> >> ip route add table T2 default dev ppp1 via 94.30.127.76
> >>
> >> # Flush the cache, just in case
> >> ip route flush cache
> >>
> >> However, the packets still go out of the default route (ppp0).
> >
> > I've also added the following, which makes no difference:
> >
> > iptables -t nat -A POSTROUTING -o ppp1 \
> > -j SNAT --to-source 109.224.134.110
> >
> >
>
> Can you post the complete table, i.e., the output of iptables-save ?
>
Thanks for that. After I added the SNAT rule, I forgot to remove an
existing earlier rule that was stopping the packets being marked. Your
email reminded me!
So, the reason it wasn't working for me was the missing SNAT rule after
all. It now works correctly.
Thanks,
Andy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] Routing locally generated traffic on fwmark
2011-09-29 7:53 ` [SOLVED] " Andrew Beverley
@ 2011-09-29 8:29 ` Pandu Poluan
2011-10-02 13:11 ` Ed W
0 siblings, 1 reply; 10+ messages in thread
From: Pandu Poluan @ 2011-09-29 8:29 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter
On Thu, Sep 29, 2011 at 14:53, Andrew Beverley <andy@andybev.com> wrote:
> On Thu, 2011-09-29 at 14:32 +0700, Pandu Poluan wrote:
>> On Thu, Sep 29, 2011 at 13:51, Andrew Beverley <andy@andybev.com> wrote:
>> > On Wed, 2011-09-28 at 23:20 +0100, Andrew Beverley wrote:
>> >> Hi,
>> >>
>> >> I'd like to route locally generated traffic via a particular interface
>> >> based on its mark value.
>> >>
>> >> From what I have researched, this is theoretically possible and lots of
>> >> people have tried it, but nobody has got it working.
>> >>
>> >> Here's my rules:
>> >>
>> >> # Mark the packets
>> >> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
>> >>
>> >> # Route the marked packets via routing table T2:
>> >> ip rule add fwmark 0x800/0xffff table T2
>> >>
>> >> # Force T2 packets out of the interface ppp1
>> >> ip route add table T2 default dev ppp1 via 94.30.127.76
>> >>
>> >> # Flush the cache, just in case
>> >> ip route flush cache
>> >>
>> >> However, the packets still go out of the default route (ppp0).
>> >
>> > I've also added the following, which makes no difference:
>> >
>> > iptables -t nat -A POSTROUTING -o ppp1 \
>> > -j SNAT --to-source 109.224.134.110
>> >
>> >
>>
>> Can you post the complete table, i.e., the output of iptables-save ?
>>
>
> Thanks for that. After I added the SNAT rule, I forgot to remove an
> existing earlier rule that was stopping the packets being marked. Your
> email reminded me!
>
> So, the reason it wasn't working for me was the missing SNAT rule after
> all. It now works correctly.
>
> Thanks,
>
You're welcome.
That's why I now no longer write iptables commands directly on the
shell. I keep my firewall rules in a file /etc/opt/firewall, and if I
need to add new rules, I just do: `vi /etc/opt/firewall &&
iptables-restore < /etc/opt/firewall`
(Of course, to seed the file I'd do `iptables-save > /etc/opt/firewall` )
This has the added benefit of allowing me to document all firewall
changes by doing `hg commit` followed by `hg push` to a local
Mercurial repository.
(The reason why I put the rules in /etc/opt instead of /etc is so that
I don't have to create an .hgignore file)
Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~
• LOPSA Member #15248
• Blog : http://pepoluan.tumblr.com
• Linked-In : http://id.linkedin.com/in/pepoluan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-29 6:51 ` Andrew Beverley
2011-09-29 7:32 ` Pandu Poluan
@ 2011-09-29 10:28 ` Jan Engelhardt
2011-09-29 17:28 ` Andrew Beverley
1 sibling, 1 reply; 10+ messages in thread
From: Jan Engelhardt @ 2011-09-29 10:28 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter, Pandu Poluan
On Thursday 2011-09-29 08:51, Andrew Beverley wrote:
>> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
>> ip rule add fwmark 0x800/0xffff table T2
>> ip route add table T2 default dev ppp1 via 94.30.127.76
>
>I've also added the following, which makes no difference:
>
>iptables -t nat -A POSTROUTING -o ppp1 \
> -j SNAT --to-source 109.224.134.110
Of course it makes no difference, because SNAT is applied after routing.
("POST" "ROUTING", see?)
>So, I assume the problem is that the packet is marked too late to affect
>the routing.
>Looking at the packet flow diagram[1] though, there should
>be a re-route check after the mangle table, which should re-route if a
>packet's mark has changed. Does this feature need enabling?
mangle is the right place; in its code you will find
ret = ipt_do_table(skb, NF_INET_LOCAL_OUT, NULL, out,
dev_net(out)->ipv4.iptable_mangle);
/* Reroute for ANY change. */
if (ret != NF_DROP && ret != NF_STOLEN) {
iph = ip_hdr(skb);
if (iph->saddr != saddr ||
iph->daddr != daddr ||
skb->mark != mark ||
iph->tos != tos)
if (ip_route_me_harder(skb, RTN_UNSPEC))
ret = NF_DROP;
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-29 10:28 ` Jan Engelhardt
@ 2011-09-29 17:28 ` Andrew Beverley
2011-09-29 17:35 ` Jan Engelhardt
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Beverley @ 2011-09-29 17:28 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter, Pandu Poluan
On Thu, 2011-09-29 at 12:28 +0200, Jan Engelhardt wrote:
> On Thursday 2011-09-29 08:51, Andrew Beverley wrote:
> >> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
> >> ip rule add fwmark 0x800/0xffff table T2
> >> ip route add table T2 default dev ppp1 via 94.30.127.76
> >
> >I've also added the following, which makes no difference:
> >
> >iptables -t nat -A POSTROUTING -o ppp1 \
> > -j SNAT --to-source 109.224.134.110
>
> Of course it makes no difference, because SNAT is applied after routing.
> ("POST" "ROUTING", see?)
Yes, but in my case the SNAT still needed applying. The problem was that
although the packets were being routed via the second interface, they
were still being sent from the original IP address of the first
interface. Therefore, packets were being returned to the first
interface, making it look as if the second interface wasn't being used.
>
> >So, I assume the problem is that the packet is marked too late to affect
> >the routing.
> >Looking at the packet flow diagram[1] though, there should
> >be a re-route check after the mangle table, which should re-route if a
> >packet's mark has changed. Does this feature need enabling?
>
> mangle is the right place; in its code you will find
>
> ret = ipt_do_table(skb, NF_INET_LOCAL_OUT, NULL, out,
> dev_net(out)->ipv4.iptable_mangle);
> /* Reroute for ANY change. */
> if (ret != NF_DROP && ret != NF_STOLEN) {
> iph = ip_hdr(skb);
> if (iph->saddr != saddr ||
> iph->daddr != daddr ||
> skb->mark != mark ||
> iph->tos != tos)
> if (ip_route_me_harder(skb, RTN_UNSPEC))
> ret = NF_DROP;
Thanks, that helps. Useful to know exactly what is going on.
Thanks for all the help.
Andy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-29 17:28 ` Andrew Beverley
@ 2011-09-29 17:35 ` Jan Engelhardt
2011-09-29 17:46 ` Andrew Beverley
0 siblings, 1 reply; 10+ messages in thread
From: Jan Engelhardt @ 2011-09-29 17:35 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter, Pandu Poluan
On Thursday 2011-09-29 19:28, Andrew Beverley wrote:
>On Thu, 2011-09-29 at 12:28 +0200, Jan Engelhardt wrote:
>> On Thursday 2011-09-29 08:51, Andrew Beverley wrote:
>> >> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
>> >> ip rule add fwmark 0x800/0xffff table T2
>> >> ip route add table T2 default dev ppp1 via 94.30.127.76
>> >
>> >I've also added the following, which makes no difference:
>> >
>> >iptables -t nat -A POSTROUTING -o ppp1 \
>> > -j SNAT --to-source 109.224.134.110
>>
>> Of course it makes no difference, because SNAT is applied after routing.
>> ("POST" "ROUTING", see?)
>
>Yes, but in my case the SNAT still needed applying. The problem was that
>although the packets were being routed via the second interface, they
>were still being sent from the original IP address of the first
>interface. Therefore, packets were being returned to the first
>interface, making it look as if the second interface wasn't being used.
Well, that's why one should use tcpdump -i ethX, rather than tcpdump -i
any :-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Routing locally generated traffic on fwmark
2011-09-29 17:35 ` Jan Engelhardt
@ 2011-09-29 17:46 ` Andrew Beverley
0 siblings, 0 replies; 10+ messages in thread
From: Andrew Beverley @ 2011-09-29 17:46 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter, Pandu Poluan
On Thu, 2011-09-29 at 19:35 +0200, Jan Engelhardt wrote:
> On Thursday 2011-09-29 19:28, Andrew Beverley wrote:
>
> >On Thu, 2011-09-29 at 12:28 +0200, Jan Engelhardt wrote:
> >> On Thursday 2011-09-29 08:51, Andrew Beverley wrote:
> >> >> iptables -A OUTPUT -t mangle -d 89.16.176.81 -j MARK --set-mark 0x800
> >> >> ip rule add fwmark 0x800/0xffff table T2
> >> >> ip route add table T2 default dev ppp1 via 94.30.127.76
> >> >
> >> >I've also added the following, which makes no difference:
> >> >
> >> >iptables -t nat -A POSTROUTING -o ppp1 \
> >> > -j SNAT --to-source 109.224.134.110
> >>
> >> Of course it makes no difference, because SNAT is applied after routing.
> >> ("POST" "ROUTING", see?)
> >
> >Yes, but in my case the SNAT still needed applying. The problem was that
> >although the packets were being routed via the second interface, they
> >were still being sent from the original IP address of the first
> >interface. Therefore, packets were being returned to the first
> >interface, making it look as if the second interface wasn't being used.
>
> Well, that's why one should use tcpdump -i ethX, rather than tcpdump -i
> any :-)
Yep, I learn something every time ;-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] Routing locally generated traffic on fwmark
2011-09-29 8:29 ` Pandu Poluan
@ 2011-10-02 13:11 ` Ed W
0 siblings, 0 replies; 10+ messages in thread
From: Ed W @ 2011-10-02 13:11 UTC (permalink / raw)
To: Pandu Poluan; +Cc: Andrew Beverley, netfilter
On 29/09/2011 09:29, Pandu Poluan wrote:
> That's why I now no longer write iptables commands directly on the
> shell. I keep my firewall rules in a file /etc/opt/firewall, and if I
> need to add new rules, I just do: `vi /etc/opt/firewall &&
> iptables-restore < /etc/opt/firewall`
>
> (Of course, to seed the file I'd do `iptables-save > /etc/opt/firewall` )
>
> This has the added benefit of allowing me to document all firewall
> changes by doing `hg commit` followed by `hg push` to a local
> Mercurial repository.
>
> (The reason why I put the rules in /etc/opt instead of /etc is so that
> I don't have to create an .hgignore file)
>
Can I also leave a plug for shorewall for similar reasons. It is a
fairly thin wrapper over iptables (etc), but it allows you to think at a
slightly higher level and wraps things such as setting/restoring fwmarks
and routing, breaks them out from the general access rules.
I find it picks a very nice level between firewall guis and raw editing
of iptables commands. Give it a try.
Also it's text file based so it's very easy to track via some source
code control system
Cheers
Ed W
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-10-02 13:11 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-28 22:20 Routing locally generated traffic on fwmark Andrew Beverley
2011-09-29 6:51 ` Andrew Beverley
2011-09-29 7:32 ` Pandu Poluan
2011-09-29 7:53 ` [SOLVED] " Andrew Beverley
2011-09-29 8:29 ` Pandu Poluan
2011-10-02 13:11 ` Ed W
2011-09-29 10:28 ` Jan Engelhardt
2011-09-29 17:28 ` Andrew Beverley
2011-09-29 17:35 ` Jan Engelhardt
2011-09-29 17:46 ` Andrew Beverley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox