All of lore.kernel.org
 help / color / mirror / Atom feed
* Natting IPs hanging
@ 2005-05-13 20:04 Brian Atkins
  2005-05-14 15:26 ` Jason Opperisano
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Atkins @ 2005-05-13 20:04 UTC (permalink / raw)
  To: netfilter

Greetings:

I'm in the process of building my first dedicated firewall using 
iptables/netfilter (v 1.2.11) on Gentoo Linux (2.6.11 kernel).  I want 
to enable the natting of IPs, but I am having trouble getting the rules 
to take.  Essentially, I would like to take a specific group of IPs 
(servers) and nat them specifically to an internal ip address.  The 
remainder of the internal IPs (workstations - dhcp) should be natted 
outbound within a range of IPs.

Based on the docs on Netfilter.org and the man pages, I decided to start 
off with the following:

iptables -t nat -A PREROUTING -i eth0 -d 141.xxx.xxx.xxx -j DNAT 
--to-destination 10.xxx.xxx.xxx

But, when I try to run the command, it just hangs. After a while, I can 
break out of it with CTL-C.

What gives?  Am I missing something?

-- 
Brian



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-13 20:04 Brian Atkins
@ 2005-05-14 15:26 ` Jason Opperisano
  2005-05-16 15:40   ` Brian Atkins
  0 siblings, 1 reply; 9+ messages in thread
From: Jason Opperisano @ 2005-05-14 15:26 UTC (permalink / raw)
  To: netfilter

On Fri, May 13, 2005 at 01:04:31PM -0700, Brian Atkins wrote:
> Greetings:
> 
> I'm in the process of building my first dedicated firewall using 
> iptables/netfilter (v 1.2.11) on Gentoo Linux (2.6.11 kernel).  I want 
> to enable the natting of IPs, but I am having trouble getting the rules 
> to take.  Essentially, I would like to take a specific group of IPs 
> (servers) and nat them specifically to an internal ip address.  The 
> remainder of the internal IPs (workstations - dhcp) should be natted 
> outbound within a range of IPs.
> 
> Based on the docs on Netfilter.org and the man pages, I decided to start 
> off with the following:
> 
> iptables -t nat -A PREROUTING -i eth0 -d 141.xxx.xxx.xxx -j DNAT 
> --to-destination 10.xxx.xxx.xxx
> 
> But, when I try to run the command, it just hangs. After a while, I can 
> break out of it with CTL-C.
> 
> What gives?  Am I missing something?

the syntax of that rule looks fine to me.  i'm going to go out on a limb
and say there is something rotten in your kernel config.

out of curiosity, how did you compile the kernel for this machine, by
hand, or by using genkernel?

also, what does:

  $ cat /proc/net/ip_tables_names
and
  $ cat /proc/net/ip_tables_targets

have to say?

-j

--
"Tom Tucker: Now let's go to Greg The Weather Mime. OK... it's going
 to be cold...lots of wind... and it looks like parents are going to
 throw human fecal matter from the rooftops onto their children... oh,
 GOD. That's awful. No wait, it looks like rain. Yes, rain."
        --Family Guy


^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-14 15:26 ` Jason Opperisano
@ 2005-05-16 15:40   ` Brian Atkins
  2005-05-16 17:18     ` John Mok
  2005-05-16 21:53     ` Jason Opperisano
  0 siblings, 2 replies; 9+ messages in thread
From: Brian Atkins @ 2005-05-16 15:40 UTC (permalink / raw)
  To: Jason Opperisano; +Cc: netfilter

Jason,

Sorry for the delay in response.  Catting either of those files doesn't 
return much.  The ip_tables_names only returns: "filter"; 
ip_tables_targets is null. 

I did use genkernel to build the new kernel. I did have multiple issues 
with the kernel config initially, but mostly related to disk drivers. I 
can forward my .config if that might be helpful. 

I should say that other than trying to load the NATs, everything else is 
working fine.  Here is the small config that I am currently running 
(don't worry, this isn't production, yet):

# Generated by iptables-save v1.2.11 on Mon May 16 13:42:26 2005
*filter
:INPUT ACCEPT [89274:15206611]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9009:1656730]
-A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p icmp -j ACCEPT
-A INPUT -s xxx.xxx.xxx.64/255.255.255.192 -p icmp -j ACCEPT
-A INPUT -s xxx.xxx.xxx.65 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -j DROP
-A INPUT -p udp -j DROP
-A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 5666 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 1999 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 4899 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 5666 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 8080 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.62 -p tcp -m tcp --dport 4899 -j ACCEPT
-A FORWARD -d xxx.xxx.xxx.63 -p tcp -m tcp --dport 5666 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -p icmp -j DROP
-A OUTPUT -p tcp -j DROP
-A OUTPUT -p udp -j DROP
COMMIT
# Completed on Mon May 16 13:42:26 2005


Jason Opperisano wrote:

>On Fri, May 13, 2005 at 01:04:31PM -0700, Brian Atkins wrote:
>  
>
>>Greetings:
>>
>>I'm in the process of building my first dedicated firewall using 
>>iptables/netfilter (v 1.2.11) on Gentoo Linux (2.6.11 kernel).  I want 
>>to enable the natting of IPs, but I am having trouble getting the rules 
>>to take.  Essentially, I would like to take a specific group of IPs 
>>(servers) and nat them specifically to an internal ip address.  The 
>>remainder of the internal IPs (workstations - dhcp) should be natted 
>>outbound within a range of IPs.
>>
>>Based on the docs on Netfilter.org and the man pages, I decided to start 
>>off with the following:
>>
>>iptables -t nat -A PREROUTING -i eth0 -d 141.xxx.xxx.xxx -j DNAT 
>>--to-destination 10.xxx.xxx.xxx
>>
>>But, when I try to run the command, it just hangs. After a while, I can 
>>break out of it with CTL-C.
>>
>>What gives?  Am I missing something?
>>    
>>
>
>the syntax of that rule looks fine to me.  i'm going to go out on a limb
>and say there is something rotten in your kernel config.
>
>out of curiosity, how did you compile the kernel for this machine, by
>hand, or by using genkernel?
>
>also, what does:
>
>  $ cat /proc/net/ip_tables_names
>and
>  $ cat /proc/net/ip_tables_targets
>
>have to say?
>
>-j
>
>--
>"Tom Tucker: Now let's go to Greg The Weather Mime. OK... it's going
> to be cold...lots of wind... and it looks like parents are going to
> throw human fecal matter from the rooftops onto their children... oh,
> GOD. That's awful. No wait, it looks like rain. Yes, rain."
>        --Family Guy
>
>  
>

-- 
Brian Atkins
Systems Administrator
The Library Corporation
Research Park * Inwood, WV 25428-9733
Ph: (800) 325-7759 or (304) 229-0100
Fx: (304) 229-0295
http://TLCdelivers.com



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-16 15:40   ` Brian Atkins
@ 2005-05-16 17:18     ` John Mok
  2005-05-16 21:53     ` Jason Opperisano
  1 sibling, 0 replies; 9+ messages in thread
From: John Mok @ 2005-05-16 17:18 UTC (permalink / raw)
  To: Brian Atkins; +Cc: netfilter

Dear Brian,

How the routing is setup? Did you try to log the entries before the DROP 
rule? Since it is a PREROUTING NAT, the packet will be NATed before 
traversing in the INPUT, FORWARD or OUTPUT chains. You may proceed 
trouble-shooting in that direction.

John Mok


Brian Atkins wrote:

> Jason,
>
> Sorry for the delay in response.  Catting either of those files 
> doesn't return much.  The ip_tables_names only returns: "filter"; 
> ip_tables_targets is null.
> I did use genkernel to build the new kernel. I did have multiple 
> issues with the kernel config initially, but mostly related to disk 
> drivers. I can forward my .config if that might be helpful.
> I should say that other than trying to load the NATs, everything else 
> is working fine.  Here is the small config that I am currently running 
> (don't worry, this isn't production, yet):
>
> # Generated by iptables-save v1.2.11 on Mon May 16 13:42:26 2005
> *filter
> :INPUT ACCEPT [89274:15206611]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [9009:1656730]
> -A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p icmp -j ACCEPT
> -A INPUT -s xxx.xxx.xxx.64/255.255.255.192 -p icmp -j ACCEPT
> -A INPUT -s xxx.xxx.xxx.65 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -p tcp -j DROP
> -A INPUT -p udp -j DROP
> -A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 80 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 5666 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 80 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 1999 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 4899 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 5666 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 8080 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.62 -p tcp -m tcp --dport 4899 -j ACCEPT
> -A FORWARD -d xxx.xxx.xxx.63 -p tcp -m tcp --dport 5666 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
> -A OUTPUT -p icmp -j ACCEPT
> -A OUTPUT -p icmp -j DROP
> -A OUTPUT -p tcp -j DROP
> -A OUTPUT -p udp -j DROP
> COMMIT
> # Completed on Mon May 16 13:42:26 2005
>
>
> Jason Opperisano wrote:
>
>> On Fri, May 13, 2005 at 01:04:31PM -0700, Brian Atkins wrote:
>>  
>>
>>> Greetings:
>>>
>>> I'm in the process of building my first dedicated firewall using 
>>> iptables/netfilter (v 1.2.11) on Gentoo Linux (2.6.11 kernel).  I 
>>> want to enable the natting of IPs, but I am having trouble getting 
>>> the rules to take.  Essentially, I would like to take a specific 
>>> group of IPs (servers) and nat them specifically to an internal ip 
>>> address.  The remainder of the internal IPs (workstations - dhcp) 
>>> should be natted outbound within a range of IPs.
>>>
>>> Based on the docs on Netfilter.org and the man pages, I decided to 
>>> start off with the following:
>>>
>>> iptables -t nat -A PREROUTING -i eth0 -d 141.xxx.xxx.xxx -j DNAT 
>>> --to-destination 10.xxx.xxx.xxx
>>>
>>> But, when I try to run the command, it just hangs. After a while, I 
>>> can break out of it with CTL-C.
>>>
>>> What gives?  Am I missing something?
>>>   
>>
>>
>> the syntax of that rule looks fine to me.  i'm going to go out on a limb
>> and say there is something rotten in your kernel config.
>>
>> out of curiosity, how did you compile the kernel for this machine, by
>> hand, or by using genkernel?
>>
>> also, what does:
>>
>>  $ cat /proc/net/ip_tables_names
>> and
>>  $ cat /proc/net/ip_tables_targets
>>
>> have to say?
>>
>> -j
>>
>> -- 
>> "Tom Tucker: Now let's go to Greg The Weather Mime. OK... it's going
>> to be cold...lots of wind... and it looks like parents are going to
>> throw human fecal matter from the rooftops onto their children... oh,
>> GOD. That's awful. No wait, it looks like rain. Yes, rain."
>>        --Family Guy
>>
>>  
>>
>



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-16 15:40   ` Brian Atkins
  2005-05-16 17:18     ` John Mok
@ 2005-05-16 21:53     ` Jason Opperisano
  1 sibling, 0 replies; 9+ messages in thread
From: Jason Opperisano @ 2005-05-16 21:53 UTC (permalink / raw)
  To: netfilter

On Mon, May 16, 2005 at 08:40:49AM -0700, Brian Atkins wrote:
> Jason,
> 
> Sorry for the delay in response.  Catting either of those files doesn't 
> return much.  The ip_tables_names only returns: "filter"; 
> ip_tables_targets is null. 

um--sounds like you don't have support for the mangle or nat tables
compiled into your kernel...eek.

> I did use genkernel to build the new kernel. I did have multiple issues 
> with the kernel config initially, but mostly related to disk drivers. I 
> can forward my .config if that might be helpful. 

i think a:

  grep _NF_ .config

may be of use.  my guess is that neither CONFIG_IP_NF_NAT nor
CONFIG_IP_NF_MANGLE are set.  this is probably a Bad Thing (tm).

-j

--
"Guy in Chicken Suit: Enjoy your chicken sandwich.
 Stewie: Enjoy your studio apartment."
        --Family Guy


^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Natting IPs hanging
@ 2005-05-19 19:55 Brian Atkins
  2005-05-20 10:38 ` Brian Atkins
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Atkins @ 2005-05-19 19:55 UTC (permalink / raw)
  To: netfilter

Jason and John,

Again, thanks for the responses.  I've finally had an opportunity to dig 
back into it after a rather nightmare-ish week...

I tried a couple of different things, without much success.  First, 
seeing as how I'm realtively new at this, I went back to the docs on 
Netfilter and pulled a script out of the appedices of one of the HOWTOs 
and modified it for my use.  Following their setup, I used it to create 
several new chains and new rules that I hadn't thought of implementing.  
Now, when I went back and checked out ip_tables_names and 
ip_tables_targets, I get the following:

root@fw>cat /proc/net/ip_tables_names
mangle
nat
filter

root@fw>cat /proc/net/ip_tables_targets
REJECT
LOG
DNAT
SNAT

Also, I checked out the kernel config and got the following list of 
modules that were created with the new build:
root@fw>grep _NF_ /usr/src/linux/.config
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
CONFIG_IP_NF_MATCH_COMMENT=m
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

Likewise, here is what is currently loaded:
root@fw>lsmod
Module                  Size  Used by
ip_nat_ftp              3584  0
ip_conntrack_ftp       72976  1 ip_nat_ftp
ipt_state               2560  5
ipt_limit               3072  2
iptable_mangle          3328  0
ipt_REJECT              6528  1
ipt_LOG                 7552  2
iptable_nat            23868  2 ip_nat_ftp
ip_conntrack           49992  4 
ip_nat_ftp,ip_conntrack_ftp,ipt_state,iptable_nat
iptable_filter          3328  1
ip_tables              23296  7 
ipt_state,ipt_limit,iptable_mangle,ipt_REJECT,ipt_LOG,iptable_nat,iptable_filter
BLADABLADABLADA

Here is my routing table (for what it's worth):
root@fw>route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
[OUTSIDE _NET]  *               255.255.255.192 U     0      0        0 eth0
[INSIDE_NET]    *               255.0.0.0       U     0      0        0 eth2
loopback        localhost       255.0.0.0       UG    0      0        0 lo
default         [OUTSIDE_GW]    0.0.0.0         UG    0      0        0 eth0

And, finally, my current ruleset (and I welcome all critiques):
root@fw>iptables-save
# Generated by iptables-save v1.3.1
*mangle
:PREROUTING ACCEPT [4431:597383]
:INPUT ACCEPT [4387:587673]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1709:222042]
:POSTROUTING ACCEPT [1686:202254]
COMMIT
*nat
:PREROUTING ACCEPT [2731:449771]
:POSTROUTING ACCEPT [13:950]
:OUTPUT ACCEPT [13:950]
-A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
-A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
-A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
-A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
COMMIT
*filter
:ALLOWED - [0:0]
:BAD_TCP_PACKETS - [0:0]
:ICMP_PACKETS - [0:0]
:INPUT DROP [2625:435028]
:FORWARD DROP [0:0]
:OUTPUT DROP [23:19788]
:POSTROUTING - [0:0]
:PREROUTING - [0:0]
:TCP_PACKETS - [0:0]
:UDP_PACKETS - [0:0]
-A ALLOWED -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A ALLOWED -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ALLOWED -p tcp -j DROP
-A BAD_TCP_PACKETS -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state 
--state NEW -j REJECT --reject-with tcp-reset
-A BAD_TCP_PACKETS -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state 
--state NEW -j DROP
-A ICMP_PACKETS -s [PRIVATE_NET]/255.0.0.0 -p icmp -j ACCEPT
-A ICMP_PACKETS -s [PUBLIC_NET]/255.255.255.192 -p icmp -j ACCEPT
-A ICMP_PACKETS -s 127.0.0.0/255.0.0.0 -p icmp -j ACCEPT
-A ICMP_PACKETS -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A INPUT -j PREROUTING
-A INPUT -p tcp -j BAD_TCP_PACKETS
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -s [PRIVATE_IP_FW] -i lo -j ACCEPT
-A INPUT -s [PUBLIC_IP_FW] -i lo -j ACCEPT
-A INPUT -d [PUBLIC_IP_FW] -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -j TCP_PACKETS
-A INPUT -p udp -j UDP_PACKETS
-A INPUT -p icmp -j ICMP_PACKETS
-A FORWARD -p tcp -j BAD_TCP_PACKETS
-A FORWARD -d [PUBLIC_NET]/255.255.255.192 -p tcp -j PREROUTING
-A FORWARD -p icmp -m icmp --icmp-type 3/4 -j ICMP_PACKETS
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix 
"IPT FORWARD packet died: " --log-level 7
-A OUTPUT -s 127.0.0.1 -j ACCEPT
-A OUTPUT -s [PRIVATE_IP_FW] -j ACCEPT
-A OUTPUT -s [PUBLIC_IP_FW] -j ACCEPT
-A OUTPUT -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix 
"IPT OUTPUT packet died: " --log-level 7
-A TCP_PACKETS -p tcp -m tcp --dport 21 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 22 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 25 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 80 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 443 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 873 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 1999 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 4899 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 5666 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 8080 -j ALLOWED
-A TCP_PACKETS -p tcp -m tcp --dport 11371 -j ALLOWED
-A UDP_PACKETS -p udp -m udp --sport 53 -j ACCEPT
-A UDP_PACKETS -p udp -m udp --sport 123 -j ACCEPT
-A UDP_PACKETS -p udp -m udp --sport 873 -j ACCEPT
COMMIT
# Completed

I also tried FireHOL to build the rules from a config file.  I liked how 
*through* it appeared to be, but I went back to the original script for 
troubleshooting purposes.

-- 
Brian Atkins
IT Services
The Library Corporation
http://TLCdelivers.com
Ph: 800.624.0559



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-19 19:55 Brian Atkins
@ 2005-05-20 10:38 ` Brian Atkins
  2005-05-20 15:47   ` Jason Opperisano
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Atkins @ 2005-05-20 10:38 UTC (permalink / raw)
  To: netfilter

Brian Atkins wrote:

> Jason and John,
>
> Again, thanks for the responses.  I've finally had an opportunity to 
> dig back into it after a rather nightmare-ish week...
>
> I tried a couple of different things, without much success.  First, 
> seeing as how I'm realtively new at this, I went back to the docs on 
> Netfilter and pulled a script out of the appedices of one of the 
> HOWTOs and modified it for my use.  Following their setup, I used it 
> to create several new chains and new rules that I hadn't thought of 
> implementing.  Now, when I went back and checked out ip_tables_names 
> and ip_tables_targets, I get the following:
>
> root@fw>cat /proc/net/ip_tables_names
> mangle
> nat
> filter
>
> root@fw>cat /proc/net/ip_tables_targets
> REJECT
> LOG
> DNAT
> SNAT
>
> Also, I checked out the kernel config and got the following list of 
> modules that were created with the new build:
> root@fw>grep _NF_ /usr/src/linux/.config
> CONFIG_IP_NF_CONNTRACK=m
> # CONFIG_IP_NF_CT_ACCT is not set
> # CONFIG_IP_NF_CONNTRACK_MARK is not set
> # CONFIG_IP_NF_CT_PROTO_SCTP is not set
> CONFIG_IP_NF_FTP=m
> # CONFIG_IP_NF_IRC is not set
> # CONFIG_IP_NF_TFTP is not set
> # CONFIG_IP_NF_AMANDA is not set
> # CONFIG_IP_NF_QUEUE is not set
> CONFIG_IP_NF_IPTABLES=m
> CONFIG_IP_NF_MATCH_LIMIT=m
> CONFIG_IP_NF_MATCH_IPRANGE=m
> CONFIG_IP_NF_MATCH_MAC=m
> CONFIG_IP_NF_MATCH_PKTTYPE=m
> CONFIG_IP_NF_MATCH_MARK=m
> CONFIG_IP_NF_MATCH_MULTIPORT=m
> CONFIG_IP_NF_MATCH_TOS=m
> CONFIG_IP_NF_MATCH_RECENT=m
> CONFIG_IP_NF_MATCH_ECN=m
> CONFIG_IP_NF_MATCH_DSCP=m
> CONFIG_IP_NF_MATCH_AH_ESP=m
> CONFIG_IP_NF_MATCH_LENGTH=m
> CONFIG_IP_NF_MATCH_TTL=m
> CONFIG_IP_NF_MATCH_TCPMSS=m
> CONFIG_IP_NF_MATCH_HELPER=m
> CONFIG_IP_NF_MATCH_STATE=m
> CONFIG_IP_NF_MATCH_CONNTRACK=m
> CONFIG_IP_NF_MATCH_OWNER=m
> CONFIG_IP_NF_MATCH_ADDRTYPE=m
> CONFIG_IP_NF_MATCH_REALM=m
> # CONFIG_IP_NF_MATCH_SCTP is not set
> CONFIG_IP_NF_MATCH_COMMENT=m
> # CONFIG_IP_NF_MATCH_HASHLIMIT is not set
> CONFIG_IP_NF_FILTER=m
> CONFIG_IP_NF_TARGET_REJECT=m
> CONFIG_IP_NF_TARGET_LOG=m
> CONFIG_IP_NF_TARGET_ULOG=m
> CONFIG_IP_NF_TARGET_TCPMSS=m
> CONFIG_IP_NF_NAT=m
> CONFIG_IP_NF_NAT_NEEDED=y
> CONFIG_IP_NF_TARGET_MASQUERADE=m
> CONFIG_IP_NF_TARGET_REDIRECT=m
> CONFIG_IP_NF_TARGET_NETMAP=m
> CONFIG_IP_NF_TARGET_SAME=m
> CONFIG_IP_NF_NAT_SNMP_BASIC=m
> CONFIG_IP_NF_NAT_FTP=m
> CONFIG_IP_NF_MANGLE=m
> CONFIG_IP_NF_TARGET_TOS=m
> CONFIG_IP_NF_TARGET_ECN=m
> CONFIG_IP_NF_TARGET_DSCP=m
> CONFIG_IP_NF_TARGET_MARK=m
> CONFIG_IP_NF_TARGET_CLASSIFY=m
> CONFIG_IP_NF_RAW=m
> CONFIG_IP_NF_TARGET_NOTRACK=m
> CONFIG_IP_NF_ARPTABLES=m
> CONFIG_IP_NF_ARPFILTER=m
> CONFIG_IP_NF_ARP_MANGLE=m
>
> Likewise, here is what is currently loaded:
> root@fw>lsmod
> Module                  Size  Used by
> ip_nat_ftp              3584  0
> ip_conntrack_ftp       72976  1 ip_nat_ftp
> ipt_state               2560  5
> ipt_limit               3072  2
> iptable_mangle          3328  0
> ipt_REJECT              6528  1
> ipt_LOG                 7552  2
> iptable_nat            23868  2 ip_nat_ftp
> ip_conntrack           49992  4 
> ip_nat_ftp,ip_conntrack_ftp,ipt_state,iptable_nat
> iptable_filter          3328  1
> ip_tables              23296  7 
> ipt_state,ipt_limit,iptable_mangle,ipt_REJECT,ipt_LOG,iptable_nat,iptable_filter 
>
> BLADABLADABLADA
>
> Here is my routing table (for what it's worth):
> root@fw>route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
> [OUTSIDE _NET]  *               255.255.255.192 U     0      0        
> 0 eth0
> [INSIDE_NET]    *               255.0.0.0       U     0      0        
> 0 eth2
> loopback        localhost       255.0.0.0       UG    0      0        
> 0 lo
> default         [OUTSIDE_GW]    0.0.0.0         UG    0      0        
> 0 eth0
>
> And, finally, my current ruleset (and I welcome all critiques):
> root@fw>iptables-save
> # Generated by iptables-save v1.3.1
> *mangle
> :PREROUTING ACCEPT [4431:597383]
> :INPUT ACCEPT [4387:587673]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [1709:222042]
> :POSTROUTING ACCEPT [1686:202254]
> COMMIT
> *nat
> :PREROUTING ACCEPT [2731:449771]
> :POSTROUTING ACCEPT [13:950]
> :OUTPUT ACCEPT [13:950]
> -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination 
> [PRIVATE_IP]
> -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination 
> [PRIVATE_IP]
> -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
> -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
> COMMIT
> *filter
> :ALLOWED - [0:0]
> :BAD_TCP_PACKETS - [0:0]
> :ICMP_PACKETS - [0:0]
> :INPUT DROP [2625:435028]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [23:19788]
> :POSTROUTING - [0:0]
> :PREROUTING - [0:0]
> :TCP_PACKETS - [0:0]
> :UDP_PACKETS - [0:0]
> -A ALLOWED -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
> -A ALLOWED -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A ALLOWED -p tcp -j DROP
> -A BAD_TCP_PACKETS -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state 
> --state NEW -j REJECT --reject-with tcp-reset
> -A BAD_TCP_PACKETS -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m 
> state --state NEW -j DROP
> -A ICMP_PACKETS -s [PRIVATE_NET]/255.0.0.0 -p icmp -j ACCEPT
> -A ICMP_PACKETS -s [PUBLIC_NET]/255.255.255.192 -p icmp -j ACCEPT
> -A ICMP_PACKETS -s 127.0.0.0/255.0.0.0 -p icmp -j ACCEPT
> -A ICMP_PACKETS -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
> -A INPUT -j PREROUTING
> -A INPUT -p tcp -j BAD_TCP_PACKETS
> -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
> -A INPUT -s [PRIVATE_IP_FW] -i lo -j ACCEPT
> -A INPUT -s [PUBLIC_IP_FW] -i lo -j ACCEPT
> -A INPUT -d [PUBLIC_IP_FW] -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p tcp -j TCP_PACKETS
> -A INPUT -p udp -j UDP_PACKETS
> -A INPUT -p icmp -j ICMP_PACKETS
> -A FORWARD -p tcp -j BAD_TCP_PACKETS
> -A FORWARD -d [PUBLIC_NET]/255.255.255.192 -p tcp -j PREROUTING
> -A FORWARD -p icmp -m icmp --icmp-type 3/4 -j ICMP_PACKETS
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix 
> "IPT FORWARD packet died: " --log-level 7
> -A OUTPUT -s 127.0.0.1 -j ACCEPT
> -A OUTPUT -s [PRIVATE_IP_FW] -j ACCEPT
> -A OUTPUT -s [PUBLIC_IP_FW] -j ACCEPT
> -A OUTPUT -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix 
> "IPT OUTPUT packet died: " --log-level 7
> -A TCP_PACKETS -p tcp -m tcp --dport 21 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 22 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 25 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 80 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 443 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 873 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 1999 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 4899 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 5666 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 8080 -j ALLOWED
> -A TCP_PACKETS -p tcp -m tcp --dport 11371 -j ALLOWED
> -A UDP_PACKETS -p udp -m udp --sport 53 -j ACCEPT
> -A UDP_PACKETS -p udp -m udp --sport 123 -j ACCEPT
> -A UDP_PACKETS -p udp -m udp --sport 873 -j ACCEPT
> COMMIT
> # Completed
>
> I also tried FireHOL to build the rules from a config file.  I liked 
> how *through* it appeared to be, but I went back to the original 
> script for troubleshooting purposes.
>

Now, even more strange is that I stripped everything out right down to 
just the natting piece and I still can't traverse the fw:

# Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
*raw
:PREROUTING ACCEPT [185327:123272626]
:OUTPUT ACCEPT [71616:17819696]
COMMIT
# Completed on Fri May 20 06:23:40 2005
# Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
*nat
:PREROUTING ACCEPT [20964:3942558]
:POSTROUTING ACCEPT [54:3564]
:OUTPUT ACCEPT [53:3480]
-A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
-A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
-A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
-A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
COMMIT
# Completed on Fri May 20 06:23:40 2005
# Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
*filter
:INPUT ACCEPT [955:375232]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1219:191838]
:POSTROUTING - [0:0]
:PREROUTING - [0:0]
-A FORWARD -i eth1 -j POSTROUTING
COMMIT
# Completed on Fri May 20 06:23:40 2005

By all intents I should be vulnerable to the world.  From the outside, I 
can hit the external facing NIC, but I can't get to the public IP of one 
of my webservers.  From the inside, I can hit both NICs (inside/outside) 
on the firewall, but not the internal facing NIC on the ex-router.  From 
the firewall, I can see both WWW and my internal network.

Is there a tool to debug iptables to see if any of the rules are being 
used by incoming traffic?

-- 
Brian Atkins
IT Services
The Library Corporation
http://TLCdelivers.com
Ph: 800.624.0559



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
  2005-05-20 10:38 ` Brian Atkins
@ 2005-05-20 15:47   ` Jason Opperisano
  0 siblings, 0 replies; 9+ messages in thread
From: Jason Opperisano @ 2005-05-20 15:47 UTC (permalink / raw)
  To: netfilter

On Sun, May 22, 2005 at 06:28:55AM -0700, Brian Atkins wrote:
> Now, even more strange is that I stripped everything out right down to 
> just the natting piece and I still can't traverse the fw:
> 
> # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
> *raw
> :PREROUTING ACCEPT [185327:123272626]
> :OUTPUT ACCEPT [71616:17819696]
> COMMIT
> # Completed on Fri May 20 06:23:40 2005
> # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
> *nat
> :PREROUTING ACCEPT [20964:3942558]
> :POSTROUTING ACCEPT [54:3564]
> :OUTPUT ACCEPT [53:3480]
> -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
> -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
> -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
> -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
> COMMIT
> # Completed on Fri May 20 06:23:40 2005
> # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
> *filter
> :INPUT ACCEPT [955:375232]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [1219:191838]
> :POSTROUTING - [0:0]
> :PREROUTING - [0:0]
> -A FORWARD -i eth1 -j POSTROUTING

um--wtf is this?

looking at the hit-count numbers of INPUT and OUTPUT vs. the fact that
FORWARD is sitting steady at zero...i'm going take a swipe at the low
hanging fruit and say you forgot to enable IP forwarding:

  sysctl -w net.ipv4.ip_forward=1

> COMMIT
> # Completed on Fri May 20 06:23:40 2005
> 
> By all intents I should be vulnerable to the world.  From the outside, I 
> can hit the external facing NIC, but I can't get to the public IP of one 
> of my webservers.  From the inside, I can hit both NICs (inside/outside) 
> on the firewall, but not the internal facing NIC on the ex-router.  From 
> the firewall, I can see both WWW and my internal network.
> 
> Is there a tool to debug iptables to see if any of the rules are being 
> used by incoming traffic?

iptables -vnxL will show you the hit-counts on your rules.  in a
controlled environment and with specific rules, you should be able to
determine rather easily if the rule you think should be matching is
actually matching.

-j

--
"Brian: I've been to New York. It's like Prague sans the whimsy."
        --Family Guy


^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Natting IPs hanging
       [not found] <200505161949.j4GJnhXF027020@mail.tlcdelivers.com>
@ 2005-05-23 20:45 ` Brian Atkins
  0 siblings, 0 replies; 9+ messages in thread
From: Brian Atkins @ 2005-05-23 20:45 UTC (permalink / raw)
  To: netfilter

Jason,

Forwarding is turned on... I'm quite certain of that, since it was the 
very first thing I looked at.

root@ns2>cat /proc/sys/net/ipv4/ip_forward
1

root@ns2>sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1

In the previous message I posted, the first piece of info I provided was 
the output of iptables-save.  I thought that this would be useful to see 
my current set of rules.  This is the current output of 'iptables -vxnL':
root@ns2>iptables -vxnL
Chain INPUT (policy ACCEPT 173854 packets, 30669333 bytes)
    pkts      bytes target     prot opt in     out     
source               destination
       0        0 ACCEPT     tcp  --  *      *       
0.0.0.0/0            0.0.0.0/0           tcp dpt:53
     174    13388 ACCEPT     udp  --  *      *       
0.0.0.0/0            0.0.0.0/0           udp dpt:53
       0        0 ACCEPT     tcp  --  eth0   *       
xxx.xxx.xxx.64/26    0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     icmp --  eth0   *       
xxx.xxx.xxx.64/26    0.0.0.0/0
    1111    78124 ACCEPT     tcp  --  eth2   *       
10.0.0.0/8           0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     icmp --  eth2   *       
10.0.0.0/8           0.0.0.0/0
      20     3054 REJECT     all  --  eth0   *       
0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 1 packets, 32 bytes)
    pkts      bytes target     prot opt in     out     
source               destination
       0        0 ACCEPT     tcp  --  eth0   eth2    
0.0.0.0/0            xxx.xxx.xxx.123     multiport dports 22,443 state NEW
       0        0 ACCEPT     all  --  *      eth0    
0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED
       0        0 ACCEPT     all  --  *      eth1    
0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED
       0        0 ACCEPT     all  --  eth0   *       
0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
       0        0 ACCEPT     all  --  eth1   *       
0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
       1       32 REJECT     all  --  *      *       
0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 255 packets, 38082 bytes)
    pkts      bytes target     prot opt in     out     
source               destination
    1085   213098 ACCEPT     all  --  *      *       
0.0.0.0/0            0.0.0.0/0

And 'lsmod':
root@ns2>lsmod
Module                  Size  Used by
ipt_REJECT              6528  2
ipt_state               2560  5
ipt_multiport           3200  1
iptable_mangle          3328  0
iptable_nat            23868  1
ip_conntrack           49992  2 ipt_state,iptable_nat
iptable_filter          3328  1
ip_tables              23296  6 
ipt_REJECT,ipt_state,ipt_multiport,iptable_mangle,iptable_nat,iptable_filter
...

And 'route/netstat -rn':
root@ns2>route | sed 's/141.157.129/xxx.xxx.xxx/g'
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
xxx.xxx.xxx.64  *               255.255.255.192 U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 eth2
loopback        localhost       255.0.0.0       UG    0      0        0 lo
default         xxx.xxx.xxx.65  0.0.0.0         UG    0      0        0 eth0

I thought, perhaps, it was an issue with the OS, but over the weekend, I 
took the opportunity to install Fedora (default kernel settings) on a 
similar unit and got the same results.  So, I'm of the assumption that 
it is either a) routing related, or b) iptables rules mis-configuration.

I'm not convinced that it is actually a problem with iptables since I 
went back to a textbook config from the RHCE (which worked fine in the 
lab), but doesn't work on this box or the one I built over the weekend.

Any other sources for info that I could hit up for info.  I've Googled 
the heck out of this...

netfilter-request@lists.netfilter.org wrote:

>On Sun, May 22, 2005 at 06:28:55AM -0700, Brian Atkins wrote:
>>/ Now, even more strange is that I stripped everything out right down to 
>/>/ just the natting piece and I still can't traverse the fw:
>/>/ 
>/>/ # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
>/>/ *raw
>/>/ :PREROUTING ACCEPT [185327:123272626]
>/>/ :OUTPUT ACCEPT [71616:17819696]
>/>/ COMMIT
>/>/ # Completed on Fri May 20 06:23:40 2005
>/>/ # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
>/>/ *nat
>/>/ :PREROUTING ACCEPT [20964:3942558]
>/>/ :POSTROUTING ACCEPT [54:3564]
>/>/ :OUTPUT ACCEPT [53:3480]
>/>/ -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
>/>/ -A PREROUTING -d [PUBLIC_IP] -i eth0 -j DNAT --to-destination [PRIVATE_IP]
>/>/ -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
>/>/ -A POSTROUTING -s [PRIVATE_IP] -o eth0 -j SNAT --to-source [PUBLIC_IP]
>/>/ COMMIT
>/>/ # Completed on Fri May 20 06:23:40 2005
>/>/ # Generated by iptables-save v1.3.1 on Fri May 20 06:23:40 2005
>/>/ *filter
>/>/ :INPUT ACCEPT [955:375232]
>/>/ :FORWARD ACCEPT [0:0]
>/>/ :OUTPUT ACCEPT [1219:191838]
>/>/ :POSTROUTING - [0:0]
>/>/ :PREROUTING - [0:0]
>/>/ -A FORWARD -i eth1 -j POSTROUTING
>/
>um--wtf is this?
>
>looking at the hit-count numbers of INPUT and OUTPUT vs. the fact that
>FORWARD is sitting steady at zero...i'm going take a swipe at the low
>hanging fruit and say you forgot to enable IP forwarding:
>
>  sysctl -w net.ipv4.ip_forward=1
>
>>/ COMMIT
>/>/ # Completed on Fri May 20 06:23:40 2005
>/>/ 
>/>/ By all intents I should be vulnerable to the world.  From the outside, I 
>/>/ can hit the external facing NIC, but I can't get to the public IP of one 
>/>/ of my webservers.  From the inside, I can hit both NICs (inside/outside) 
>/>/ on the firewall, but not the internal facing NIC on the ex-router.  From 
>/>/ the firewall, I can see both WWW and my internal network.
>/>/ 
>/>/ Is there a tool to debug iptables to see if any of the rules are being 
>/>/ used by incoming traffic?
>/
>iptables -vnxL will show you the hit-counts on your rules.  in a
>controlled environment and with specific rules, you should be able to
>determine rather easily if the rule you think should be matching is
>actually matching.
>
>-j
>
>--
>"Brian: I've been to New York. It's like Prague sans the whimsy."
>        --Family Guy
>
>>Jason,
>>
>>Sorry for the delay in response.  Catting either of those files 
>>doesn't return much.  The ip_tables_names only returns: "filter"; 
>>ip_tables_targets is null.
>>I did use genkernel to build the new kernel. I did have multiple 
>>issues with the kernel config initially, but mostly related to disk 
>>drivers. I can forward my .config if that might be helpful.
>>I should say that other than trying to load the NATs, everything else 
>>is working fine.  Here is the small config that I am currently running 
>>(don't worry, this isn't production, yet):
>>
>># Generated by iptables-save v1.2.11 on Mon May 16 13:42:26 2005
>>*filter
>>:INPUT ACCEPT [89274:15206611]
>>:FORWARD ACCEPT [0:0]
>>:OUTPUT ACCEPT [9009:1656730]
>>-A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p tcp -m tcp --dport 22 -j ACCEPT
>>-A INPUT -s xxx.xxx.xxx.0/255.0.0.0 -p icmp -j ACCEPT
>>-A INPUT -s xxx.xxx.xxx.64/255.255.255.192 -p icmp -j ACCEPT
>>-A INPUT -s xxx.xxx.xxx.65 -p tcp -m tcp --dport 22 -j ACCEPT
>>-A INPUT -p tcp -j DROP
>>-A INPUT -p udp -j DROP
>>-A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 80 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.57 -p tcp -m tcp --dport 5666 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 80 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 1999 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 4899 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 5666 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.61 -p tcp -m tcp --dport 8080 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.62 -p tcp -m tcp --dport 4899 -j ACCEPT
>>-A FORWARD -d xxx.xxx.xxx.63 -p tcp -m tcp --dport 5666 -j ACCEPT
>>-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
>>-A OUTPUT -p icmp -j ACCEPT
>>-A OUTPUT -p icmp -j DROP
>>-A OUTPUT -p tcp -j DROP
>>-A OUTPUT -p udp -j DROP
>>COMMIT
>># Completed on Mon May 16 13:42:26 2005
>>
>>
>>Jason Opperisano wrote:
>>
>>    
>>
>>>On Fri, May 13, 2005 at 01:04:31PM -0700, Brian Atkins wrote:
>>> 
>>>
>>>      
>>>
>>>>Greetings:
>>>>
>>>>I'm in the process of building my first dedicated firewall using 
>>>>iptables/netfilter (v 1.2.11) on Gentoo Linux (2.6.11 kernel).  I 
>>>>want to enable the natting of IPs, but I am having trouble getting 
>>>>the rules to take.  Essentially, I would like to take a specific 
>>>>group of IPs (servers) and nat them specifically to an internal ip 
>>>>address.  The remainder of the internal IPs (workstations - dhcp) 
>>>>should be natted outbound within a range of IPs.
>>>>
>>>>Based on the docs on Netfilter.org and the man pages, I decided to 
>>>>start off with the following:
>>>>
>>>>iptables -t nat -A PREROUTING -i eth0 -d 141.xxx.xxx.xxx -j DNAT 
>>>>--to-destination 10.xxx.xxx.xxx
>>>>
>>>>But, when I try to run the command, it just hangs. After a while, I 
>>>>can break out of it with CTL-C.
>>>>
>>>>What gives?  Am I missing something?
>>>>  
>>>>        
>>>>
>>>the syntax of that rule looks fine to me.  i'm going to go out on a limb
>>>and say there is something rotten in your kernel config.
>>>
>>>out of curiosity, how did you compile the kernel for this machine, by
>>>hand, or by using genkernel?
>>>
>>>also, what does:
>>>
>>> $ cat /proc/net/ip_tables_names
>>>and
>>> $ cat /proc/net/ip_tables_targets
>>>
>>>have to say?
>>>
>>>-j
>>>
>>>-- 
>>>"Tom Tucker: Now let's go to Greg The Weather Mime. OK... it's going
>>>to be cold...lots of wind... and it looks like parents are going to
>>>throw human fecal matter from the rooftops onto their children... oh,
>>>GOD. That's awful. No wait, it looks like rain. Yes, rain."
>>>       --Family Guy
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 16 May 2005 13:40:57 -0400 (EDT)
>From: "R. DuFresne" <dufresne@sysinfo.com>
>Subject: Re: okay, I admit confusion here;
>To: Jason Opperisano <opie@817west.com>
>Cc: netfilter@lists.netfilter.org
>Message-ID: <Pine.LNX.4.60.0505161332480.15128@darkstar.sysinfo.com>
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Fri, 13 May 2005, Jason Opperisano wrote:
>
>  
>
>>On Fri, May 13, 2005 at 05:31:06PM -0400, R. DuFresne wrote:
>>    
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>I have moved from a p-p-p dialup serivce to a rr business class service
>>><and learned to hate verizion>.  Anyways, rr brings in a router, and
>>>gives me the /28 block <router takes an address>.  how do I setup  eht0
>>>and eth1 to share the same block?  Is this a case for interface bridging
>>>and ip2route?
>>>
>>>router  <->   eth1 <external>   <->   eth0 <internal, connects to the home
>>>
>>>router = xxx.xxx.xxx.17
>>>
>>>eth1 = xxx.xxx.xxx.18
>>>
>>>eth0 = xxx.xxx.xxx.19
>>>
>>>Rest of the home net gets IP's 20-30
>>>      
>>>
>>sounds like a job for bridging.  how's about:
>>
>>router	= .17
>>
>>br0	= .18
>>
>>where br0 is a bridge device containing member ports eth0 and eth1.
>>
>>rest of the home net can use .19 - .30 and use .17 as their default
>>gateway.  the only reason the bridging linux firewall needs an IP at all
>>would be for SSH mgmt.
>>
>>    
>>
>
>- From what I have seen of the bridging abilities and ebtables this gets 
>ugly as we are reduced to layer 2 filtering and have a lack of control of 
>the higher level protocols, which is basically useless here.
>
>The only work about I note would be to bridge and then 'untransparent' the 
>whole thing by putting IP's on both bridged eht cards and then filtering 
>and all is reduced to eth1 and eth0 kind of rules.  All of it again ugly, 
>and wasteful...
>
>Course, others might have a better understanding of the capabilities of 
>bridging and ebtables that I'm missing.  here's the setup in more detail;
>
>
>
>
>                                  ______________________________
>                                 |                              |
>                                 |       rr router              |
>                                 |                              |
>                                 |      three nets off it       |
>                                 |                              |
>                                 |______________________________|
>                                         |       |       |
>                                         |       |       |
>                                 ________|       |       |________
>                                 |               |               |
>                                 |               |               |
>                         public /28      private  /24        private class 
>C dhcp
>
>
>                         |
>                         |
>                         |
>                         |
>                        eth1
>                         |
>                  darkstar.sysinfo.com
>                         |
>              ______________________
>              |                    |
>              |     home fw        |
>              |                    |
>              |                    |
>              |____________________|
>                         |
>                         |
>                       eth0
>                         |
>                 blackhole.sysinfo.com
>                 mail.sysinfo.com
>                 www.sysinfo.com
>                    sysinfo.com
>                         |
>                         |
>
>
>
>                 internal network
>
>                 with public IP's_
>
>
>
>
>Thanks,
>
>Ron DuFresne
>- -- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
>Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
>...We waste time looking for the perfect lover
>instead of creating the perfect love.
>
>                 -Tom Robbins <Still Life With Woodpecker>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFCiNs0st+vzJSwZikRAvlfAJ4xSd1NQqBv2Ups2nuC9hGqu3GNagCg2ndx
>ICPAl3aB9Uo9VphwjEAk7Fo=
>=WrHm
>-----END PGP SIGNATURE-----
>
>
>
>------------------------------
>
>Message: 5
>Date: Mon, 16 May 2005 13:35:34 -0500
>From: "Taylor, Grant" <gtaylor@riverviewtech.net>
>Subject: Re: Combined Internal/External DNAT question
>To: netfilter@lists.netfilter.org
>Message-ID: <4288E7F6.3030700@riverviewtech.net>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>  
>
>>My problem still remains however Grant. I would have to create another DNAT rule to match each existing *real* public DNAT rule that currently exists to DNAT traffic from the Internet.  Do you have any further ideas for me? Given that a packet can have both the src and dst IP address rewritten in it's one trip through iptables, it seems to me that it should be possible for two rewrites to happen at once. My thinking it perhaps breaking the nat table into several chains?  Any other suggestions, you've been most helpful so far.
>>    
>>
>
>
>The only other thing that comes to mind would be to use iphash (IP)sets of destination IP addresses on your original DNAT rules.  This would cause your iptables rule to match based on the destination of your external IP of your firewall OR your external IP of your DSL modem (/router) and DNAT the traffic to the real server on your 2nd internal subnet.  Here is an example rule for what you would need:
>
>iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT --to-destination <relevant.internal.server>:<tcpservice>
>
>To support this rule you would need to do the following (likely before you issued the above rule):
>
>ipset -N My_IP_Set iphash
>ipset -A My_IP_Set 10.0.0.1
>ipset -A My_IP_Set <Public IP>
>
>As stated before this should cause your one iptables rule to match packets that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets to the <relevant.internal.server>:<tcpservice>.  I know that this is not the multiple passes through the iptables chains like you were asking for, but I think it will provide a solution comparable  to the result that you were after.  Rather than have a rule that will alter traffic such that it will be caught by another rule and then altered again why not have a rule that will catch either type of traffic.
>
>
>
>Grant. . . .
>
>
>
>------------------------------
>
>Message: 6
>Date: Mon, 16 May 2005 15:27:43 -0400 (EDT)
>From: "R. DuFresne" <dufresne@sysinfo.com>
>Subject: Re: Combined Internal/External DNAT question
>To: "Taylor, Grant" <gtaylor@riverviewtech.net>
>Cc: netfilter@lists.netfilter.org
>Message-ID: <Pine.LNX.4.60.0505161523100.15128@darkstar.sysinfo.com>
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mon, 16 May 2005, Taylor, Grant wrote:
>
>  
>
>>>My problem still remains however Grant. I would have to create another 
>>>DNAT rule to match each existing *real* public DNAT rule that currently 
>>>exists to DNAT traffic from the Internet.  Do you have any further ideas 
>>>for me? Given that a packet can have both the src and dst IP address 
>>>rewritten in it's one trip through iptables, it seems to me that it should 
>>>be possible for two rewrites to happen at once. My thinking it perhaps 
>>>breaking the nat table into several chains?  Any other suggestions, you've 
>>>been most helpful so far.
>>>      
>>>
>>The only other thing that comes to mind would be to use iphash (IP)sets of 
>>destination IP addresses on your original DNAT rules.  This would cause your 
>>iptables rule to match based on the destination of your external IP of your 
>>firewall OR your external IP of your DSL modem (/router) and DNAT the traffic 
>>to the real server on your 2nd internal subnet.  Here is an example rule for 
>>what you would need:
>>
>>iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT 
>>--to-destination <relevant.internal.server>:<tcpservice>
>>
>>To support this rule you would need to do the following (likely before you 
>>issued the above rule):
>>
>>ipset -N My_IP_Set iphash
>>ipset -A My_IP_Set 10.0.0.1
>>ipset -A My_IP_Set <Public IP>
>>
>>As stated before this should cause your one iptables rule to match packets 
>>that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets 
>>to the <relevant.internal.server>:<tcpservice>.  I know that this is not the 
>>multiple passes through the iptables chains like you were asking for, but I 
>>think it will provide a solution comparable  to the result that you were 
>>after.  Rather than have a rule that will alter traffic such that it will be 
>>caught by another rule and then altered again why not have a rule that will 
>>catch either type of traffic.
>>
>>    
>>
>
>Actually, if this does not help the original poster, it may work in my 
>issues in the thread on "okay I admit confusion here..."
>
>I think my best solution is one to one nat of public addresses to internal 
>private addresses.  Means I have to put some post/pre routing rules in 
>place and I might beable to shorten that all up with IP hashes as you are 
>suggesting here.  But, all in all I think that sure beats bridging 
>interfaces and dealing with trying to firewall at layer2...
>
>
>Thanks,
>
>
>Ron DuFresne
>- -- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
>Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
>...We waste time looking for the perfect lover
>instead of creating the perfect love.
>
>                 -Tom Robbins <Still Life With Woodpecker>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFCiPQzst+vzJSwZikRAtEWAKCy8I6X6s5EwnsIWNPw5Kmo/pyO5wCdHFe4
>c4qm+DWsr0VvOtqZxHdGyFU=
>=xH0c
>-----END PGP SIGNATURE-----
>
>
>
>------------------------------
>
>Message: 7
>Date: Mon, 16 May 2005 15:50:42 -0400 (EDT)
>From: "R. DuFresne" <dufresne@sysinfo.com>
>Subject: Re: Combined Internal/External DNAT question
>To: "Taylor, Grant" <gtaylor@riverviewtech.net>
>Cc: netfilter@lists.netfilter.org
>Message-ID: <Pine.LNX.4.60.0505161548000.15128@darkstar.sysinfo.com>
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>an interesting tidbit from the iptables man pages suggests that their is a 
>built in facility for this one to one nat thingie I'm looking into here;
>
>    NETMAP
>        This  target allows you to statically map a whole network of 
>addresses onto another network of addresses.
>        It can only be used from rules in the nat table.
>
>        --to address[/mask]
>               Network address to map to.  The resulting address will be 
>constructed in the  following  way:  All
>               'one'  bits  in the mask are filled in from the new 
>`address'.  All bits that are zero in the mask
>               are filled in from the original address.
>
>
>If I read this correctly, it appears to build the hash tables of addresses 
>for one eh?
>
>Thanks,
>
>Ron DuFresne
>
>On Mon, 16 May 2005, R. DuFresne wrote:
>
>  
>
>>--[PinePGP]--------------------------------------------------[begin]--
>>On Mon, 16 May 2005, Taylor, Grant wrote:
>>
>>    
>>
>>>>My problem still remains however Grant. I would have to create another
>>>>DNAT rule to match each existing *real* public DNAT rule that currently
>>>>exists to DNAT traffic from the Internet.  Do you have any further ideas
>>>>for me? Given that a packet can have both the src and dst IP address
>>>>rewritten in it's one trip through iptables, it seems to me that it 
>>>>should
>>>>be possible for two rewrites to happen at once. My thinking it perhaps
>>>>breaking the nat table into several chains?  Any other suggestions, 
>>>>you've
>>>>been most helpful so far.
>>>>        
>>>>
>>>The only other thing that comes to mind would be to use iphash (IP)sets of
>>>destination IP addresses on your original DNAT rules.  This would cause 
>>>your
>>>iptables rule to match based on the destination of your external IP of 
>>>your
>>>firewall OR your external IP of your DSL modem (/router) and DNAT the 
>>>traffic
>>>to the real server on your 2nd internal subnet.  Here is an example rule 
>>>for
>>>what you would need:
>>>
>>>iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT
>>>--to-destination <relevant.internal.server>:<tcpservice>
>>>
>>>To support this rule you would need to do the following (likely before you
>>>issued the above rule):
>>>
>>>ipset -N My_IP_Set iphash
>>>ipset -A My_IP_Set 10.0.0.1
>>>ipset -A My_IP_Set <Public IP>
>>>
>>>As stated before this should cause your one iptables rule to match packets
>>>that are destined to any IP in the ip set "My_IP_Set" and DNAT said 
>>>packets
>>>to the <relevant.internal.server>:<tcpservice>.  I know that this is not 
>>>the
>>>multiple passes through the iptables chains like you were asking for, but 
>>>I
>>>think it will provide a solution comparable  to the result that you were
>>>after.  Rather than have a rule that will alter traffic such that it will 
>>>be
>>>caught by another rule and then altered again why not have a rule that 
>>>will
>>>catch either type of traffic.
>>>
>>>      
>>>
>>Actually, if this does not help the original poster, it may work in my
>>issues in the thread on "okay I admit confusion here..."
>>
>>I think my best solution is one to one nat of public addresses to internal
>>private addresses.  Means I have to put some post/pre routing rules in
>>place and I might beable to shorten that all up with IP hashes as you are
>>suggesting here.  But, all in all I think that sure beats bridging
>>interfaces and dealing with trying to firewall at layer2...
>>
>>
>>Thanks,
>>
>>
>>Ron DuFresne
>>--
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>       admin & senior security consultant:  sysinfo.com
>>                       http://sysinfo.com
>>Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>>
>>...We waste time looking for the perfect lover
>>instead of creating the perfect love.
>>
>>               -Tom Robbins <Still Life With Woodpecker>
>>--[PinePGP]-----------------------------------------------------------
>>gpg: Signature made Mon 16 May 2005 03:27:47 PM EDT using DSA key ID 94B06629
>>gpg: Good signature from "dufresne <dufresne@sysinfo.com>"
>>--[PinePGP]----------------------------------------------------[end]--
>>
>>    
>>
>
>- -- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
>Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
>...We waste time looking for the perfect lover
>instead of creating the perfect love.
>
>                 -Tom Robbins <Still Life With Woodpecker>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFCiPmWst+vzJSwZikRAnNJAKDH9bP49JIBtFn1wK5Xbre/CHoNlgCffM0s
>fQET0waj7L4hdtx/EbPmaZY=
>=0jZG
>-----END PGP SIGNATURE-----
>
>
>
>------------------------------
>
>_______________________________________________
>netfilter mailing list
>netfilter@lists.netfilter.org
>https://lists.netfilter.org/mailman/listinfo/netfilter
>
>
>End of netfilter Digest, Vol 10, Issue 47
>*****************************************
>
>  
>

-- 
Brian Atkins
Systems Administrator
The Library Corporation
Research Park * Inwood, WV 25428-9733
Ph: (800) 325-7759 or (304) 229-0100
Fx: (304) 229-0295
http://TLCdelivers.com



^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-05-23 20:45 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <200505161949.j4GJnhXF027020@mail.tlcdelivers.com>
2005-05-23 20:45 ` Natting IPs hanging Brian Atkins
2005-05-19 19:55 Brian Atkins
2005-05-20 10:38 ` Brian Atkins
2005-05-20 15:47   ` Jason Opperisano
  -- strict thread matches above, loose matches on Subject: below --
2005-05-13 20:04 Brian Atkins
2005-05-14 15:26 ` Jason Opperisano
2005-05-16 15:40   ` Brian Atkins
2005-05-16 17:18     ` John Mok
2005-05-16 21:53     ` Jason Opperisano

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.