SNAT

SNAT

[Breno Cardoso Perucchi]

Hello,
How I can do that the iptables that my IP INVALID (192.168.0.1) in the
OUTPUT transform my IP INVALID for ip valid in the output (200.200.200.1)
using SNAT

Example IP:
Internal 192.168.0.1 port 53
External 200.200.200.1 port 53

I want when to request internal 192.168.0.1:53 he leaves how ip external
200.200.200.1:53
I tried to do that. But no this working
iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
SNAT --to-source 200.200.200.1:53


Breno Cardoso Perucchi
breno@omegatec.net

RE: SNAT

[Rob Sterenborg]

> I want when to request internal 192.168.0.1:53 he leaves how
> ip external
> 200.200.200.1:53
> I tried to do that. But no this working
> iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> SNAT --to-source 200.200.200.1:53

I don't know if dns traffic is always sent *from* 53/udp, but I do
know it is always sent *to* 53/udp.

Do you have a default policy set to DROP in the FORWARD chain ?
Something like this should do the trick I think :
# iptables -A FORWARD -s 192.168.0.1 -p udp --dport 53 -o <eth-out> -j
ACCEPT
# iptables -t nat -A PREROUTING -s 192.168.0.1 -p tcp --dport 53 -j
SNAT --to-source 200.200.200.1


Rob

Re: SNAT

[Antony Stone]

On Tuesday 12 November 2002 9:01 pm, Rob Sterenborg wrote:

> > I want when to request internal 192.168.0.1:53 he leaves how
> > ip external
> > 200.200.200.1:53
> > I tried to do that. But no this working
> > iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> > SNAT --to-source 200.200.200.1:53
>
> I don't know if dns traffic is always sent *from* 53/udp, but I do
> know it is always sent *to* 53/udp.

Not *always* :-)   Sometimes it goes to 53/tcp...

Antony

-- 

With thanks to God,
For all that's come before,
For all that will come after,
But most of all, for this bit right here now.

RE: SNAT

[Luis Fernando Barrera]

I think that the DNS traffic goes only on 53/tcp when transfering
zones, and it uses the 53/udp for the queries.

Also, if you use the BIND implementation of the DNS server, you
can specify the source port, so the traffic can go from 53/udp to 53/udp

Luis Fernando Barrera 
luba@assist.com.gt


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Tuesday, November 12, 2002 15:29
To: netfilter@lists.netfilter.org
Subject: Re: SNAT


On Tuesday 12 November 2002 9:01 pm, Rob Sterenborg wrote:

> > I want when to request internal 192.168.0.1:53 he leaves how
> > ip external
> > 200.200.200.1:53
> > I tried to do that. But no this working
> > iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> > SNAT --to-source 200.200.200.1:53
>
> I don't know if dns traffic is always sent *from* 53/udp, but I do
> know it is always sent *to* 53/udp.

Not *always* :-)   Sometimes it goes to 53/tcp...

Antony

-- 

With thanks to God,
For all that's come before,
For all that will come after,
But most of all, for this bit right here now.

RE: SNAT

[Rob Sterenborg]

> > > > iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> > > > SNAT --to-source 200.200.200.1:53

> > > I don't know if dns traffic is always sent *from* 53/udp, but I do
> > > know it is always sent *to* 53/udp.

> > Not *always* :-)   Sometimes it goes to 53/tcp...

> I think that the DNS traffic goes only on 53/tcp when transfering
> zones, and it uses the 53/udp for the queries.
>
> Also, if you use the BIND implementation of the DNS server, you
> can specify the source port, so the traffic can go from
> 53/udp to 53/udp

Of course you're right.
Anyway, I interpret the original question as how to SNAT normal dns traffic
because the rule he wrote was using the udp protocol for *source* port
53/udp, which doesn't have to match *all* dns traffic (if it does).
That's why I mentioned that I don't know if dns traffic always come *from*
port 53/udp (here it doesn't ; it uses some port above 1024), but I do know
it's going *to* port 53/udp.


Rob

Re: SNAT

[Breno Cardoso Perucchi]

Everybody is talking about DNS tcp/udp. But I want know how I can do that my
traffic go to out as my IP_NET and not another IP. I know that I have to use
SNAT for to do this.

My problem is that my DNS this going out with IP NAT(Masquerade)
Somebody can help me

----- Original Message -----
From: "Rob Sterenborg" <rsterenborg@xs4all.nl>
To: "Netfilter (E-mail)" <netfilter@lists.netfilter.org>
Sent: Wednesday, November 13, 2002 9:21 AM
Subject: RE: SNAT


> > > > > iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> > > > > SNAT --to-source 200.200.200.1:53
>
> > > > I don't know if dns traffic is always sent *from* 53/udp, but I do
> > > > know it is always sent *to* 53/udp.
>
> > > Not *always* :-)   Sometimes it goes to 53/tcp...
>
> > I think that the DNS traffic goes only on 53/tcp when transfering
> > zones, and it uses the 53/udp for the queries.
> >
> > Also, if you use the BIND implementation of the DNS server, you
> > can specify the source port, so the traffic can go from
> > 53/udp to 53/udp
>
> Of course you're right.
> Anyway, I interpret the original question as how to SNAT normal dns
traffic
> because the rule he wrote was using the udp protocol for *source* port
> 53/udp, which doesn't have to match *all* dns traffic (if it does).
> That's why I mentioned that I don't know if dns traffic always come *from*
> port 53/udp (here it doesn't ; it uses some port above 1024), but I do
know
> it's going *to* port 53/udp.
>
>
> Rob
>
>
>

RE: SNAT

[Rob Sterenborg]

> Everybody is talking about DNS tcp/udp. But I want know how I
> can do that my
> traffic go to out as my IP_NET and not another IP. I know
> that I have to use
> SNAT for to do this.
>
> My problem is that my DNS this going out with IP NAT(Masquerade)
> Somebody can help me

I thought I did reply to your question. Don't the SNAT/FORWARD rules work ?

In your first post you didn't mention any of your FORWARD rules, and I still
think you should match your traffic for dport 53 instead of sport 53. Unless
ofcourse there's something we don't know because you didn't tell us (do you
have a DNS server ? If so ; is your DNS server running on or behind the
firewall ?).
If you have policy set to DROP for the FORWARD chain then you have to add a
rule to allow traffic for port 53/udp/tcp or whatever you want to
accomplish.


Rob

RE: SNAT

[Luis Fernando Barrera]

You mean you want to send your DNS queries to your ISP DNS server?

I guess you have a DNS server? O just want to consult (as a client) your ISP
DNS server?




-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Breno Cardoso
Perucchi
Sent: Wednesday, November 13, 2002 07:26
To: Netfilter (E-mail)
Subject: Re: SNAT


Everybody is talking about DNS tcp/udp. But I want know how I can do that my
traffic go to out as my IP_NET and not another IP. I know that I have to use
SNAT for to do this.

My problem is that my DNS this going out with IP NAT(Masquerade)
Somebody can help me

----- Original Message -----
From: "Rob Sterenborg" <rsterenborg@xs4all.nl>
To: "Netfilter (E-mail)" <netfilter@lists.netfilter.org>
Sent: Wednesday, November 13, 2002 9:21 AM
Subject: RE: SNAT


> > > > > iptables -t nat -I POSTROUTING -p udp -s 192.168.0.1 --sport 53 -j
> > > > > SNAT --to-source 200.200.200.1:53
>
> > > > I don't know if dns traffic is always sent *from* 53/udp, but I do
> > > > know it is always sent *to* 53/udp.
>
> > > Not *always* :-)   Sometimes it goes to 53/tcp...
>
> > I think that the DNS traffic goes only on 53/tcp when transfering
> > zones, and it uses the 53/udp for the queries.
> >
> > Also, if you use the BIND implementation of the DNS server, you
> > can specify the source port, so the traffic can go from
> > 53/udp to 53/udp
>
> Of course you're right.
> Anyway, I interpret the original question as how to SNAT normal dns
traffic
> because the rule he wrote was using the udp protocol for *source* port
> 53/udp, which doesn't have to match *all* dns traffic (if it does).
> That's why I mentioned that I don't know if dns traffic always come *from*
> port 53/udp (here it doesn't ; it uses some port above 1024), but I do
know
> it's going *to* port 53/udp.
>
>
> Rob
>
>
>

SNAT

[Rio Martin.]

Dear folks,
I need help to modify the source ip for every irc connection coming from my
clients.

Eg:

eth0    = 64.1.1.1
eth0:1 = 64.1.1.2
eth0:2 = 192.168.1.1


My clients is in 192.168.1.0/24. Right now all connection to irc server is
using ip 64.1.1.1
I want to modify, so all irc connection is using 64.1.1.2

Thanks for helping me ...

Regards,
Rio Martin.

RE: SNAT

[Daniel Chemko]

1. You are using aliases, which IPTables does not use. Please use look
into IPRoute2 on the net on how to setup proper IPRoute2 bindings.

2. Add an SNAT rule on the postrouting -o <internet_iface> pointing to
64.1.1.2

-----Original Message-----
From: Rio Martin. [mailto:rio@martin.mu] 
Sent: Thursday, April 03, 2003 2:29 AM
To: netfilter@lists.netfilter.org
Subject: SNAT

Dear folks,
I need help to modify the source ip for every irc connection coming from
my
clients.

Eg:

eth0    = 64.1.1.1
eth0:1 = 64.1.1.2
eth0:2 = 192.168.1.1


My clients is in 192.168.1.0/24. Right now all connection to irc server
is
using ip 64.1.1.1
I want to modify, so all irc connection is using 64.1.1.2

Thanks for helping me ...

Regards,
Rio Martin.

Re: SNAT

[Rio Martin.]

Okay,
I add another interface so that make looks like this:
eth0    = 64.1.1.1
eth0:1 = 192.168.1.1
eth1 = 64.1.1.2

also add iptables command:
# /sbin/iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 --dport
6667 -j SNAT --to 64.1.1.2

but still doesnt work, all users from 192.168.1.0/24 still irc using
64.1.1.1
need help.

Regards,
Rio Martin.



----- Original Message -----
From: "Daniel Chemko" <dchemko@smgtec.com>
To: "Rio Martin." <rio@martin.mu>; <netfilter@lists.netfilter.org>
Sent: Friday, April 04, 2003 1:34 AM
Subject: RE: SNAT


1. You are using aliases, which IPTables does not use. Please use look
into IPRoute2 on the net on how to setup proper IPRoute2 bindings.

2. Add an SNAT rule on the postrouting -o <internet_iface> pointing to
64.1.1.2

-----Original Message-----
From: Rio Martin. [mailto:rio@martin.mu]
Sent: Thursday, April 03, 2003 2:29 AM
To: netfilter@lists.netfilter.org
Subject: SNAT

Dear folks,
I need help to modify the source ip for every irc connection coming from
my
clients.

Eg:

eth0    = 64.1.1.1
eth0:1 = 64.1.1.2
eth0:2 = 192.168.1.1


My clients is in 192.168.1.0/24. Right now all connection to irc server
is
using ip 64.1.1.1
I want to modify, so all irc connection is using 64.1.1.2

Thanks for helping me ...

Regards,
Rio Martin.

Re: SNAT

[Daniel Chemko]

Rio Martin. wrote:

>Okay,
>I add another interface so that make looks like this:
>eth0    = 64.1.1.1
>eth0:1 = 192.168.1.1
>eth1 = 64.1.1.2
>
>also add iptables command:
># /sbin/iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 --dport
>6667 -j SNAT --to 64.1.1.2
>
>but still doesnt work, all users from 192.168.1.0/24 still irc using
>64.1.1.1
>need help.
>
>Regards,
>Rio Martin.
>
>
>
>----- Original Message -----
>From: "Daniel Chemko" <dchemko@smgtec.com>
>To: "Rio Martin." <rio@martin.mu>; <netfilter@lists.netfilter.org>
>Sent: Friday, April 04, 2003 1:34 AM
>Subject: RE: SNAT
>
>
>1. You are using aliases, which IPTables does not use. Please use look
>into IPRoute2 on the net on how to setup proper IPRoute2 bindings.
>
>2. Add an SNAT rule on the postrouting -o <internet_iface> pointing to
>64.1.1.2
>
>-----Original Message-----
>From: Rio Martin. [mailto:rio@martin.mu]
>Sent: Thursday, April 03, 2003 2:29 AM
>To: netfilter@lists.netfilter.org
>Subject: SNAT
>
>Dear folks,
>I need help to modify the source ip for every irc connection coming from
>my
>clients.
>
>Eg:
>
>eth0    = 64.1.1.1
>eth0:1 = 64.1.1.2
>eth0:2 = 192.168.1.1
>
>
>My clients is in 192.168.1.0/24. Right now all connection to irc server
>is
>using ip 64.1.1.1
>I want to modify, so all irc connection is using 64.1.1.2
>
>Thanks for helping me ...
>
>Regards,
>Rio Martin.
>
>
>
>
>
>
>
>  
>
*slaps his own  head* of course it does! Keep that rule in, but you have 
to mangle the packet route. If you have the ROUTE jump target, you can 
use that to explicitly use that to accomplish what you desire, making 
sure to apply your above rule to the outgoing interface, so just adding 
-o eth1 to your previously described rule.

Unfortunately, I have never personally used the ROUTE target so I am not 
sure the syntax. I think it would be something like:
iptables -t nat -A PREROUTING -p tcp --source 192.168.1.0/24 --dport 
6667 -j ROUTE --iface eth1
iptables -t nat -A POSTROUTING -o eth1 -p tcp --source 192.168.1.0/24 
--dport 6667 -j SNAT --to 64.1.1.2

You might need Patch-O-Matic to get the ROUTE option.

SNAT

[Andy Wood]

	There is no easy way to describe this, so I'll just start.

	I am running a Snort IDS/FW with 4 interfaces, but we'll just be
concerned with 2 (eth0 and eth2 + ipsec0).  Ipsec is functioning, so that is
not the problem.

Local subnet	10.10.41.0/24
Local GW		10.10.41.100

Remote Network:
Network		111.111.0.0/16
Eth0			111.111.3.160 (gw 111.111.3.129)
Eth2			111.111.3.163
Add. Route		route add 111.111.8.204 gw 111.111.3.129 dev eth2
(just cause I want to ensure it 			goes out eth2) and I
can ping that host; it does go out eth2

To ensure that there is no unintentional DROPping of packets there are only
3 rules:

iptables -A POSTROUTING -t nat -o ipsec0 -s 111.111.3.160 -d 10.10.41.0/24
-j SNAT --to 111.111.3.163
iptables -A POSTROUTING -t nat -o eth2 -s 10.10.41.0/24 -j SNAT --to
111.111.3.163
Iptables -A FORWARD -j ACCEPT

	Basically, I want to send a packet through the tunnel (ipsec0) and
out to system 111.111.8.204.  Because the packet will arrive as source
10.10.41.100, and I cannot control the route table of system 111.111.8.204,
I figured I would SNAT the packet from 10.10.41.100 to 111.111.3.163.  If I
do a tcpdump on ipsec0 I see the pachet coming in:

(Remote Side - Inbound) tcpdump -i ipsec0 -p -n -nn icmp
13:27:33.916290 10.10.41.100 > 111.111.8.204: icmp: echo request (DF)
13:27:34.919120 10.10.41.100 > 111.111.8.204: icmp: echo request (DF)
13:27:35.931122 10.10.41.100 > 111.111.8.204: icmp: echo request (DF)
13:27:36.923962 10.10.41.100 > 111.111.8.204: icmp: echo request (DF)

	However, (On the remote side) "tcpdump -i eth2 -p -n -nn icmp" or
"tcpdump -i eth0 -p -n -nn icmp" (just in case) do not show any packets
outbound (to 111.111.8.204).  I can't see anything wrong with my rules, but
sometimes I can't think outside the box.....any ideas?

Thanks,
Andy

	To verify the tunnel works:

[root@darkgate root]# ping 111.111.3.163

PING 111.111.3.163 (111.111.3.163) from 68.68.130.209 : 56(84) bytes of
data.
64 bytes from 111.111.3.163: icmp_seq=1 ttl=64 time=29.5 ms
64 bytes from 111.111.3.163: icmp_seq=2 ttl=64 time=31.7 ms
64 bytes from 111.111.3.163: icmp_seq=3 ttl=64 time=26.1 ms
64 bytes from 111.111.3.163: icmp_seq=4 ttl=64 time=26.7 ms



[root@testids root]# tcpdump -i ipsec0 -p -n -nn icmp

13:35:50.883841 10.10.41.100 > 111.111.3.163: icmp: echo request (DF)
13:35:50.884001 111.111.3.163 > 10.10.41.100: icmp: echo reply
13:35:51.832915 10.10.41.100 > 111.111.3.163: icmp: echo request (DF)
13:35:51.832976 111.111.3.163 > 10.10.41.100: icmp: echo reply
13:35:52.847691 10.10.41.100 > 111.111.3.163: icmp: echo request (DF)
13:35:52.847749 111.111.3.163 > 10.10.41.100: icmp: echo reply
13:35:53.859624 10.10.41.100 > 111.111.3.163: icmp: echo request (DF)
13:35:53.859684 111.111.3.163 > 10.10.41.100: icmp: echo reply

SNAT

[David Busby]

Dudes,
    I setup my SNAT like this:

iptables -t nat -I POSTROUTING 1 -s 10.0.0.0/24 -d 0/0 \
  -p tcp -m tcp --dport 80 \
  -j SNAT --to 1.2.3.66-1.2.3.126

So my lan outbound HTTP traffic gets shared over those 60 ip addresses.
Seems sweet, but I notice that netfilter doesn't always rotate the
addresses. And sometimes only switches a client between two addresses. Where
in the docs does it show me how to make this thing rotate addresses more
regularly, or if not in doc how would I do that?

David Busby
Systems Engineer
busby@pnts.com

SNAT

[Payal Rathod]

Hi,
While reading man page of iptables I stumbled in MASQUERADE section,

| This  target  is only valid in the nat table, in the POSTROUTING chain.
|  It should only be used with dynamically assigned  IP  (dialup)  connec-
|  tions: if you have a static IP address, you should use the SNAT target.

Can someone explain please why this is not valid when I am using a
permanent conneciton terminating at say eth0 and also a small example
on how SNAT can be used in the place?

Thanks a lot in advance.
With warm regards,
Payal

Re: SNAT

[John A. Sullivan III]

Payal Rathod wrote:
> Hi,
> While reading man page of iptables I stumbled in MASQUERADE section,
> 
> | This  target  is only valid in the nat table, in the POSTROUTING chain.
> |  It should only be used with dynamically assigned  IP  (dialup)  connec-
> |  tions: if you have a static IP address, you should use the SNAT target.
> 
> Can someone explain please why this is not valid when I am using a
> permanent conneciton terminating at say eth0 and also a small example
> on how SNAT can be used in the place?
> 
> Thanks a lot in advance.
> With warm regards,
> Payal
It is indeed valid, it is just slower than SNAT.  MASQUERADE must look 
up the address for each packet it alters (or so I believe).  That is why 
it can be used on connections which do not have a static IP address.  If 
one has a static IP address, one can save the overhead by using SNAT.

You'll find an excellent tutorial by Oskar Andreasson at 
http://www.netfilter.org in the tutorials section.  You can also find a 
training slide show in the training section at 
http://iscs.sourceforge.net.  Good luck - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net

RE: snat

[Ken Hilliard]

Hey, I'm pretty new to iptables. Where can I get a list of all these
iptables targets. For example, I never heard of (or read about) the SAME
target.

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jason
Opperisano
Sent: Monday, May 02, 2005 11:15 PM
To: netfilter@lists.netfilter.org
Subject: Re: snat

On Mon, May 02, 2005 at 11:07:38AM -0500, Taylor, Grant wrote:
> Marco Berizzi wrote:
> >Hello everybody.
> >I would like to better understand the SNAT target.
> >Man states:
> >
> >"You can add several --to-source option. If you specify
> >more than one source address, either via an address range
> >or multiple --to-source options, a simple round-robin  (one
> >after another in cycle) takes place between these addresses.
> >
> >I would like to know if this round-robin cycle is per packet
> >or per socket.
> >
> >TIA
> 
> Don't hold me to this, but I think that the SAME target will implement
some 
> SNATing across multiple IPs and ensure that any given connection and 
> possibly system will get the ""same source IP (hens the name) as it
goes 
> out.  Can any one back me up on this?

SAME is a way to have a pool of addresses for SNAT, but keep either (a)
connections between the same src and dst IP SNAT-ed to the same SNAT IP
or (b) all connections from a single src IP always get the same SNAT IP
(regardless of dst IP).

for the sake of completeness, SAME also works for DNAT as well.

-j

--
"Peter: Oh, you people can kiss the fattest part of my ass."
        --Family Guy

RE: snat

[Ken Hilliard]

Much thanks.

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jason
Opperisano
Sent: Tuesday, May 03, 2005 1:06 AM
To: netfilter@lists.netfilter.org
Subject: Re: snat

On Mon, May 02, 2005 at 09:52:14AM +0700, Ken Hilliard wrote:
> Hey, I'm pretty new to iptables. Where can I get a list of all these
> iptables targets. For example, I never heard of (or read about) the
SAME
> target.

browse the descriptions at the netfilter site (or mirror of your
choosing):

  http://netfilter.org/patch-o-matic/pom-submitted.html
  http://netfilter.org/patch-o-matic/pom-pending.html
  http://netfilter.org/patch-o-matic/pom-base.html
  http://netfilter.org/patch-o-matic/pom-extra.html

or--if your prefer, browse the help and info files directly from the SVN
repository:

  http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/

or--checkout your own copy of PoM from SVN, and browse the files in your
local copy (if you ever actually want to apply any of the patches, this
is probably the best route to go):

  svn co https://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng

HTH...

-j

--
"Grinch: You think you have won, you think all is well. Well kiss my
 green ass, I'll see you in hell."
        --Family Guy

snat

[Marco Berizzi]

Hello everybody.
I would like to better understand the SNAT target.
Man states:

"You can add several --to-source option. If you specify
more than one source address, either via an address range
or multiple --to-source options, a simple round-robin  (one
after another in cycle) takes place between these addresses.

I would like to know if this round-robin cycle is per packet
or per socket.

TIA

Re: snat

[Jason Opperisano]

On Mon, May 02, 2005 at 05:32:42PM +0200, Marco Berizzi wrote:
> Hello everybody.
> I would like to better understand the SNAT target.
> Man states:
> 
> "You can add several --to-source option. If you specify
> more than one source address, either via an address range
> or multiple --to-source options, a simple round-robin  (one
> after another in cycle) takes place between these addresses.
> 
> I would like to know if this round-robin cycle is per packet
> or per socket.

per connection.

-j

--
"Peter: Don't worry Lois. I'll handle this. I read a book about
 this kind of thing once. 
 Brian: Are you sure it was in a book? Are you sure it
 wasn't...nothing?"
        --Family Guy

Re: snat

[Taylor, Grant]

Marco Berizzi wrote:
> Hello everybody.
> I would like to better understand the SNAT target.
> Man states:
> 
> "You can add several --to-source option. If you specify
> more than one source address, either via an address range
> or multiple --to-source options, a simple round-robin  (one
> after another in cycle) takes place between these addresses.
> 
> I would like to know if this round-robin cycle is per packet
> or per socket.
> 
> TIA

Don't hold me to this, but I think that the SAME target will implement some SNATing across multiple IPs and ensure that any given connection and possibly system will get the ""same source IP (hens the name) as it goes out.  Can any one back me up on this?



Grant. . . .

Re: snat

[Jason Opperisano]

On Mon, May 02, 2005 at 11:07:38AM -0500, Taylor, Grant wrote:
> Marco Berizzi wrote:
> >Hello everybody.
> >I would like to better understand the SNAT target.
> >Man states:
> >
> >"You can add several --to-source option. If you specify
> >more than one source address, either via an address range
> >or multiple --to-source options, a simple round-robin  (one
> >after another in cycle) takes place between these addresses.
> >
> >I would like to know if this round-robin cycle is per packet
> >or per socket.
> >
> >TIA
> 
> Don't hold me to this, but I think that the SAME target will implement some 
> SNATing across multiple IPs and ensure that any given connection and 
> possibly system will get the ""same source IP (hens the name) as it goes 
> out.  Can any one back me up on this?

SAME is a way to have a pool of addresses for SNAT, but keep either (a)
connections between the same src and dst IP SNAT-ed to the same SNAT IP
or (b) all connections from a single src IP always get the same SNAT IP
(regardless of dst IP).

for the sake of completeness, SAME also works for DNAT as well.

-j

--
"Peter: Oh, you people can kiss the fattest part of my ass."
        --Family Guy

RE: snat

[Charlie Brady]

On Mon, 2 May 2005, Ken Hilliard wrote:

> Hey, I'm pretty new to iptables. Where can I get a list of all these
> iptables targets.

Most netfilter documentation is at http://www.netfilter.org/.

> For example, I never heard of (or read about) the SAME
> target.

http://www.netfilter.org/patch-o-matic/pom-submitted.html#pom-submitted-SAME

[Google "netfilter+SAME" would have found you that pretty quickly.]

Re: snat

[Jason Opperisano]

On Mon, May 02, 2005 at 09:52:14AM +0700, Ken Hilliard wrote:
> Hey, I'm pretty new to iptables. Where can I get a list of all these
> iptables targets. For example, I never heard of (or read about) the SAME
> target.

browse the descriptions at the netfilter site (or mirror of your
choosing):

  http://netfilter.org/patch-o-matic/pom-submitted.html
  http://netfilter.org/patch-o-matic/pom-pending.html
  http://netfilter.org/patch-o-matic/pom-base.html
  http://netfilter.org/patch-o-matic/pom-extra.html

or--if your prefer, browse the help and info files directly from the SVN
repository:

  http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/

or--checkout your own copy of PoM from SVN, and browse the files in your
local copy (if you ever actually want to apply any of the patches, this
is probably the best route to go):

  svn co https://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng

HTH...

-j

--
"Grinch: You think you have won, you think all is well. Well kiss my
 green ass, I'll see you in hell."
        --Family Guy

Re: snat

[Marco Berizzi]

Jason Opperisano wrote:

> On Mon, May 02, 2005 at 05:32:42PM +0200, Marco Berizzi wrote:
> > Hello everybody.
> > I would like to better understand the SNAT target.
> > Man states:
> >
> > "You can add several --to-source option. If you specify
> > more than one source address, either via an address range
> > or multiple --to-source options, a simple round-robin  (one
> > after another in cycle) takes place between these addresses.
> >
> > I would like to know if this round-robin cycle is per packet
> > or per socket.
>
> per connection.
>
> -j

Thanks everybody.

SNAT

[Chad Eldridge]

I have a situation where I have packets coming into a server (we'll call 
it RTR) and getting routed to other servers depending on the ip address 
the packet is coming from. This part works great. The problem I am 
having is when the server (call it Responder) answers back to the 
original client (not going back through RTR), the client sees the 
traffic coming from an address it did not originally try to open a 
connection to and therefore rejects the packets and the connection is 
never established. I thought I could fix this by using SNAT to change 
the source ip on Responder.
iptables -t nat -A POSTROUTING -p tcp -m tcp --sport $PORT -j SNAT --to 
$RTR-IP
This however, seems to do nothing. The Responder still sends replies to 
the client, they make it to the client and show up as coming from the ip 
address of Responder.
It was suggested to me that I would need to turn off rp_filter (echo 0 > 
/proc/sys/net/ipv4/conf/all/rp_filter; echo 0 > 
/proc/sys/net/ipv4/conf/eth0/rp_filter) since the ip address I am trying 
to change the source to does not actually exist on the server. I tried 
that but it did not seem to help. Further more it was suggested that I 
could setup the $RTR-IP on a loopback and arptables it off and then it 
should work. This did not work either. If it is because iptables is 
trying to prevent spoofing I'm guessing it is stopping it because it's 
trying to send it out an interface that does not have the ip on it. Then 
again, all of this guessing could be wrong.
Is this even possible with iptables? If so, how can I accomplish it? 
Everything I have seen that seems like it should work has so far failed.
iptables v1.2.8
Redhat ES3
(Final box will probably be running ES4)

Thanks,

-- 
Chad Eldridge
Security | Web.com
celdridge@corp.web.com
404.260.2580

Re: SNAT

[Grant Taylor]

On 10/09/07 13:47, Chad Eldridge wrote:
> I have a situation where I have packets coming into a server (we'll 
> call it RTR) and getting routed to other servers depending on the ip 
> address the packet is coming from. This part works great. The problem 
> I am having is when the server (call it Responder) answers back to 
> the original client (not going back through RTR), the client sees the 
> traffic coming from an address it did not originally try to open a 
> connection to and therefore rejects the packets and the connection is 
> never established. I thought I could fix this by using SNAT to change 
> the source ip on Responder.
> 
> iptables -t nat -A POSTROUTING -p tcp -m tcp --sport $PORT -j SNAT 
> --to $RTR-IP

Ah, you are falling victim to what I consider a communications triangle. 
  You are describing exactly what happens.  A connects to B, B redirects 
to C, C responds to A, and A is rather distraught that B is ignoring him 
/ her while this yahoo C is not using proper protocol / grammar to start 
a conversation.

> This however, seems to do nothing. The Responder still sends replies 
> to the client, they make it to the client and show up as coming from 
> the ip address of Responder.

Where did you try to SNAT?  Were you trying to SNAT on RTR to make the 
Responder think the traffic came from RTR or were you trying to SNAT on 
the Responder to make the traffic to the client look like it came from 
RTR?  I'm guessing the second method seeing as how the first should have 
worked (and has for me).  I suppose that if you could get the source IP 
of the traffic from Responder to really be that of RTR things would work 
too, but I'm not sure what type of reverse path issues you will have / 
need to over come.

> It was suggested to me that I would need to turn off rp_filter (echo 
> 0 /proc/sys/net/ipv4/conf/all/rp_filter; echo 0 
> /proc/sys/net/ipv4/conf/eth0/rp_filter) since the ip address I am 
> trying to change the source to does not actually exist on the server. 
> I tried that but it did not seem to help. Further more it was 
> suggested that I could setup the $RTR-IP on a loopback and arptables 
> it off and then it should work. This did not work either. If it is 
> because iptables is trying to prevent spoofing I'm guessing it is 
> stopping it because it's trying to send it out an interface that does 
> not have the ip on it. Then again, all of this guessing could be 
> wrong.

Well to start with, you do not want to use the loop back interface 
because the kernel will protect it at all costs.  In short, the only 
thing that can communicate with the loop back device is the loop back 
device its self.  Any and all attempts that I'm aware of to over come 
this short of an application layer proxy that binds to loop back and 
other interfaces will most likely fail with out some kernel patching.

I feel like I just answered a similar question with in the last week or 
so.  I think that question had to do with pseudo load balancing though. 
  However the answer to that question fits here too.

> Is this even possible with iptables? If so, how can I accomplish it? 
> Everything I have seen that seems like it should work has so far 
> failed.

I'm not sure if IPTables can solve this its self or not.  You may need 
some help from bridging and EBTables.

I have to ask, are the responders hidden behind the router?  I'm 
guessing now because it sounds like the responder is talking directly 
back to the client.  Thus are the router and responders in the same 
subnet / broadcast domain?  For the sake of conversation I'm going to 
presume the latter.  So let's have some ASCII art to help explain this.

                  +------------+
                  | Default GW |
                  +-----+------+
                        |
     +------------+-----+------+------------+
     |            |            |            |
+---+----+   +---+----+   +---+----+   +---+----+
| Router |   | Host A |   | Host B |   | Host C |
+--------+   +--------+   +--------+   +--------+

Let's presume for the sake of conversation that a client connects in to 
Router from the internet.  Router decides to redirect the traffic to 
Host A based on the source IP address.  At the same time a different 
client connects in to Router from the internet.  However this second 
client is from a different IP address and as such Router decides to 
redirect the traffic to Host C.

Router and Hosts A, B, and C, all need to have the same IP bound to an 
interface that will allow non localhost communications to them (read: 
not loop back).  Hosts A, B, and C need to NOT respond to ARPs from 
Default GW to find the IP in question so that you can be sure that 
Router will respond and be found.  Thus Default GW will send the packets 
destined to the target IP to Router.  Router will then need to redirect 
the packets over to Host A or B or C as it sees fit.  Hosts A, B, and C 
will then receive the packet and process the request and respond in kind 
back out Default GW.  This way, the original client will see the correct 
source IP on the reply traffic.

Using EBTables Router can alter the destination MAC address the packets 
coming in based on the source IP.  Thus you can use EBTables to redirect 
some traffic to Host and some to Host B and some to Host C as you see fit.

You may need to have multiple IP addresses bound to the network 
interfaces of Hosts A, B, and C so that they respond from the correct 
source IP while using Default GW on a different subnet so that Default 
GW does not update it's ARP cache with the new MAC addresses of Host A 
or B or C.

At least as I understand it, this is how one mode of LVS operates.  This 
will also work for what you are wanting to do.

> iptables v1.2.8
> Redhat ES3
> (Final box will probably be running ES4)

As long as you include EBTables and / or LVS in the mix I don't think 
the difference between ES3 and ES4 will matter.

> Thanks,

*nod*

Good luck.



Grant. . . .

SNAT

[cc]

Hi,

Long story short, I'm now rebuilding a netfilter firewall 
script as the original died with the firewall.  Well, died
in the sense that it got corrupted.

Instead of needing to specify the following for each required
port that needs to be used to connect to external sites,
how do I just let any traffic originating from the LAN
to connect?  (I'm feeling this isn't the right way of doing
things.  I appreciate any corrections.)

$IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
           --dport 1025: -j SNAT --to-source $EXTIP

But the above rule 'looks' like it should work; but it
doesn't.  tcpdumping the traffic, it seems the traffic is
going one way and not the other.

So if I want to set the firewall to allow the following
situations: machine A in $LAN_NET  wants to RDP to an external
site,  it can.  If machine B wants to surf the net, it also
can.  I don't need to separately do the following:

  $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
           --dport 3389 -j ACCEPT
  $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
           --dport 80 -j ACCEPT
  $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
           --dport 443 -j ACCEPT

  $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
          --dport 3389 -j SNAT --to-source $EXTIP
  $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
          --dport 80 -j SNAT --to-source $EXTIP
  $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
          --dport 443 -j SNAT --to-source $EXTIP



Now if I remembered, I used MASQUERADE when I was using 
a dynamic IP.  Now with a fixed IP, I shouldn't be using
MASQUERADE (seems less of a headache) as the manual says 
it's more appropriate to use SNAT for fixed IP.

Any help/clarifications/hints appreciated.

Ed

Re: SNAT

[SamLT]

On Wed, Feb 22, 2012 at 10:04:32AM +0800, cc wrote:
> Hi,
> 
> Long story short, I'm now rebuilding a netfilter firewall 
> script as the original died with the firewall.  Well, died
> in the sense that it got corrupted.
> 
> Instead of needing to specify the following for each required
> port that needs to be used to connect to external sites,
> how do I just let any traffic originating from the LAN
> to connect?  (I'm feeling this isn't the right way of doing
> things.  I appreciate any corrections.)
> 
> $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
>            --dport 1025: -j SNAT --to-source $EXTIP
> 
> But the above rule 'looks' like it should work; but it
> doesn't.  tcpdumping the traffic, it seems the traffic is
> going one way and not the other.
> 
> So if I want to set the firewall to allow the following
> situations: machine A in $LAN_NET  wants to RDP to an external
> site,  it can.  If machine B wants to surf the net, it also
> can.  I don't need to separately do the following:
> 
>   $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
>            --dport 3389 -j ACCEPT
>   $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
>            --dport 80 -j ACCEPT
>   $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -s $LAN_NET \
>            --dport 443 -j ACCEPT

You need to allow the reply too, e.g. for tcp 443, you could add this
rule:
|   $IPT -A FORWARD -o $LANETH -i $EXTETH -p tcp -d $LAN_NET \
|            --sport 443 -m state --state ESTABLISHED -j ACCEPT


Doing it this way, you'd also need to allow, at least, ICMP RELATED
packets.


> 
>   $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
>           --dport 3389 -j SNAT --to-source $EXTIP
>   $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
>           --dport 80 -j SNAT --to-source $EXTIP
>   $IPT -t nat -A POSTROUTING -o $EXTETH -p tcp -s $LAN_NET \
>           --dport 443 -j SNAT --to-source $EXTIP
> 


Instead of doing it per "tcp connection", if you don't have special
needs, you could SNAT globally, allow the outbound traffic you want, and
allow every inbound ESTABLISHED and RELATED traffic. e.g.:

|   $IPT -t nat -A POSTROUTING -o $EXTETH -s $LAN_NET \
|           -j SNAT --to-source $EXTIP
|   $IPT -A FORWARD -o $LANETH -i $EXTETH -d $LAN_NET -m state \
|           --state ESTABLISHED,RELATED -j ACCEPT
|   $IPT -A FORWARD -i $LANETH -o $EXTETH -p tcp -d $LAN_NET \
|           -m multiport --dports 80,443,3389 -j ACCEPT


This may or may not suit you though.



> 
> 
> Now if I remembered, I used MASQUERADE when I was using 
> a dynamic IP.  Now with a fixed IP, I shouldn't be using
> MASQUERADE (seems less of a headache) as the manual says 
> it's more appropriate to use SNAT for fixed IP.
> 
> Any help/clarifications/hints appreciated.
> 
> Ed
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html