DMZ to DMT through ROUTER problem !

-----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-----

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.

-----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
[...]

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-----

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.

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

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-----

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.

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

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-----

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.

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

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-----

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.

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

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$

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-----

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.

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.

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

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-----

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.

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

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-----