[Firewall] DMZ-IP

Lonnie Abelbeck lists at lonnie.abelbeck.com
Wed Jan 14 20:16:15 CET 2009


Arno,

Can you give a simple example how a plugin would handle the ordering  
in this case?

Given...
# Local box
HOST_OPEN_TCP="0/0~443"

# LAN host
NAT_FORWARD_TCP="25>192.168.1.5"

Then the plugin would...
Forward everything else to 192.168.1.2 instead of being dropped.

Thanks,

Lonnie


On Jan 14, 2009, at 12:50 PM, Arno van Amersfoort wrote:

> First of all: you can implement about *anything* with plugins. They  
> are loaded before *almost* everything in the main script. I even  
> implemented  these POST_xxx-chains for allow plugins to add stuff  
> *after* the main script has loaded its rules. If there isn't  
> something that can't be done with plugins, contact me and I'll take  
> care of it in the main script.
>
> About the DMZ-idea: it is indeed interesting. I see 2 possible  
> options:
> - Use the NAT_FORWARD_xxx variables, as already suggested, though  
> quick 'n dirty;
> - Write a plugin which nicely implements this.
>
> a.
>
> Lonnie Abelbeck wrote:
>> On Jan 14, 2009, at 11:48 AM, Darrick Hartman wrote:
>>> I'm trying to figure out a way to implement the following  
>>> 'feature'.  I don't think it's possible as a plugin because it  
>>> would likely need to be applied before many of the rules in the  
>>> main script.
>>>
>>> The feature follows:
>>>
>>> Many firewall 'appliances' allow a so-called DMZ where all  
>>> unassigned inbound traffic is directed to a specific IP address on  
>>> the lan.  I need to duplicate this behavior and hope we can find a  
>>> way to do this cleanly with the Arno's script.
>>>
>>> So as an example:
>>>
>>> TCP 80 -> NAT 192.168.1.1:80
>>> TCP 25 -> NAT 192.168.1.15:25
>>>
>>> ALL other inbound traffic -> NAT 192.168.1.2
>>>
>>> I suppose that NAT_TCP_FORWARD, NAT_UDP_FORWARD could be used with  
>>> some very wide ranges with the specified ports listed before the  
>>> wide range, but I was hoping for something cleaner that would  
>>> ensure that DMZ-IP forwards would happen at the right time without  
>>> having to ensure they were listed last in these other fields.
>>>
>>> Darrick
>> Interesting idea...
>> This would allow multiple firewalls to be easily placed back-to- 
>> back, the first firewall handles what it chooses and then forwards  
>> everything else to another firewall downstream.
>> Possibly Arno could add something like:
>> FORWARD_DENYED="192.168.1.2"
>> before his DENY's, to forward traffic to a particular IP address  
>> immediately before they would normally be blocked.
>> Lonnie
>> _______________________________________________
>> Firewall mailing list
>> Firewall at rocky.eld.leidenuniv.nl
>> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
>> Arno's (Linux IPTABLES Firewall) Homepage:
>> http://rocky.eld.leidenuniv.nl
>
> -- 
> Arno van Amersfoort
> E-mail    : arnova at rocky.eld.leidenuniv.nl
> Donations are welcome through Paypal!
> ---------------------------------------------------------------------------
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl
> _______________________________________________
> Firewall mailing list
> Firewall at rocky.eld.leidenuniv.nl
> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl
>
>



More information about the Firewall mailing list