is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Nguyen Dinh Nam]

Currently, SNAT/MASQ is only allowed in POSTROUTING/nat so at the 
internet gateway, everyone is doing something like this:
iptables -A POSTROUTING -t nat -o $external_interface -j SNAT --to 
$external_ip

But I think that this approach is more interesting
iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

The rule clears the source IP address from the packet, later, routing 
code will bind an ip address to the packet based on routing decision. In 
the case where the host has several internet providers, the traditional 
method needs several rules, as well as using CONNMARK to bind each TCP 
connection to only one internet provider. If this new approach is 
possible, it'll simplify the problem tremendously

I've never touched netfilter source code so I don't know if it's 
possible, it may be just a stupid idea.

Re: is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Max Kellermann]

On 2005/03/22 15:47, Nguyen Dinh Nam <64vn@cardvn.net> wrote:
> But I think that this approach is more interesting
> iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0
> 
> The rule clears the source IP address from the packet, later, routing 
> code will bind an ip address to the packet based on routing decision. In 
> the case where the host has several internet providers, the traditional 
> method needs several rules, as well as using CONNMARK to bind each TCP 
> connection to only one internet provider. If this new approach is 
> possible, it'll simplify the problem tremendously

Why don't you just use -j MASQUERADE if writing one rule per interface
is too much work for you?

I don't understand how CONNMARK helps with your "traditional method".

Max

Re: is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Nguyen Dinh Nam]

I use each -j SNAT for an interface because -j MASQUERADE doesn't work 
well with multipath routes, and SNAT has better performance than MASQ.

CONNMARK helps keeping packets of the same connection routed via a given 
nexthop which is selected by the multipath route for the first (--state 
NEW) packet, I wrote about it here:
http://selab.edu.ms/twiki/bin/view/Networking/MultihomedLinuxNetworking
it's a vital part of a multihomed internet gateway. With SNAT/MASQ 
available in PREROUTING, CONNMARK is no long required, hence save a lot 
of works and increase the performance.

Max Kellermann wrote:

> Why don't you just use -j MASQUERADE if writing one rule per interface
> is too much work for you?
>
> I don't understand how CONNMARK helps with your "traditional method".
>
> Max
>

Re: is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Nguyen Dinh Nam]

Senior netfilter developers, please tell me if SNAT in PREROUTING is 
worth the effort to implement. At least, tell me if it is fit with the 
linux networking architecture?

Nguyen Dinh Nam wrote:

> Currently, SNAT/MASQ is only allowed in POSTROUTING/nat so at the 
> internet gateway, everyone is doing something like this:
> iptables -A POSTROUTING -t nat -o $external_interface -j SNAT --to 
> $external_ip
>
> But I think that this approach is more interesting
> iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0
>
> The rule clears the source IP address from the packet, later, routing 
> code will bind an ip address to the packet based on routing decision. 
> In the case where the host has several internet providers, the 
> traditional method needs several rules, as well as using CONNMARK to 
> bind each TCP connection to only one internet provider. If this new 
> approach is possible, it'll simplify the problem tremendously
>
> I've never touched netfilter source code so I don't know if it's 
> possible, it may be just a stupid idea.

Newbie question about fragmentation and the PRE_ROUTING hook

[Devesh Agrawal]

Hi,
I have a very basic question about netfilter and IP fragments. My
understanding is that the pre routing hook gets the fragmented packet
, which is later in defragged in local in in the ip_local_input funx.
ie If I print the skb in pre route hook, I shall get the individual
frags, whereas in local in hook I would get the complete packet. Is
this absolutely correct ?
Am I gettting the right picture or is there anything else that I should know?
I would be grateful if someone could clear my doubt. 
Sincerely,
Devesh Agrawal

Re: Newbie question about fragmentation and the PRE_ROUTING hook

[Devesh Agrawal]

Hi,
Just to add some more info:
I wrote a simple src routing protocol , which adds a new hdr b/w the
ip and the tcp headers. I fragment a packet, such that each fragment
has the ip and my header (so that I decide the route for every frag).
However if I allow the kernel to reassemble my fragments it will screw
things up for me as it does not know anything about my header. Hence I
want to process each of the fragments in pre route as it is (basically
I remove my header and pass it up to local_in, where it can be
defragged in ip_local_deliver before calling my local in hander).
I have given NF_IP_PRE_FIRST priority to my pre route handler, but
still it is getting some screwed up reassembled packet, as probably
Netfilter is trying to reassemble my packet and hence messing it up.
I read up that conntrack defrags the packet, but it does so with a
lower priority (higher value) than NF_IP_PRE_FIRST, inspite of all
this, I do not know why my pre route handler is getting a defragged
packet. Any idea of what I am missing out.
PS: My sender explicitly frags a packet if its size is greater than
some value (currently set to 500). Hence I am sure that I am
generating those fragments. I will be greatful for any insight into
this problem.
Regards,
Devesh Agrawal

On Sat, 26 Mar 2005 00:37:41 +0530, Devesh Agrawal
<devesh.agrawal@gmail.com> wrote:
> Hi,
> I have a very basic question about netfilter and IP fragments. My
> understanding is that the pre routing hook gets the fragmented packet
> , which is later in defragged in local in in the ip_local_input funx.
> ie If I print the skb in pre route hook, I shall get the individual
> frags, whereas in local in hook I would get the complete packet. Is
> this absolutely correct ?
> Am I gettting the right picture or is there anything else that I should know?
> I would be grateful if someone could clear my doubt.
> Sincerely,
> Devesh Agrawal
> 


-- 
Devesh Agrawal
4th year Dual Degree.
Dept of CSE 
Indian Institute of Technology , Madras
Room No . 309 , Alakananda Hostel 
Chennai 600036 ,India
Ph : +91 9382102431

Re: is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nguyen Dinh Nam wrote:
| Senior netfilter developers, please tell me if SNAT in PREROUTING is
| worth the effort to implement. At least, tell me if it is fit with the
| linux networking architecture?

I'm no senior, but could the SAME target in patch-o-matic-ng maybe help you out?

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCRU9+xyF48ZTvn+4RAjCgAKDFc0QJvIsOxAxGXqJd4wCmtY3iXQCgnAAI
M6Jxpx7DfqrBeRsrkF9SRXE=
=xcEV
-----END PGP SIGNATURE-----

Re: is this make sense: iptables -A PREROUTING -t nat -j SNAT --to 0.0.0.0

[Nguyen Dinh Nam]

No, AFAIK, SAME is for internet connections which supply a whole subnet 
of public IP addresses instead of just 1 IP address. But it's not what I 
want. I want to make routing in a multihomed host easier, let me write 
an example:
There is a host with 2 PPPOE connections: ppp1 (IP: 11.1.1.1) and ppp2 
(IP: 22.2.2.2), so connection teaming is done like this:
ip rule add prio 1 from 11.1.1.1 lookup 101
ip route add table 101 to default dev ppp1
ip rule add prio 2 from 22.2.2.2 lookup 102
ip route add table 102 to default dev ppp2
ip route add default nexthop dev ppp0 nexthop dev ppp1

the problem is that the routing system can depend on the source IP 
address (11.1.1.1 or 22.2.2.2) to route the packet to the correct 
interface, but packets from the LAN will have LAN ip address when 
reaching routing system, thus those packet won't match neither "prio 1" 
nor "prio 2" rules.

My idea to solve it is to do something to make netfilter to masquerade 
the source of packets (from LAN IP address to 11.1.1.1 or 22.2.2.2) 
*before* reaching routing system, so those packets can match "prio 1" or 
"prio 2" routing rules. If I know that it's possible, I'll start the new 
career of hacking networking code so may be you will have one more 
contributor.

Sincerely,
Nam

Jonas Berlin wrote:

> I'm no senior, but could the SAME target in patch-o-matic-ng maybe 
> help you out?