# Filter the Output of a NAT?

## Mageta

Hej folks,

I'm currently facing a somewhat low data-volume-restriction and thus I want to minimize the outgoing traffic to the only necessary ones (http, ssh, ..), so that a window-box for example can't open other connections than that (I know, many thing are done over http these days.. but I think, filtering http would be somewhat complex and only good with black-lists and not white-lists). How can I tell iptables to apply my output-rules on forwarded/masquerade packages?

I'm currently using this script to setup the tables:

```
#!/bin/bash

echo 0 > /proc/sys/net/ipv4/ip_forward

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $f ; done

#flushing the tables

iptables -F

iptables -t nat -F

#setting up the default polices

iptables -P INPUT ACCEPT

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

#variables

export LAN="br0"

export WAN="wwan0"

iptables -I INPUT 1 -i ${LAN} -j ACCEPT

iptables -I INPUT 1 -i lo -j ACCEPT

iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

iptables -A INPUT -p TCP --dport ftp -i ${WAN} -j ACCEPT

iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:1023 -j REJECT --reject-with tcp-reset

iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:1023 -j REJECT

iptables -I OUTPUT 1 -o ${LAN} -j ACCEPT

iptables -I OUTPUT 1 -o lo -j ACCEPT

iptables -A OUTPUT -p ICMP -o ${WAN} -j ACCEPT

PORTS="53 ssh ftp http https rsync 3000"

for i in ${PORTS}; do

        iptables -A OUTPUT -p TCP --dport ${i} -o ${WAN} -j ACCEPT

        iptables -A OUTPUT -p UDP --dport ${i} -o ${WAN} -j ACCEPT

done

#NAT

iptables -I FORWARD -i ${LAN} -d 192.168.1.0/24 -j DROP

iptables -A FORWARD -i ${LAN} -s 192.168.1.0/24 -j ACCEPT

iptables -A FORWARD -i ${WAN} -d 192.168.1.0/24 -j ACCEPT

iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

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

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
```

But this works only for the router itself, all other PC's in this LAN are not restricted by the output-rules (pkts-counters do not increase if, for example a http-connection is done by a other PC). What do I have to do, to filter also the other PC's in this LAN?

best regards,

- Ben

----------

## Hu

 *Mageta wrote:*   

> How can I tell iptables to apply my output-rules on forwarded/masquerade packages?

 

Packets destined for the local machine traverse INPUT.  Packets originating from the local machine traverse OUTPUT.  Packets crossing the local machine, but neither locally generated nor locally received, traverse FORWARD.

 *Mageta wrote:*   

> 
> 
> ```
> for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $f ; done
> ```
> ...

 

Nothing in the script changes routing rules, so there is no reason to disable rp_filter, even temporarily.

 *Mageta wrote:*   

> 
> 
> ```
> iptables -P INPUT ACCEPT
> ```
> ...

 Why?

 *Mageta wrote:*   

> 
> 
> ```
> iptables -A INPUT -p TCP --dport ftp -i ${WAN} -j ACCEPT
> ```
> ...

 It looks like you allow ftp, but not ftp-data.  This requires clients to use active mode FTP.  Additionally, ftp can consume bandwidth without much user interaction, so allowing it could be bad if you are concerned about your bandwidth allowance.

 *Mageta wrote:*   

> 
> 
> ```
> iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:1023 -j REJECT --reject-with tcp-reset
> 
> ...

 Why use this instead of -j DROP?

 *Mageta wrote:*   

> 
> 
> ```
> 
> PORTS="53 ssh ftp http https rsync 3000"
> ...

 This results in some silly rules.  For example, http is never done over UDP, but you create a rule to allow it.

 *Mageta wrote:*   

> 
> 
> ```
> iptables -A FORWARD -i ${WAN} -d 192.168.1.0/24 -j ACCEPT
> ```
> ...

 Did you intend to omit connection tracking here?

Overall, nothing here looks dynamic, so why not manage the whole thing through the Gentoo iptables service?

----------

## Mageta

 *Hu wrote:*   

>  *Mageta wrote:*   How can I tell iptables to apply my output-rules on forwarded/masquerade packages? 
> 
> Packets destined for the local machine traverse INPUT.  Packets originating from the local machine traverse OUTPUT.  Packets crossing the local machine, but neither locally generated nor locally received, traverse FORWARD.

 

Ah ok, so I have to do my output-filters also for the forward-chain.

 *Hu wrote:*   

>  *Mageta wrote:*   
> 
> ```
> for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $f ; done
> ```
> ...

 

ok

 *Hu wrote:*   

>  *Mageta wrote:*   
> 
> ```
> iptables -P INPUT ACCEPT
> ```
> ...

 

laziness

 *Hu wrote:*   

>  *Mageta wrote:*   
> 
> ```
> iptables -A INPUT -p TCP --dport ftp -i ${WAN} -j ACCEPT
> ```
> ...

 

I think it's much nicer to know right away that something is not working instead of being forced to wait until some sort of timeout.

 *Hu wrote:*   

>  *Mageta wrote:*   
> 
> ```
> 
> PORTS="53 ssh ftp http https rsync 3000"
> ...

 

You are absolutely right. Again some sort if laziness.   :Embarassed: 

 *Hu wrote:*   

>  *Mageta wrote:*   
> 
> ```
> iptables -A FORWARD -i ${WAN} -d 192.168.1.0/24 -j ACCEPT
> ```
> ...

 

Isn't this necessary to accept input that once originated from inside my LAN and was "nat'ed" into the WAN?

 *Hu wrote:*   

> Overall, nothing here looks dynamic, so why not manage the whole thing through the Gentoo iptables service?

 

You mean, I should write the script into a conf.d-file or what to you mean with "Gentoo iptables service"?

----------

## Hu

 *Mageta wrote:*   

>  *Hu wrote:*    *Mageta wrote:*   
> 
> ```
> iptables -P INPUT ACCEPT
> ```
> ...

 If you do it this way, then you have a blacklist-based firewall instead of a whitelist-based firewall.  Generally, when securing resources, whitelists are a better choice because they fail secure.

 *Mageta wrote:*   

> I think it's much nicer to know right away that something is not working instead of being forced to wait until some sort of timeout.

 This only benefits external users trying to access your services.

 *Mageta wrote:*   

>  *Hu wrote:*   Did you intend to omit connection tracking here? 
> 
> Isn't this necessary to accept input that once originated from inside my LAN and was "nat'ed" into the WAN?

 By using connection tracking, you can allow traffic that was initiated internally, without the need to allow all unsolicited traffic.

 *Mageta wrote:*   

>  *Hu wrote:*   Overall, nothing here looks dynamic, so why not manage the whole thing through the Gentoo iptables service? 
> 
> You mean, I should write the script into a conf.d-file or what to you mean with "Gentoo iptables service"?

 I mean the init.d service provided by /etc/init.d/iptables.

----------

