All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Themel <themel@iwoars.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] fwmark routing of locally generated packets
Date: Sat, 01 Nov 2003 10:39:10 +0000	[thread overview]
Message-ID: <marc-lartc-106768361926312@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106730159403106@msgid-missing>

Hi,
Brad Barnett (bb@L8R.net) wrote on 2003-11-01:
> We have the same problem. ;)  You're right, it doesn't make any sense.

Yeah, that's what I feel. Unfortunately, my message to linux-netdev went
unnoticed, and I don't really know of any reference against which to
compare whether the current behaviour is intended or not.

> Can anyone elaborate??  My setup is virtually identical to what Thomas
> has.  However, I'm using IPMASQ on my outgoing connection, so I am able to
> see that the problem exists even without using SNAT. 

This is what I do currently, and it seems to work. This is from an ip-up
script for my PPP link:

ip route flush table aonc
ip route add $GWIP dev $PPP_IFACE src $PPP_LOCAL table aonc
# local for DNS etc
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table aonc
# internet via PPP lnk
ip route add default via $PPP_REMOTE src $PPP_LOCAL table aonc
ip rule add fwmark 3 lookup aonc

# owner tagging
iptables -t mangle -A OUTPUT -m owner --uid-owner freenet -j MARK --set-mark 3
# SNAT for outgoing packets
iptables -A POSTROUTING -t nat -o $PPP_IFACE --match mark --mark 0x03 -j SNAT --to-source $PPP_LOCAL
# DNAT for incoming packets
iptables -t nat -A PREROUTING -i $PPP_IFACE  -d $PPP_LOCAL -j DNAT --to-destination 192.168.1.1
ip route flush cache

However, this is feels like a very bad hack - the final DNAT makes the
interface unusable for other purposes, and the interaction between the
sockets' addresses and the packets' addresses are too complicated for my
taste. It's okay for my home network, but I wouldn't want to run this
productively. 

ciao,
-- 
[*Thomas  Themel*] Our national shield displays a lion with two tails. It's
[extended contact] rumoured that it symbolizes the nature of our governments;
[info provided in] that there actually were two lions, but one is now stuck
[*message header*] deep in the ass of the other one.  - Thomas Shaddack
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-11-01 10:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-28  0:32 [LARTC] fwmark routing of locally generated packets Thomas Themel
2003-10-28 16:20 ` Thomas Themel
2003-11-01  4:37 ` Brad Barnett
2003-11-01 10:39 ` Thomas Themel [this message]
2003-11-04 10:26 ` Thomas Themel

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=marc-lartc-106768361926312@msgid-missing \
    --to=themel@iwoars.net \
    --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.