Date: Fri, 03 Nov 2000 13:11:12 -0800 From: "j telford" <jtelford@visto.com> To: peterk@americanisp.net Cc: questions@freebsd.org Subject: Re: How do I see what the firewall rules are doing ? Message-ID: <20001103213128.8979537B4CF@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
This is a bit long but I've been working on it for a day now so I have lots of
info:
What I want: 1 server inside the firewall to have a public IP address. My BSD
guru set it up on a 3.4 box and it works fine, now I'm trying to do it on a
4.1.1 box and followed his example. It doesn't work, after much trouble
shooting I can tell you this.
If I ping from the private box (P1) to a remote public box (R1) I can see the
packets (using tcpdump) leave the firewall with the redirected address, they
arrive at R1 and R1 responds to the redirected address (RA). The packets NEVER
return to the firewall. If I traceroute from R1 to RA it stops at the firewall
ISP's routers. If I traceroute from P1 to R1 I get to the inside NIC of the
firewall and no more.
Here are my rules, .conf files, even the part I added to GENERIC and recompiled.
(IP numbers have been changed to protect the inocent:
TEMfw3# ipfw show
00050 11 1344 divert 8668 ip from any to any via fxp0
00100 10 988 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
65000 165 11960 allow ip from any to any
65535 0 0 allow ip from any to any
TEMfw3#
TEMfw3# more rc.conf
# This file now contains just the overrides from /etc/defaults/rc.conf
# please make all changes to this file.
# Enable network daemons for user convenience.
# -- sysinstall generated deltas -- #
sendmail_enable="NO"
gateway_enable="YES"
sshd_enable="YES"
inetd_enable="YES"
##############################################################
### Network configuration sub-section ######################
##############################################################
### Basic network and firewall/security options: ###
hostname="TEMfw3" # Set this!
firewall_enable="YES" # Set to YES to enable firewall functionality
firewall_type="OPEN" # Firewall type (see /etc/rc.firewall)
firewall_quiet="NO" # Set to YES to suppress rule display
firewall_logging="YES"
natd_enable="YES" # Enable natd (if firewall_enable == YES).
natd_interface="fxp0" # Public interface or IPaddress to use.
natd_flags="-f /etc/natd.conf"
network_interfaces="auto" # List of network interfaces (or "auto").
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
ifconfig_fxp0="inet 216.208.171.XXX netmask 255.255.255.224"
ifconfig_fxp1="inet 10.150.0.241 netmask 255.255.255.0"
#
named_enable="YES" # Run named, the DNS server (or NO).
defaultrouter="216.208.171.XXX"
TEMfw3#
TEMfw3# more natd.conf
redirect_address 10.150.0.143 216.208.171.XXX
TEMfw3#
#
# IPFIREWALL enables support for IP firewall construction, in
# conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends
# logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT
# limits the number of times a matching entry can be logged.
#
# WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any"
# and if you do not add other rules during startup to allow access,
# YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type=open
# in /etc/rc.conf when first enabling this feature, then refining the
# firewall rules in /etc/rc.firewall after you've tested that the new kernel
# feature works properly.
#
# IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to
# allow everything. Use with care, if a cracker can crash your
# firewall machine, they can get to your protected machines. However,
# if you are using it as an as-needed filter for specific problems as
# they arise, then this may be for you. Changing the default to 'allow'
# means that you won't get stuck if the kernel and /sbin/ipfw binary get
# out of sync.
#
# IPDIVERT enables the divert IP sockets, used by ``ipfw divert''
#
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the ttl). This can be useful to hide firewalls
# from traceroute and similar tools.
#
# TCPDEBUG is undocumented.
#
options TCP_COMPAT_42 #emulate 4.2BSD TCP bugs
options MROUTING # Multicast routing
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #print information about
# dropped packets
options IPFIREWALL_FORWARD #enable transparent proxy support
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default
options IPDIVERT #divert sockets
options IPFILTER #ipfilter support
options IPFILTER_LOG #ipfilter logging
options IPSTEALTH #support for stealth forwarding
options TCPDEBUG
# The following options add sysctl variables for controlling how certain
# TCP packets are handled.
#
# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This
# prevents nmap et al. from identifying the TCP/IP stack, but breaks support
# for RFC1644 extensions and is not recommended for web servers.
#
# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets.
# This is useful on systems which are exposed to SYN floods (e.g. IRC servers)
# or any system which one does not want to be easily portscannable.
#
options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN
options TCP_RESTRICT_RST #restrict emission of TCP RST
# ICMP_BANDLIM enables icmp error response bandwidth limiting. You
# typically want this option as it will help protect the machine from
# D.O.S. packet attacks.
#
options "ICMP_BANDLIM"
# DUMMYNET enables the "dummynet" bandwidth limiter. You need
# IPFIREWALL as well. See the dummynet(4) manpage for more info.
# BRIDGE enables bridging between ethernet cards -- see bridge(4).
# You can use IPFIREWALL and dummynet together with bridging.
options DUMMYNET
options BRIDGE
TEMfw3#
This is how it looks on the 3.4 box. Could it be that the DSL ISP is blocking
something ?? My 3.4 box is on a different ISP.
John...
-----Original Message-----
From: Peter peterk@americanisp.net
Sent: Fri, 3 Nov 2000 13:05:37 -0700 (MST)
To: jtelford@visto.com
CC: questions@freebsd.org
Subject: Re: How do I see what the firewall rules are doing ?
One thing, show us your firewall rules, maybe those got messed up somehow
or the interface changed etc.etc.
--- www.FreeBSD.org --- The Power to Serve!
On Fri, 3 Nov 2000, j telford wrote:
> Fbsd 4.1.1 and trying to natd redirect_address <private ip> <public IP>
> It just won't go, I've set it exactly like my working ver 3.4 Fbsd box with
> redirect.
> I'm guessing it's something in the firewall (but its the same as the 3.4 too)
> I'd love to be able to see whats happening as the rules process How How
How ???
> Can you sense I'm desperate here ? Thanks. John...
>
> ___________________________________________________________________________
> Visit http://www.visto.com/info, your free web-based communications center.
> Visto.com. Life on the Dot.
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
>
>
___________________________________________________________________________
Visit http://www.visto.com/info, your free web-based communications center.
Visto.com. Life on the Dot.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001103213128.8979537B4CF>