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 lo= ts of=20 info: What I want: 1 server inside the firewall to have a public IP address. My= BSD=20 guru set it up on a 3.4 box and it works fine, now I'm trying to do it on= a=20 4.1.1 box and followed his example. It doesn't work, after much trouble=20 shooting I can tell you this.=20 If I ping from the private box (P1) to a remote public box (R1) I can see= the=20 packets (using tcpdump) leave the firewall with the redirected address, t= hey=20 arrive at R1 and R1 responds to the redirected address (RA). The packets = NEVER=20 return to the firewall. If I traceroute from R1 to RA it stops at the fir= ewall=20 ISP's routers. If I traceroute from P1 to R1 I get to the inside NIC of t= he=20 firewall and no more. Here are my rules, .conf files, even the part I added to GENERIC and reco= mpiled. (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=3D"NO" gateway_enable=3D"YES" sshd_enable=3D"YES" inetd_enable=3D"YES" ############################################################## ### Network configuration sub-section ###################### ############################################################## ### Basic network and firewall/security options: ### hostname=3D"TEMfw3" # Set this! firewall_enable=3D"YES" # Set to YES to enable firewall functio= nality firewall_type=3D"OPEN" # Firewall type (see /etc/rc.firewall) firewall_quiet=3D"NO" # Set to YES to suppress rule display firewall_logging=3D"YES" natd_enable=3D"YES" # Enable natd (if firewall_enable =3D=3D= YES). natd_interface=3D"fxp0" # Public interface or IPaddress to use. natd_flags=3D"-f /etc/natd.conf" network_interfaces=3D"auto" # List of network interfaces (or "auto"= ). ifconfig_lo0=3D"inet 127.0.0.1" # default loopback device configuration= =2E ifconfig_fxp0=3D"inet 216.208.171.XXX netmask 255.255.255.224" ifconfig_fxp1=3D"inet 10.150.0.241 netmask 255.255.255.0" # named_enable=3D"YES" # Run named, the DNS server (or NO). defaultrouter=3D"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= =3Dopen # 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 ker= nel # 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 firewall= s # 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=3D100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by defa= ult 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. Thi= s # prevents nmap et al. from identifying the TCP/IP stack, but breaks supp= ort # for RFC1644 extensions and is not recommended for web servers. # # TCP_RESTRICT_RST adds support for blocking the emission of TCP RST pack= ets. # This is useful on systems which are exposed to SYN floods (e.g. IRC ser= vers) # 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 bloc= king=20 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=20 > redirect. > I'm guessing it's something in the firewall (but its the same as the 3.= 4 too)=20 > I'd love to be able to see whats happening as the rules process How How= =20 How ??? > Can you sense I'm desperate here ? Thanks. John... >=20 > _______________________________________________________________________= ____ > Visit http://www.visto.com/info, your free web-based communications cen= ter. > Visto.com. Life on the Dot. >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message >=20 >=20 _________________________________________________________________________= __ Visit http://www.visto.com/info, your free web-based communications cente= r. 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>