DMZ to DMT through ROUTER problem !

DMZ to DMT through ROUTER problem !

[O-Zone]

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

Hi all,
i've a big problem. Here's a little diagram:

[INTRANET 10.0.0.0/24]-------------+
                                                      +--[ROUTER]--(NET)
[DMZ SERVER A - 192.168.0.2]----+
[DMZ SERVER B - 192.168.0.3]----+

Each DMZ server is mapped to it's PUBLIC IP. For example:

151.8.47.A ----> 192.168.0.2
151.8.47.B ----> 192.168.0.3

and all work perfectly !!!

The problem is when, from 192.168.0.2, i try to connect to 151.08.47.B (trat's 
mapped to 192.168.0.3): packets die on ROUTER.

Here's my IPTABLES configuration:

[.....]
#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "1" > /proc/sys/net/ipv4/conf/all/accept_source_route

[....]
#
# 4.3.8 POSTROUTING chain
#

$IPTABLES -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE

# This is my TRY :-( but don't work...
$IPTABLES -t nat -A POSTROUTING -o $DMZ_IFACE -s 192.168.0.0/24 -d 151.8.47.A 
- -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o $DMZ_IFACE -s 192.168.0.0/24 -d 151.8.47.B 
- -j MASQUERADE

# Perhaps the same as the first
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

Someone can help me ?

Please ! Oz


- -- 
Legge di Eagleson:
	Qualsiasi tuo personale codice sorgente che non e' piu' stato
	guardato da sei o piu' mesi potrebbe benissimo essere stato
	scritto da qualcun altro.  (Eagleson e' un ottimista; il numero
	reale e' piu' vicino alle tre settimane.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArJQHYuBSFbgkEysRAsMqAKDYL9wufFI1uEVNubiBhsdlLVHs+gCgjwq3
JASN8hPUrFKObgR4MzAPZ0k=
=hVW2
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 12:18 pm, O-Zone wrote:

> i've a big problem. Here's a little diagram:
>
> [INTRANET 10.0.0.0/24]-------------+
>                                                       +--[ROUTER]--(NET)
> [DMZ SERVER A - 192.168.0.2]----+
> [DMZ SERVER B - 192.168.0.3]----+
>
> Each DMZ server is mapped to it's PUBLIC IP. For example:
>
> 151.8.47.A ----> 192.168.0.2
> 151.8.47.B ----> 192.168.0.3
>
> and all work perfectly !!!
>
> The problem is when, from 192.168.0.2, i try to connect to 151.08.47.B
> (trat's mapped to 192.168.0.3): packets die on ROUTER.

It's the reply packets which are the problem.

Think about a TCP connection:

1. SYN packet from 192.168.0.2 to 151.8.47.B goes to the firewall.
2. Firewall DNATs 151.8.47.B to 192.168.0.3
3. SYN packet goes from firewall to 192.168.0.3
4. 192.168.0.3 sends SYN-ACK to 192.168.0.2 on local net (not via firewall)
5. 192.168.0.2 wonders why it got a SYN-ACK from 192.168.0.3 when it sent the 
SYN to 151.8.47.B

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html

Regards,

Antony.

-- 
"The problem with television is that the people must sit and keep their eyes 
glued on a screen; the average American family hasn't time for it."

 - New York Times, following a demonstration at the 1939 World's Fair.

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

Thanks for reply,

On Thursday 20 May 2004 14:30, Antony Stone wrote:
[ SNIP ]
[INTRANET 10.0.0.0/24]-------------+
                                                      +--[ROUTER]--(NET)
[DMZ SERVER A - 192.168.0.2]----+
[DMZ SERVER B - 192.168.0.3]----+

Each DMZ server is mapped to it's PUBLIC IP. For example:

151.8.47.A ----> 192.168.0.2
151.8.47.B ----> 192.168.0.3
[...]
> It's the reply packets which are the problem.
>
> http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html

i've read that manual but i't not so clear. It say to do a:

# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
        -p tcp --dport 80 -j SNAT --to 192.168.1.250

but  can't understand what it say for 192.168.1.250. As in my config, i've 
write down that rule:

$IPTABLES -t nat -A POSTROUTING -d 151.8.47.B -s 192.168.0.0/24 -p tcp -j SNAT 
- --to 192.168.0.1

...where 192.168.0.1 is the DMZ interface of ROUTER. It don't work. Where's 
the error ?

Thanks. Oz



- -- 
Children are natural mimics who act like their parents despite every
effort to teach them good manners.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArKqVYuBSFbgkEysRAr5UAJ9BYkyVJ7UP659V1E46GhbWcADehwCgsKj4
2NJvOiTcojDX9CPzQPSG0Nc=
=Jx70
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 1:54 pm, O-Zone wrote:

> On Thursday 20 May 2004 14:30, Antony Stone wrote:
>
> > It's the reply packets which are the problem.
> >
> > http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html
>
> i've read that manual but i't not so clear. It say to do a:
>
> # iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
>         -p tcp --dport 80 -j SNAT --to 192.168.1.250
>
> but  can't understand what it say for 192.168.1.250. As in my config, i've
> write down that rule:
>
> $IPTABLES -t nat -A POSTROUTING -d 151.8.47.B -s 192.168.0.0/24 -p tcp -j
> SNAT - --to 192.168.0.1
>
> ...where 192.168.0.1 is the DMZ interface of ROUTER. It don't work. Where's
> the error ?

You need to make sure that the reply packets go back through the firewall, as 
well as the forward packets.   The easiest way to do this is by adding a SNAT 
rule so that as far as the destination server is concerned, the packets came 
from the firewall, not the real client, and therefore the server sends the 
replies back to the firewall (which then reverse-NATs them and returns the 
replies to the original client machine).

Therefore in your case something such as:

iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d 192.168.0.0/24 -j SNAT 
--to 192.168.0.1

should do the trick.

The above rule matches packets coming from an internal client (-s 
192.168.0.0/24) and going to an internal server (-d 192.168.0.0/24), and 
forces the source address to be that of the firewall (192.168.0.1) so the 
replies go back by the same route.

Regards,

Antony.

-- 
The difference between theory and practice is that in theory there is no 
difference, whereas in practice there is.

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Thursday 20 May 2004 15:22, Antony Stone wrote:
> You need to make sure that the reply packets go back through the firewall,
> as well as the forward packets.   The easiest way to do this is by adding a
> SNAT rule so that as far as the destination server is concerned, the
> packets came from the firewall, not the real client, and therefore the
> server sends the replies back to the firewall (which then reverse-NATs them
> and returns the replies to the original client machine).
>
> Therefore in your case something such as:
>
> iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d 192.168.0.0/24 -j SNAT
> --to 192.168.0.1

But, i think, i need to add other rules because the original connection came 
from 192.168.0.x to 151.8.47.x, right ?

Let me know. Thanks a lot !

Oz


- -- 
A new supply of round tuits has arrived and are available from Mary.
Anyone who has been putting off work until they got a round tuit now
has no excuse for further procrastination.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArMLAYuBSFbgkEysRAtYHAJ9dGGKWf4KK3LgTVbe7dnPcWvS6ggCcDKy9
/bErxaNGbSQzlE/sS0HpRmo=
=+z9F
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 3:37 pm, O-Zone wrote:

> On Thursday 20 May 2004 15:22, Antony Stone wrote:
> > You need to make sure that the reply packets go back through the
> > firewall, as well as the forward packets.   The easiest way to do this is
> > by adding a SNAT rule so that as far as the destination server is
> > concerned, the packets came from the firewall, not the real client, and
> > therefore the server sends the replies back to the firewall (which then
> > reverse-NATs them and returns the replies to the original client
> > machine).
> >
> > Therefore in your case something such as:
> >
> > iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d 192.168.0.0/24 -j
> > SNAT --to 192.168.0.1
>
> But, i think, i need to add other rules because the original connection
> came from 192.168.0.x to 151.8.47.x, right ?

Yes, but that destination address has already been changed by your PREROUTING 
rule, and is now 192.168.0.0/24 - that's the whole point.   If the 
destination address had not been changed (ie: if the client had contacted the 
server's real IP address instead of a pretend one), you wouldn't need to 
change the source address as well.

If you think you need other rules, please explain what they would be and why 
they are needed - it's entirely possible I have missed something about your 
setup.

Regards,

Antony.

-- 
The truth is rarely pure, and never simple.

 - Oscar Wilde

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Thursday 20 May 2004 16:45, Antony Stone wrote:
> Yes, but that destination address has already been changed by your
> PREROUTING rule, and is now 192.168.0.0/24 - that's the whole point.   If
> the destination address had not been changed (ie: if the client had
> contacted the server's real IP address instead of a pretend one), you
> wouldn't need to change the source address as well.

As you say, the problem was when a server with 192.168.0.x, passing through 
192.168.0.1 (that is the ROUTER), and try to connect to 151.8.47.x (the real 
server's PUBLIC IP). This is the desidered flow:

192.168.0.2-->151.8.47.A-->192.168.0.3

So i think that i need additiona rules to MASQ/DNAT connection to 151.8.47.x !

Oz

- -- 
There is a theory which states that if ever anyone discovers exactly what
the Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.  There is another
theory which states that this has already happened.
		-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArMexYuBSFbgkEysRAgoOAKCxjUX/lXCX30GUUaCkQTSHaklXXQCdHS6A
faOLbQvIfdm6e7coMhWm/9w=
=ddMI
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 3:58 pm, O-Zone wrote:

> On Thursday 20 May 2004 16:45, Antony Stone wrote:
> > Yes, but that destination address has already been changed by your
> > PREROUTING rule, and is now 192.168.0.0/24 - that's the whole point.   If
> > the destination address had not been changed (ie: if the client had
> > contacted the server's real IP address instead of a pretend one), you
> > wouldn't need to change the source address as well.
>
> As you say, the problem was when a server with 192.168.0.x, passing through
> 192.168.0.1 (that is the ROUTER), and try to connect to 151.8.47.x (the
> real server's PUBLIC IP). This is the desidered flow:
>
> 192.168.0.2-->151.8.47.A-->192.168.0.3
>
> So i think that i need additiona rules to MASQ/DNAT connection to
> 151.8.47.x !

Well, yes, but this PREROUTING DNAT rule is needed for connections from the 
outside, which you say are working fine already?

I quote from your original posting:

 - Hi all,
 - i've a big problem. Here's a little diagram:
 - 
 - [INTRANET 10.0.0.0/24]-------------+
 -                                                       +--[ROUTER]--(NET)
 - [DMZ SERVER A - 192.168.0.2]----+
 - [DMZ SERVER B - 192.168.0.3]----+
 - 
 - Each DMZ server is mapped to it's PUBLIC IP. For example:
 - 
 - 151.8.47.A ----> 192.168.0.2
 - 151.8.47.B ----> 192.168.0.3
 - 
 - and all work perfectly !!!"

If you do not in fact already have the PREROUTING DNAT rules, then what do you 
mean by "Each DMZ server is mapped to its PUBLIC IP"?   Maybe I misunderstood 
what you have already done, and already have working, and what problem is 
still left to solve?

Regards,

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Thursday 20 May 2004 17:07, Antony Stone wrote:
> If you do not in fact already have the PREROUTING DNAT rules, then what do
> you mean by "Each DMZ server is mapped to its PUBLIC IP"?   Maybe I
> misunderstood what you have already done, and already have working, and
> what problem is still left to solve?

Here's the problem (TCPDUMP on 192.168.0.1):
root@bastion:/etc/rc.d# tcpdump -i eth2 dst 151.8.47.B
17:45:52.507152 IP 192.168.0.2.45621 > 151.8.47.B.pop3: S 
1931786477:1931786477(0) win 5840 <mss 1460,sackOK,timestamp 107802174[|tcp]>
17:45:55.506855 IP 192.168.0.2.45621 > 151.8.47.B.pop3: S 
1931786477:1931786477(0) win 5840 <mss 1460,sackOK,timestamp 107805174[|tcp]>
17:46:01.506454 IP 192.168.0.2.45621 > 151.8.47.B.pop3: S 
1931786477:1931786477(0) win 5840 <mss 1460,sackOK,timestamp 107811174[|tcp]>

but on 151.8.47.B (192.168.0.3) no any packet arrive. This is a piece of 
rc.firewall:

#
# 4.3.8 POSTROUTING chain
#

$IPTABLES -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -s 172.16.0.0/24 -j MASQUERADE

$IPTABLES -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp -j 
SNAT --to 192.168.0.1

$IPTABLES -t nat -A POSTROUTING -s $DMZ_SIENA_IP -o $INET_IFACE -j SNAT 
- --to-source $SIENA_IP
$IPTABLES -t nat -A POSTROUTING -s $DMZ_DOMINI_IP -o $INET_IFACE -j SNAT 
- --to-source $DOMINI_IP
$IPTABLES -t nat -A POSTROUTING -s $DMZ_EXCHANGE_IP -o $INET_IFACE -j SNAT 
- --to-source $EXCHANGE_IP
$IPTABLES -t nat -A POSTROUTING -s $DMZ_ELEKTRA_IP -o $INET_IFACE -j SNAT 
- --to-source $ELEKTRA_IP
$IPTABLES -t nat -A POSTROUTING -s $DMZ_LEONARDO_IP -o $INET_IFACE -j SNAT 
- --to-source $LEONARDO_IP
$IPTABLES -t nat -A POSTROUTING -s $DMZ_PROXYSAT_IP -o $INET_IFACE -j SNAT 
- --to-source $PROXYSAT_IP

The problem is still here :-(

- -- 
What is algebra, exactly?  Is it one of those three-cornered things?
		-- J.M. Barrie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArNSCYuBSFbgkEysRApQsAKCACoGu7IIxbBGI8r5BOOPwQAUzMgCeI/g0
ODxv+ha7hSWSLOr1RdU2g7o=
=kqyU
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 4:53 pm, O-Zone wrote:

> On Thursday 20 May 2004 17:07, Antony Stone wrote:
> > If you do not in fact already have the PREROUTING DNAT rules, then what
> > do you mean by "Each DMZ server is mapped to its PUBLIC IP"?   Maybe I
> > misunderstood what you have already done, and already have working, and
> > what problem is still left to solve?
>
> Here's the problem (TCPDUMP on 192.168.0.1):
> root@bastion:/etc/rc.d# tcpdump -i eth2 dst 151.8.47.B
> 17:45:52.507152 IP 192.168.0.2.45621 > 151.8.47.B.pop3: S
> 1931786477:1931786477(0) win 5840 <mss 1460,sackOK,timestamp
>
> but on 151.8.47.B (192.168.0.3) no any packet arrive. This is a piece of
> rc.firewall:

What about the rest of rc.firewall?   You have posted your POSTROUTING SNAT 
rules - do you have any PREROUTING DNAT rules to convert 151.8.47.B into 
192.168.0.3?

If you do not have any PREROUTING rules, I remain confused about how this was 
already working from the Internet as you said previously, but try:

iptables -A PREROUTING -t nat -p tcp --dport 110 -d 151.8.47.B -j DNAT --to 
192.168.0.3

Regards,

Antony.

-- 
There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Thursday 20 May 2004 18:07, Antony Stone wrote:
> What about the rest of rc.firewall?   You have posted your POSTROUTING SNAT
> rules - do you have any PREROUTING DNAT rules to convert 151.8.47.B into
> 192.168.0.3?

Yes ! Here is (for SIENA only):

$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_SIENA_IP -m 
multiport --dports 25,53,110 -j allowed
$IPTABLES -A FORWARD -p UDP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_SIENA_IP -m 
multiport --dports 53 -j allowed

$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_SIENA_IP -j 
icmp_packets

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $SIENA_IP -m multiport 
- --dports 25,53,80,110 -j DNAT --to-destinati$
$IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $SIENA_IP -m multiport 
- --dports 53 -j DNAT --to-destination $DMZ_SI$


> If you do not have any PREROUTING rules, I remain confused about how this
> was already working from the Internet as you said previously, but try:
>
> iptables -A PREROUTING -t nat -p tcp --dport 110 -d 151.8.47.B -j DNAT --to
> 192.168.0.3

Don't work :-(

- -- 
"If a camel flies, no one laughs if it doesn't get very far."
		-- Paul White
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArN2YYuBSFbgkEysRAmcFAKCW2V0kRalMNbuwZmq42Gy+u7p08gCffD7w
KAM4uDcf9QHjbXn5U/QRQN4=
=exTi
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 5:32 pm, O-Zone wrote:

> On Thursday 20 May 2004 18:07, Antony Stone wrote:
> > What about the rest of rc.firewall?   You have posted your POSTROUTING
> > SNAT rules - do you have any PREROUTING DNAT rules to convert 151.8.47.B
> > into 192.168.0.3?
>
> Yes ! Here is (for SIENA only):
>
> $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $SIENA_IP -m
> multiport - --dports 25,53,80,110 -j DNAT --to-destinati$
> $IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $SIENA_IP -m
> multiport - --dports 53 -j DNAT --to-destination $DMZ_SI$

Your PREROUTING DNAT rules specify the input interface (-i $INET_IFACE), 
therefore they do not apply to packets arriving on any other interface.

Change this, either by removing the -i option altogether, or by adding extra 
rules to apply to the other interrface/s on your firewall from which you want 
to allow packets to be DNATted, and things should work.

Regards,

Antony.

-- 
If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.

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

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Thursday 20 May 2004 6:34 pm, Antony Stone wrote:

> On Thursday 20 May 2004 5:32 pm, O-Zone wrote:
> >
> > $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $SIENA_IP -m
> > multiport - --dports 25,53,80,110 -j DNAT --to-destinati$
> > $IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $SIENA_IP -m
> > multiport - --dports 53 -j DNAT --to-destination $DMZ_SI$
>
> Your PREROUTING DNAT rules specify the input interface (-i $INET_IFACE),
> therefore they do not apply to packets arriving on any other interface.

The same applies to your FORWARDing rules as well, by the way, so these will 
need changing before the packets can get through your firewall to their 
destination.

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Thursday 20 May 2004 19:44, Antony Stone wrote:
> The same applies to your FORWARDing rules as well, by the way, so these
> will need changing before the packets can get through your firewall to
> their destination.

OK ! Thanks a lot...now all works perfeclty. But i still have a problem with 
UDP. My DNS server inside DMZ, 192.168.0.2 ($DMZ_SIENA_IP), is mapped to two 
public ip:

151.8.47.A ($SIENA_IP)
81.113.95.B ($SIENA2_IP)

and the rules to allow UDP to this server from those IP are:

$IPTABLES -A FORWARD -p TCP -o $DMZ_IFACE -d $DMZ_SIENA_IP -m multiport 
- --dports 25,53,110 -j allowed
$IPTABLES -A FORWARD -p UDP -o $DMZ_IFACE -d $DMZ_SIENA_IP -m multiport 
- --dports 53 -j ACCEPT

$IPTABLES -A FORWARD -p ICMP -o $DMZ_IFACE -d $DMZ_SIENA_IP -j icmp_packets

$IPTABLES -t nat -A PREROUTING -p TCP -d $SIENA_IP -m multiport --dports 
25,53,80,110 -j DNAT --to-destination $DMZ_SIENA_IP
$IPTABLES -t nat -A PREROUTING -p UDP -d $SIENA_IP -m multiport --dports 53 -j 
DNAT --to-destination $DMZ_SIENA_IP

$IPTABLES -t nat -A PREROUTING -p TCP -d $SIENA2_IP -m multiport --dports 
25,53,80,110 -j DNAT --to-destination $DMZ_SIENA_$
$IPTABLES -t nat -A PREROUTING -p UDP -d $SIENA2_IP -m multiport --dports 53 
- -j DNAT --to-destination $DMZ_SIENA_IP

With the $SIENA_IP all work. With $SIENA2_IP not :-(. Is possible that the UDP 
reply packet source is wrong because:

...
$IPTABLES -t nat -A POSTROUTING -s $DMZ_SIENA_IP -o $INET_IFACE -j SNAT 
- --to-source $SIENA_IP
...

? 

Oz


- -- 
What we wish, that we readily believe.
		-- Demosthenes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArcwqYuBSFbgkEysRAmcOAJ9cZZgIyBMqGg9e2kFMzgVc2j1gtgCfZl8e
CwVcZex0I1X51bAUYx3FKJk=
=Rgex
-----END PGP SIGNATURE-----

Re: DMZ to DMT through ROUTER problem !

[Antony Stone]

On Friday 21 May 2004 10:30 am, O-Zone wrote:

> On Thursday 20 May 2004 19:44, Antony Stone wrote:
> > The same applies to your FORWARDing rules as well, by the way, so these
> > will need changing before the packets can get through your firewall to
> > their destination.
>
> OK ! Thanks a lot...now all works perfeclty. But i still have a problem
> with UDP. My DNS server inside DMZ, 192.168.0.2 ($DMZ_SIENA_IP), is mapped
> to two public ip:
>
> 151.8.47.A ($SIENA_IP)
> 81.113.95.B ($SIENA2_IP)

How do you route reply packets from those two public IPs back to the sender?

Netfilter will correctly apply reverse nat rules to reply packets which are in 
response to original packets matching nat rules in your ruleset - therefore 
if you map both the above public IPs to a single DMZ private IP, reply 
packets will be correctly reverse natted to have the appropriate public 
source IP.   However, you may need to make sure that packets with one source 
IP go via one ISP and those with the other source IP go via the other ISP 
(I'm assuming here that you have two entirely different public IPs because 
you have Internet connections from two ISPs?), as both ISPs may drop packets 
which have source addresses outside the range they have allocated to you (or 
which have been allocated to the ISP).

If you haven't already looked into iproute2 at http://lartc.org now would be a 
good time to find out about it.

Regards,

Antony.

-- 
Late in 1972 President Richard Nixon announced that the rate of increase of 
inflation was decreasing.   This was the first time a sitting president used 
a third derivative to advance his case for re-election.

 - Hugo Rossi, Notices of the American Mathematical Society

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

Re: DMZ to DMT through ROUTER problem !

[O-Zone]

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

On Friday 21 May 2004 12:19, Antony Stone wrote:
> How do you route reply packets from those two public IPs back to the
> sender?

Ok problem with UDP solved...again many many thanks ! But a little problem 
still remain with IPSEC.

On Firewall we have OpenSwan to connect from remote places. Inside our 
INTRANET, however some of us use IPSEC clients, such SSH Sentinel or SafeNet 
LT, to connect to remote IPSEC (using NAT-T Encapsulation). 

What happens when an intranet's user (10.0.0.40) try to connect to remote 
IPSEC server (81.113.x.y) ?

10.0.0.40 -----> [MASQ - 10.0.0.1] ----> 81.113.x.y
10.0.0.40 <-xx- [MASQ - 10.0.0.1] <--- 81.113.x.y

the reply to IPSEC packet was NOT forwarded and take by OpenSwan on 10.0.0.1 
with, of course, "who are you and why the f&%k calling me ?".

To enable firewall (10.0.0.1) accepting IPSEC connection i've used the 
following rules:

# IPSEC
$IPTABLES -A INPUT -i $INET_IFACE -p udp --dport 500 -j ACCEPT
$IPTABLES -A INPUT -i $INET_IFACE -p 50 -j ACCEPT
$IPTABLES -A INPUT -i $INET_IFACE -p 51 -j ACCEPT

How i can keep working correctly MASQ ?

Oz

- -- 
I always had a repulsive need to be something more than human.
		-- David Bowie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArg1oYuBSFbgkEysRAn8EAKDftszKctvX4gDK8G98HEDqllCvxgCguUy6
sZQ3BxQzAEucvi8yXa0XAbE=
=cPye
-----END PGP SIGNATURE-----