SNAT Question

SNAT Question

[Burton]

I need help setting up a server I am working with.
 
I am not very knowledgeable in regards to Linux. 
 
With that in mind I have read several HOWTO's and I am convinced that SNAT
is what I need to do this.
 
What I am trying to do is I have to servers on two different T1's located on
the same switch.
 
I would like server1 (my Linux Server) to accept an incoming connecting via
its IP address on T1(1) 12..22.81.18 on port 10025 and forward that request
to server2(my Windows Mail Server)  on T1(2) 204.250.113.2 on port 25
 
I have tried several combinations of 
iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --dport 10025 --to
204.250.113.2:25 
 
What am I doing wrong or am I looking at the wrong tool.
 

Re: SNAT Question

[Lopsch]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Burton schrieb:
> I need help setting up a server I am working with.
>  
> I am not very knowledgeable in regards to Linux. 
>  
> With that in mind I have read several HOWTO's and I am convinced that SNAT
> is what I need to do this.
>  
> What I am trying to do is I have to servers on two different T1's located on
> the same switch.
>  
> I would like server1 (my Linux Server) to accept an incoming connecting via
> its IP address on T1(1) 12..22.81.18 on port 10025 and forward that request
> to server2(my Windows Mail Server)  on T1(2) 204.250.113.2 on port 25
>  
> I have tried several combinations of 
> iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --dport 10025 --to
> 204.250.113.2:25 
>  
> What am I doing wrong or am I looking at the wrong tool.
>  
> 
> 

You need DNAT not SNAT ;). And you need a apropriate FORWARD rule if 
your default policy is DROP.

iptables -t nat -A PREROUTING -i ethx -p tcp --dport 10025 -j DNAT --to 
204.250.113.2:25

iptables -t filter -A FORWARD -i ethx -d 204.250.113.2 -o ethx -p tcp 
--dport 25 -j ACCEPT


-- 

PGP-ID 0xF8EAF138

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 825 bytes --]

RE: SNAT question

[Gary W. Smith]

I went back to the sample source and changes a couple little items to march how they had it.  It still fails for each internel request for the external ip with the exception of the firewall itself.
 
ping 206.17.98.52 from machine 206.17.98.60 results in a return from 192.168.0.52.  
 
#Incoming Maps
[0:0] -A PREROUTING -d 206.17.98.51 -j DNAT --to-destination 192.168.0.51
[0:0] -A PREROUTING -d 206.17.98.52 -j DNAT --to-destination 192.168.0.52
...
[0:0] -A PREROUTING -d 206.17.98.62 -j DNAT --to-destination 192.168.0.62
#Outgoing Maps 
[0:0] -A POSTROUTING -d 206.17.98.51 -j SNAT --to-source 192.168.0.51
[0:0] -A POSTROUTING -d 206.17.98.52 -j SNAT --to-source 192.168.0.52
...
[0:0] -A POSTROUTING -d 206.17.98.62 -j SNAT --to-source 192.168.0.62
[0:0] -A POSTROUTING -o eth0 -j SNAT --to-source 206.17.98.50
#************************************************************
[0:0] -A OUTPUT -d 192.168.0.51 -j DNAT --to-destination 206.17.98.51
[0:0] -A OUTPUT -d 192.168.0.52 -j DNAT --to-destination 206.17.98.52
...
[0:0] -A OUTPUT -d 192.168.0.62 -j DNAT --to-destination 206.17.98.62

I know that I must be missing something simple.
 
Gary Smith
 

________________________________

From: netfilter-bounces@lists.netfilter.org on behalf of Gary W. Smith
Sent: Sun 11/14/2004 2:53 PM
To: netfilter@lists.netfilter.org
Subject: SNAT question



I'm having a problem with DNAT/SNAT.

I have this on a couple firewalls at different places and it works
great.  I'm implementing this on a new firewall based on RHEL3 and it
seems to work great for everything except local servers with external
IP's.  Trying to access 206.14.210.52 internally returns me
192.168.0.52.  If I access it from the firewall it all works fine.  If I
access from another workstation or the server itself then it returns the
local IP as part of the ping.

Some time ago on another firewall with multiple segments someone told me
to put this:
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -d 192.168.0.52 -j SNAT
--to-source 206.17.98.52

On another firewall at another location I found that they had
-A POSTROUTING -s 192.168.0.52 -d 192.168.0.52 -j SNAT --to-source
206.17.98.52

Something to note that this is a custom RHEL3v3 compile with
pptp-conntrack compiled in.  We also recompiled iptables using the new
userspace changes.

The location where I got the information regarding the original
DNAT/SNAT is:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html#DNATTARGET


Here is the actual PRE/POST/OUT routing section

[0:0] -A PREROUTING -d 206.14.210.51 -j DNAT --to-destination
192.168.0.51
[0:0] -A PREROUTING -d 206.14.210.52 -j DNAT --to-destination
192.168.0.52
...
[0:0] -A PREROUTING -d 206.14.210.62 -j DNAT --to-destination
192.168.0.62

[0:0] -A POSTROUTING -s 192.168.0.51 -o eth0 -j SNAT --to-source
206.14.210.51
[0:0] -A POSTROUTING -s 192.168.0.52 -o eth0 -j SNAT --to-source
206.14.210.52
#[0:0] -A POSTROUTING -s 192.168.0.52 -d 192.168.0.52 -j SNAT
--to-source 206.17.98.52
...
[0:0] -A POSTROUTING -s 192.168.0.62 -o eth0 -j SNAT --to-source
206.17.98.62
[0:0] -A POSTROUTING -o eth0 -j SNAT --to-source 206.17.98.50

[0:0] -A OUTPUT -d 206.17.98.51 -j DNAT --to-destination 192.168.0.51
[0:0] -A OUTPUT -d 206.17.98.52 -j DNAT --to-destination 192.168.0.52
...
[0:0] -A OUTPUT -d 206.17.98.62 -j DNAT --to-destination 192.168.0.62

SNAT question

[Gary W. Smith]

I'm having a problem with DNAT/SNAT.

I have this on a couple firewalls at different places and it works
great.  I'm implementing this on a new firewall based on RHEL3 and it
seems to work great for everything except local servers with external
IP's.  Trying to access 206.14.210.52 internally returns me
192.168.0.52.  If I access it from the firewall it all works fine.  If I
access from another workstation or the server itself then it returns the
local IP as part of the ping.

Some time ago on another firewall with multiple segments someone told me
to put this:
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -d 192.168.0.52 -j SNAT
--to-source 206.17.98.52

On another firewall at another location I found that they had 
-A POSTROUTING -s 192.168.0.52 -d 192.168.0.52 -j SNAT --to-source
206.17.98.52

Something to note that this is a custom RHEL3v3 compile with
pptp-conntrack compiled in.  We also recompiled iptables using the new
userspace changes.

The location where I got the information regarding the original
DNAT/SNAT is:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html#DNATTARGET


Here is the actual PRE/POST/OUT routing section

[0:0] -A PREROUTING -d 206.14.210.51 -j DNAT --to-destination
192.168.0.51
[0:0] -A PREROUTING -d 206.14.210.52 -j DNAT --to-destination
192.168.0.52
...
[0:0] -A PREROUTING -d 206.14.210.62 -j DNAT --to-destination
192.168.0.62

[0:0] -A POSTROUTING -s 192.168.0.51 -o eth0 -j SNAT --to-source
206.14.210.51
[0:0] -A POSTROUTING -s 192.168.0.52 -o eth0 -j SNAT --to-source
206.14.210.52
#[0:0] -A POSTROUTING -s 192.168.0.52 -d 192.168.0.52 -j SNAT
--to-source 206.17.98.52
...
[0:0] -A POSTROUTING -s 192.168.0.62 -o eth0 -j SNAT --to-source
206.17.98.62
[0:0] -A POSTROUTING -o eth0 -j SNAT --to-source 206.17.98.50

[0:0] -A OUTPUT -d 206.17.98.51 -j DNAT --to-destination 192.168.0.51
[0:0] -A OUTPUT -d 206.17.98.52 -j DNAT --to-destination 192.168.0.52
...
[0:0] -A OUTPUT -d 206.17.98.62 -j DNAT --to-destination 192.168.0.62

Re: SNAT question

[Alexey Toptygin]

On Fri, 17 Sep 2004, [iso-8859-1] darmian martinez wrote:

> Alexey,
>
> I tried your command, but it says:
> iptables: Target problem

What I meant to say was:

iptables -t nat -A POSTROUTING -s [FIREWALL_IP] -p icmp -j SNAT --to-source
[FAKE_IP]

which applies, but for some reason works only for outgoing requests.


Can someone on the list explain why this:

iptables -t nat -A POSTROUTING -s 192.168.1.9 -p icmp -j SNAT --to-source
10.0.0.1

Causes this:

# tcpdump -nnvl -i eth0 "icmp"
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

17:37:38.781912 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 84)
10.0.0.1 > 192.168.1.2: icmp 64: echo request seq 1

17:37:49.656966 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 84)
192.168.1.181 > 192.168.1.9: icmp 64: echo request seq 1

17:37:49.656988 IP (tos 0x0, ttl  64, id 6381, offset 0, flags [none],
length: 84) 192.168.1.9 > 192.168.1.181: icmp 64: echo reply seq 1

Do locally generated ICMP replies not go through postrouting for some 
reason? I'm testing with iptables v1.2.9 and Debian kernel 2.6.7-1-k7.

 			Alexey

Re: SNAT question

[darmian martinez]

Alex,
 
It's doesn't work because NAT rules applies only to new connections, and
the icmp reply packet is part of an "virtual" established connection.
This is my original question, how to make a rule that make a NAT to 
a packet that belong to already established connection.
 
thanks you.

Alexey Toptygin <alexeyt@freeshell.org> wrote:
On Fri, 17 Sep 2004, [iso-8859-1] darmian martinez wrote:

> Alexey,
>
> I tried your command, but it says:
> iptables: Target problem

What I meant to say was:

iptables -t nat -A POSTROUTING -s [FIREWALL_IP] -p icmp -j SNAT --to-source
[FAKE_IP]

which applies, but for some reason works only for outgoing requests.


Can someone on the list explain why this:

iptables -t nat -A POSTROUTING -s 192.168.1.9 -p icmp -j SNAT --to-source
10.0.0.1

Causes this:

# tcpdump -nnvl -i eth0 "icmp"
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

17:37:38.781912 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84)
10.0.0.1 > 192.168.1.2: icmp 64: echo request seq 1

17:37:49.656966 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84)
192.168.1.181 > 192.168.1.9: icmp 64: echo request seq 1

17:37:49.656988 IP (tos 0x0, ttl 64, id 6381, offset 0, flags [none],
length: 84) 192.168.1.9 > 192.168.1.181: icmp 64: echo reply seq 1

Do locally generated ICMP replies not go through postrouting for some 
reason? I'm testing with iptables v1.2.9 and Debian kernel 2.6.7-1-k7.

Alexey

		100mb gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
¡Tenelo ya!

Re: SNAT question

[Jason Opperisano]

On Sun, 2004-09-19 at 13:10, darmian martinez wrote:
> Alex,
>  
> It's doesn't work because NAT rules applies only to new connections, and
> the icmp reply packet is part of an "virtual" established connection.
> This is my original question, how to make a rule that make a NAT to 
> a packet that belong to already established connection.
>  
> thanks you.

not an answer, but a hint...

if you need to fiddle with packets that are replies to established
connections--investigate the capabilities of the RAW table patch from
POM and its NOTRACK capabilities.

-j

-- 
Jason Opperisano <opie@817west.com>

SNAT question

[darmian martinez]

Hello,
 
I am trying to change the source ip address of icmp reply packets of the
firewall, just because i am trying to hide the firewall ip address in the case someone makes a traceroute to my protected network. I dont want
to block the icmp packet, just to change the source ip address.
i try it with:
 
iptables -t nat -I POSTROUTING -s [FIREWALL_IP] -d [TRACEROUTE_ORIGINATOR] -m state --state RELATED,NEW,ESTABLISHED -j SNAT --to [FAKE_IP_ADDRESS]
 
it's does not work. anyone know how to make it?
 
thanks.

		100mb gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
¡Tenelo ya!

Re: SNAT question

[John A. Sullivan III]

On Thu, 2004-09-16 at 13:20, darmian martinez wrote:
> Hello,
>  
> I am trying to change the source ip address of icmp reply packets of the
> firewall, just because i am trying to hide the firewall ip address in the case someone makes a traceroute to my protected network. I dont want
> to block the icmp packet, just to change the source ip address.
> i try it with:
>  
> iptables -t nat -I POSTROUTING -s [FIREWALL_IP] -d [TRACEROUTE_ORIGINATOR] -m state --state RELATED,NEW,ESTABLISHED -j SNAT --to [FAKE_IP_ADDRESS]
>  
> it's does not work. anyone know how to make it?
<snip>
We handle this a little differently in the ISCS project
(http://iscs.sourceforge.net).  Instead, we have a drop rule in the
mangle table to drop any packet with a TTL of 1 rather than sending back
a TTL expired ICMP packet.  At least I think that's what I remember
doing :-)

We had originally planned to simply increment the TTL by 1 so that a
packet would never expire on the gateway but then decided that was a bad
way to go about it.
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com

SNAT question

[Felipe]

It's necessary to set up phisically the public address used in SNAT rule ?
For this rule:

iptables -t nat -A POSTROUTING -s 172.21.0.0/16 -j SNAT --to 200.110.2.181

For that rule, its necessay set up phisically the IP 200.110.2.181 over the interface ?

Thanks for your response


Felipe

Re: SNAT question

[Antony Stone]

On Monday 01 March 2004 11:56 pm, Felipe wrote:

> It's necessary to set up phisically the public address used in SNAT rule ?
> For this rule:
>
> iptables -t nat -A POSTROUTING -s 172.21.0.0/16 -j SNAT --to 200.110.2.181
>
> For that rule, its necessay set up phisically the IP 200.110.2.181 over the
> interface ?

No, it is not necessary to set up that address on that interface in order to 
use that rule and send out packets with that source address.

However, if you send out packets with that source address, and you want to 
receive the replies, the address must exist on whatever machine the address 
will get routed to.

If you are only doing UDP transmits, and never expect a reply, it might work.

Regards,

Antony.

-- 
"The joy of X!!??  I've always hated compiling graphical shite.  You have a 10 
line program, and it ends up depending on the entire known universe."

 - Philip Hands

                                                     Please reply to the list;
                                                           please don't CC me.

Re: SNAT question

[Felipe]

Is there any special configuration to do this, perhaps any kernel values?
That's because without set up the ip on the interface that rule doesn't work

Thanks

Felipe

Antony Stone <Antony@Soft-Solutions.co.uk> escribió:

> On Monday 01 March 2004 11:56 pm, Felipe wrote:
> 
> > It's necessary to set up phisically the public address used in SNAT
> rule ?
> > For this rule:
> >
> > iptables -t nat -A POSTROUTING -s 172.21.0.0/16 -j SNAT --to
> 200.110.2.181
> >
> > For that rule, its necessay set up phisically the IP 200.110.2.181
> over the
> > interface ?
> 
> No, it is not necessary to set up that address on that interface in
> order to 
> use that rule and send out packets with that source address.
> 
> However, if you send out packets with that source address, and you want
> to 
> receive the replies, the address must exist on whatever machine the
> address 
> will get routed to.
> 
> If you are only doing UDP transmits, and never expect a reply, it might
> work.
> 
> Regards,
> 
> Antony.
> 
> -- 
> "The joy of X!!??  I've always hated compiling graphical shite.  You
> have a 10 
> line program, and it ends up depending on the entire known universe."
> 
>  - Philip Hands
> 
>                                                      Please reply to the
> list;
>                                                            please don't
> CC me.
> 
> 
> 

SNAT question

[John Black]

Everything works, when i do the lazy way and go to the web page www.whatismyipaddress.com.


but my question is when i went to the MS chat room, it was showing me the 192.168.x.x
ipaddress.

why is this?

john



http://www.arbbs.net/

Re: SNAT question

[Antony Stone]

On Friday 20 February 2004 8:15 pm, John Black wrote:

> Everything works, when i do the lazy way and go to the web page
> www.whatismyipaddress.com.
>
>
> but my question is when i went to the MS chat room, it was showing me the
> 192.168.x.x ipaddress.
>
> why is this?

Because Microsoft always do things differently from everyone else :) ?


No, seriously though, some protocols embed the IP address of the machines 
which are communicating inside the data which is transferred, so each end 
knows what the other end's true IP address is, even if this then means they 
can't talk to each other because one or both ends has an unroutable address.

As far as I'm aware MS Chat is one of these protocols, although I've certainly 
never used it myself.


One thing you should be aware of is that if you use such a protocol to test 
your network / firewall setup, then you should count yourself lucky that it 
appears to work at all.   Many such protocols (which network people refer to 
as embedding OSI layer 3 data inside OSI layer 7 packets) simply do not work 
across NAT at all.

Hope this helps clarify your confusion.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.

Re: SNAT question

[John Black]

> 
> Because Microsoft always do things differently from everyone else :) ?
> 

> 
> Hope this helps clarify your confusion.
> 

yes it does, thank you

john

Re: SNAT question

[John A. Sullivan III]

On Fri, 2004-02-20 at 15:15, John Black wrote:
> Everything works, when i do the lazy way and go to the web page www.whatismyipaddress.com.
> 
> 
> but my question is when i went to the MS chat room, it was showing me the 192.168.x.x
> ipaddress.
> 
> why is this?
I do not know the innards of the MS Chat protocol but could it be that
it embeds the address information in the data portion of the packet? -
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 

SNAT question

[Jean-Rene Cormier]

Okay here is the thing. I have a full Class C to work with and I want to
make a Linux Firewall/NAT box using Netfilter and I was wondering, say I
have 50 IPs in my Class C I want to use for SNAT. Do I have to add all
50 IPs on the Linux box's interface? 

Thanks

Jean-Rene Cormier

RE: SNAT question

[mailinglists]

Hi

this is my problem:

+ iptables -t mangle -A PREROUTING -i eth1 -j TTL --ttl-inc 1
iptables: No chain/target/match by that name

modprobe ipt_ttl is in my script. 
According to 
http://cert.uni-stuttgart.de/archive/usenet/comp.os.linux.security/2002/08/m
sg00458.html
there should be two ttl modules in
/lib/modules/2.4.18-4GB/kernel/net/ipv4/netfilter/.
ipt_TTL for the target
ipt_ttl for matching.

ipt_TTL isnt in the modules directory.

How am I going to get this to work?

Thanks,
Philipp

PS: 
System is Suse 8.0, Kernel 2.4.18, iptables 1.2.25