All of lore.kernel.org
 help / color / mirror / Atom feed
From: iptables-user <iptables@theorb.net>
To: netfilter@lists.netfilter.org
Subject: Re: some addresses won't route
Date: Mon, 19 Sep 2005 17:38:23 -0700	[thread overview]
Message-ID: <432F59FF.6010003@theorb.net> (raw)
In-Reply-To: <200509190912.51338.rob0@gmx.co.uk>

/dev/rob0 wrote:
> On Sunday 18 September 2005 17:08, iptables-user wrote:
> 
>>/dev/rob0 wrote:
>>
>>>>Box is setup as a router with a WAN, DMZ, and LAN.  WAN traffic
>>>>DNAT'd to DMZ works. DMZ and LAN through WAN works. The problems
>>>>show up in LAN to DMZ traffic.
>>>
>>>Incomplete description. Does the LAN and the DMZ have different
>>>netblocks? What IP addresses are being accessed by LAN clients? Are
>>>you doing the DNAT for those?
> 
> 
> This be talk-like-a-pirate day, lad, so we be keel-haulin' yer router! 
> Arrr! http://www.talklikeapirate.com/
> 
<snip />

Thanks /dev/rob0!!!  I laughed so hard I felt like *I* was full of grog. 
  (I'm part of a small circle of friends who talk like a pirate on a 
regular basis. P)

Sorry for the delay in following up.  My ship dropped me on a jungle 
isle replete with very hungry alligators.  Kept me busy all day :)

Everything now works without delay.  Apparently specifying the output 
interface in a FORWARD chain is not enough.  By modifying the rule to 
include -i AND -o things go where they're supposed to.  Everything now 
works again except LAN traffic to the one DMZ ip:http.

As for the one IP that just won't work for HTTP I think I have a .config 
file somewhere that is conflicting with the network's new identities. 
I've recycled my boxes a couple of times and think that therein lies the 
problem.  It's not that it's being DNAT'd incorrectly, I think it has an 
identity crisis.  The current DMZ IP used to be my client box's IP on a 
different network.  Now that I know it works I can do a clean install, 
copy over the iptables rules, and flesh out the iptables rule set.

And /dev/rob0, thanks again for your detailed help and especially for my 
laugh of the day!!!  (I owe you a good pirate joke)

Here is the working iptables rule set in iptables-save format (WAN IPs 
obfuscated, some comments):

##########  VERY BASIC 3-LEGGED FIREWALL/ROUTER  ###########
#
# [eth0] LAN is 192.168.0.1 /24 (private)
# [eth1] WAN is W.A.N.1-5   /29 (dsl to internet)
# NETWORK:W.A.N.0; IPADDR:W.A.N.1-5; GATEWAY:W.A.N.6; BROADCAST:W.A.N.7
# [eth2] DMZ is 10.0.0.1    /24 (servers)
#
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:WAN_1 - [:]
:WAN_2 - [:]
:WAN_3 - [:]
:WAN_4 - [:]
:WAN_5 - [:]
## break each WAN IP into its own chain
-A PREROUTING -d W.A.N.1 -j WAN_1
-A PREROUTING -d W.A.N.2 -j WAN_2
-A PREROUTING -d W.A.N.3 -j WAN_3
-A PREROUTING -d W.A.N.4 -j WAN_4
-A PREROUTING -d W.A.N.5 -j WAN_5
-A POSTROUTING -o eth1 -j SNAT --to-source W.A.N.5
## dns, pop3, smtp, lot's of different types of webservers
-A WAN_1 -p tcp --dport 25 -j DNAT --to-destination 10.0.0.11
-A WAN_1 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.11
-A WAN_1 -p udp --dport 53 -j DNAT --to-destination 10.0.0.11
-A WAN_1 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.11
-A WAN_2 -p tcp --dport 25 -j DNAT --to-destination 10.0.0.13
-A WAN_2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.13
-A WAN_2 -p tcp --dport 110 -j DNAT --to-destination 10.0.0.13
-A WAN_3 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.14
-A WAN_4 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.15
-A WAN_5 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.16
COMMIT

*filter
:INPUT   DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
## only LAN hosts can SSH to router
-A INPUT -s 192.168.0.0/255.255.255.0 -d 192.168.0.1 -p tcp -m tcp 
--dport 22 -j ACCEPT

## all devices can go thru DMZ
-A FORWARD -i eth0 -o eth2 -j ACCEPT
-A FORWARD -i eth1 -o eth2 -j ACCEPT
## all devices can go thru WAN
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A FORWARD -i eth2 -o eth1 -j ACCEPT
## LAN must expose AUTH for access to DMZ's SMTP server...
-A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 113 -j ACCEPT
## ...otherwise LAN access is restricted
-A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

I hope this can be a useful starting point for somebody else.

Thanks to all for your help,
San Jose Mike


  reply	other threads:[~2005-09-20  0:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-18 19:14 some addresses won't route iptables-user
2005-09-18 21:05 ` /dev/rob0
2005-09-18 21:39   ` wkc
2005-09-18 22:08   ` iptables-user
2005-09-19 14:12     ` /dev/rob0
2005-09-20  0:38       ` iptables-user [this message]
2005-09-20 14:06         ` /dev/rob0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=432F59FF.6010003@theorb.net \
    --to=iptables@theorb.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.