IPTABLES MASQUERADE - WAN is OK but no LAN traffic...

Here is the masquerade section of rules that I have set up...

iptables -t nat -A POSTROUTING -s 172.19.0.0/24 -j SNAT --to
66.119.9.186
iptables -A FORWARD -t filter -m state --state NEW,ESTABLISHED,RELATED
-j ACCEP
iptables -A FORWARD -t filter -m state --state ESTABLISHED,RELATED -j
ACCEPT


1. If I set an IP on the 66.119.9.0/24 network, Everything is OK.
2. When I set up IP: 172.19.0.2 SM: 255.255.255.0 GW:172.19.0.1 I can
get traffic out of the network just fine but can no longer access the
66.119.9.0/24 network.
3. I can ping google via it's IP and Yahoo via the IP but not my
servers on the 66.119.9.0/24.
4. I had to use a DNS server that was outside of my network in order to
resolve domains as my DNS is on the 66.119.9.0/24 network.

Can someone tell me what the heck I'm doing wrong?

On Mon, 28 Aug 2006 23:26:11 -0700, wisptech wrote:

> Here is the masquerade section of rules that I have set up...
>
> iptables -t nat -A POSTROUTING -s 172.19.0.0/24 -j SNAT --to
> 66.119.9.186

Well since you are using FORWARD I will assume (bad idea I know) that you
have more then one interface on this box.

Since POSTROUTING is done on all FORWARD'ed packets every packet no matter
where is started, when it exits the box it is being SNAT'ed to
66.119.9.186

eth0 -> PREROUTE -> FORWARD -> POSTROUTE -> eth1
eth0 <- POSTROUTE <- FORWARD <- PREROUTE <- eth1

The steps are simple;

Enter an interface
Do some PREROUTE rules
Route Packet (FORWARD)
Do some POSTROUTE rules
Exit other interface

You can fix this by using the '-o <interface>' option which is the
outbound interface. For example I will assume (I know) that eth0 is the
interface to the world. Your rules should then look like this

iptables -t nat -A POSTROUTING -o eth0 -s 172.19.0.0/24 -j SNAT --to 66.119.9.186

Then only packets that are exiting to the world will be SNATed and not
every packet that cross the box.

> iptables -A FORWARD -t filter -m state --state NEW,ESTABLISHED,RELATED
> -j ACCEP
> iptables -A FORWARD -t filter -m state --state ESTABLISHED,RELATED -j
> ACCEPT

Here again the first ACCEPT rule takes charge so the second does nothing.
If you want to allow only the NEW packets from your 172.19 network through
this box then you would have to change the first rule to;

iptables -A FORWARD -t filter -i eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

and you would change the second one to only allow related packets back
like this;

iptables -A FORWARD -t filter -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

> Can someone tell me what the heck I'm doing wrong?

That should get you started. If this BOX only has one interface then the
rules change again and you don't need FORWARD.

Take a look at this site. I think it might help you.

http://iptables-tutorial.frozentux.n...-tutorial.html


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Hello,

Robert a écrit :
> On Mon, 28 Aug 2006 23:26:11 -0700, wisptech wrote:
>
>>iptables -t nat -A POSTROUTING -s 172.19.0.0/24 -j SNAT --to
>>66.119.9.186
>
> Since POSTROUTING is done on all FORWARD'ed packets every packet no matter
> where is started,

This is not completely true, as most packets don't traverse the nat
chains. Only the first packet of a connexion does. The next ones are
implicitly processed by the NAT code.

> when it exits the box it is being SNAT'ed to 66.119.9.186

This is true only for packets in the original direction of the
connection, not for packets in the return direction.

>>Can someone tell me what the heck I'm doing wrong?

You didn't describe your network setup. So the reader doesn't know what
the 66.119.9.186 or 172.19.0.0/24 addresses mean. You didn't clearly say
what is your goal either.

Thanks for the replies... Let me be more clear about what I'm trying
to do

- eth0 - This is the WAN side of the router
IP: 66.119.30.246
GW: 66.119.30.245

- eth1 - This is on the LAN side of the router
IP: 66.119.9.1

- eth2 - This is also on the LAN side of the router
IP: 172.19.0.1

1. All interfaces are physical not virtual.
2. I want to give out both public and private IP addresses to machines
on the network via a DHCP server that is on another machine.
3. I want to have the 172.19.0.0/24 network able to access the
66.119.9.0/24 network for web servers, email, and DNS.
4. Right now the 66.119.9.0/24 is working 100%.
5. Right now the 172.19.0.0/24 is not communicating with the
66.119.9.0/24 network, no traffic, nothing.
6. The eth1 and eth2 interfaces are attached to the same switch.
7. 66.119.9.186 is the NAT/MASQ address that the 172.19.0.0/24 is
using.

(E-Mail Removed) a écrit :
> Thanks for the replies... Let me be more clear about what I'm trying
> to do

Thank you. Things are much clearer now.

> - eth0 - This is the WAN side of the router
> IP: 66.119.30.246
> GW: 66.119.30.245
>
> - eth1 - This is on the LAN side of the router
> IP: 66.119.9.1
>
> - eth2 - This is also on the LAN side of the router
> IP: 172.19.0.1

Are eth1 and eth2 on the same physical LAN or the same VLAN (which is a
bad idea IMHO), or are there on two separate (V)LANs ?

Thank you everyone who input... I got it working... Had some bad
rules in the firewall...

iptables -A FORWARD -i Ethernet0 -m limit --limit 10/s \
--limit-burst 10 -p icmp --icmp-type echo-request -j ACCEPT

iptables -A FORWARD -o Ethernet0 -m limit --limit 5/s \
--limit-burst 30 -p icmp --icmp-type echo-request -j ACCEPT

iptables -A FORWARD -p icmp -j DROP

As soon as I commented these out, everything started working. Anybody
know why these would cause the traffic to stop completely when they are
just supposed to limit icmp echo-requests?

On 30 Aug 2006 08:28:05 -0700, (E-Mail Removed) wrote:

>Thank you everyone who input... I got it working... Had some bad
>rules in the firewall...
>
> iptables -A FORWARD -i Ethernet0 -m limit --limit 10/s \
> --limit-burst 10 -p icmp --icmp-type echo-request -j ACCEPT
>
>iptables -A FORWARD -o Ethernet0 -m limit --limit 5/s \
> --limit-burst 30 -p icmp --icmp-type echo-request -j ACCEPT
>
>iptables -A FORWARD -p icmp -j DROP
>
>As soon as I commented these out, everything started working. Anybody
>know why these would cause the traffic to stop completely when they are
>just supposed to limit icmp echo-requests?

You don't drop or limit ICMPs -- they're a vital part of tcp/ip
networking. Also make sure the first rules for INPUT and FORWARD
are something like these:

MSTATE="--match state --state"
....
iptables -A INPUT -p all $MSTATE ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p all $MSTATE ESTABLISHED,RELATED -j ACCEPT

Apply rate limiting when starting NEW connections, not to the control
traffic, an example:

filter_traceroute_requests()
{
# traceroute
iptables -A INPUT -p udp --dport $TRPORT \
$MLIMIT 1/sec --limit-burst 10 \
-j $LOGGED "$PREFIX:inp:accept trace "
iptables -A INPUT -p udp --dport $TRPORT \
$MLIMIT 1/sec --limit-burst 10 -j ACCEPT
}

See also: <http://bugsplatter.mine.nu/junkview/iptables-save> for current
router firewall ruleset.

Grant.
--
http://bugsplatter.mine.nu/

Grant a écrit :
>
> You don't drop or limit ICMPs -- they're a vital part of tcp/ip
> networking.

Some ICMP are more vital than others. I personnally allow only a few
ICMP types from the internet or untrusted sources :

- type 0 (echo reply) in state ESTABLISHED
- type 3 (destination unreachable) in state RELATED
- type 8 (echo) in state NEW
- type 11 (time exceeded) in state RELATED

I consider the other ICMP types less useful or potentially harmful. I
used to allow type 4 (source quench) until I read some security
advisories involving it in DoS.
And I limit the rate of echo requests. There is no reason to send
hundreds of them per second.

Pascal Hambourg wrote:
> Grant a écrit :
>
>>
>> You don't drop or limit ICMPs -- they're a vital part of tcp/ip
>> networking.
>
>
> Some ICMP are more vital than others. I personnally allow only a few
> ICMP types from the internet or untrusted sources :
>
> - type 0 (echo reply) in state ESTABLISHED
> - type 3 (destination unreachable) in state RELATED
> - type 8 (echo) in state NEW
> - type 11 (time exceeded) in state RELATED
>
> I consider the other ICMP types less useful or potentially harmful. I
> used to allow type 4 (source quench) until I read some security
> advisories involving it in DoS.
> And I limit the rate of echo requests. There is no reason to send
> hundreds of them per second.

Please add type 4 (Fragmentation Needed but DF Set),
to enable TCP MSS detection to work properly.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio a écrit :
>>
>> Some ICMP are more vital than others. I personnally allow only a few
>> ICMP types from the internet or untrusted sources :
>>
>> - type 0 (echo reply) in state ESTABLISHED
>> - type 3 (destination unreachable) in state RELATED
>> - type 8 (echo) in state NEW
>> - type 11 (time exceeded) in state RELATED
[...]
> Please add type 4 (Fragmentation Needed but DF Set),
> to enable TCP MSS detection to work properly.

Fragmentation-needed is not ICMP type 4 (which is source-quench, as I
said earlier) but ICMP type 3 *code* 4. So it's already included in
destination-unreachable.