Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 Dec 1999 20:11:02 +0100
From:      Roelof Osinga <roelof@nisser.com>
To:        mw@freibergnet.de
Cc:        FreeBSD Stable <freebsd-stable@FreeBSD.ORG>
Subject:   Re: ifpw forwarding problem
Message-ID:  <384FFEC6.276F4A1E@nisser.com>
References:  <XFMail.991209101540.mw@freibergnet.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Martin Welk wrote:
> 
> As I understood it, you tell natd the interface it's going to work on for
> the purpose that it get's is (probably dynamic) IP address from this
> interface (the IP address it should use for translated packets).

You can either give it the interface or its IP address. In my case they're
equal since I've got a static IP address.

> You still have to pass the packets from the IP firewall to natd by divert
> rules in the firewall ruleset.

Did too! <g>. I'll paste the configs at the end.

> Take care at the spelling. I'm not sure about how tolerant natd is in
> reading the options from a config file, they are slightly different.
> My example is correct and the option is really called "deny_incoming"
> (with the value "no").

Not very. However, I was referring to:

  ... actioned.  If no other action can be made, and if
  -deny_incoming is not specified, the packet is delivered to
  the local machine and port as specified in the packet.

From which I've gathered that deny incoming is not the default. As for
the options, the best source is the error output.

> You need this if you are going to setup rules for a transparent proxy,
> but with redirect_address the packet should arrive with the original
> address at the host in the internal network.

When it works I'll see if it does. Doesn't get mentioned in the man
page whereas it does for proxe_rule.

> use_sockets yes
> same_ports
> redirect_port ...

I ended up by looking at the error output for hints and just
fiddling till it got accepted.

> Argh! You're right, from the internal network I can't access the host with
> it's external address. The same bug here! (This machines offers some web
> services and FTP via NATD to the outside and obviously nobody tried to use
> these services from our internal network :-) )

I'm not sure. I currently run the ports/net/bounce program. That
listens to the external interface and redirects traffic from the
inside. But presumably it does not do it transparently.

> Woah! Never really experienced such trouble.

Unfortunately I did. Gone now that I reverted to the pre-FORWARD
kernel.

> options IPFIREWALL
> 
> All except those marked with * are running on our primary server that doesn
> NAT for the internal network, the others are in my desktop machine's kernel.
> 
> Both run rock-stable with 3.3-STABLE.

It didn't crash or anything. Networking just became erratic. Things (TCP/IP
things, that is) stopped. Had to kill natd and restart it to get it
going again. Lost telnet en news sessions. Webbrowsers stopped browsing.
Things like that.

I believe it had been running for some 75 days flawlessly before I
put in that option. It occurs in conjunction with natd since I can't
remember those effects when I was fiddling with ipfw in that kernel.

> Did you include IPDIVERT?

Oh yes, see below.

> No, it doesn't. I usually kill it before (re-) starting it. If this
> behaviour has changed, I haven't noticed.

It hasn't. I looked at the source. SIGHUP signals a change in IP address
or something. It only handles SIGTERM and SIGHUP.

> (I made the experience that in some circumstances starting a new natd after
> killing the older one something didn't work properly anymore, especially on
> a machine here with six Ethernet interfaces and three natd's running
> parallel. I had to reboot it after doing very heavy changes :-) )

Same thing happens with but two NICs <g>. Bit bothersome in that they
don't always seem to stay dead when you kill them. Maybe this was the
cause for that erratic behavior and GOTCHA! in that you evidently
also have experienced erratic behavior ;). I blame the combination with
IPFIREWALL_FORWARD. It's not the first time I've fiddled with natd, but
it *is* the first time I've experienced such behaviour.

> Which version of FreeBSD are you running?

OK, here it comes. A fresh set of data. This is how it is *now*. Thus
with FORWARD disabled. Some testscripts are at the end. Maybe you
can spot the error, I sure can't.

Roelof

nisser:~$ uname -a
FreeBSD nisser.com 3.3-STABLE FreeBSD 3.3-STABLE #12: Wed Dec  8 08:24:55 CET
1999     root@nisser.com:/usr/src/sys/compile/FORSETI  i386

nisser:~$ grep IP /usr/src/sys/i386/conf/FORSETI
#options        IPX                     #IPX/SPX communications protocols
options         IPFIREWALL              #firewall
#options         IPFIREWALL_VERBOSE      #print information about
#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                #kernel ipfilter support
#options         IPFILTER_LOG            #ipfilter logging
#options        IPFILTER_LKM            #kernel support for ip_fil.o LKM

nisser:~$ ifconfig -a
ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.0.0.55 netmask 0xffffff00 broadcast 10.0.0.255
        ether 00:60:97:14:31:a7
ep1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 212.187.0.39 netmask 0xfffff800 broadcast 212.187.7.255
        inet 194.134.130.170 netmask 0xffffffff broadcast 194.134.130.170
        ether 00:60:97:e4:98:db
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000

nisser:~$ cat /etc/rc.conf | grep -v ^#

moused_type="mousesystems"
moused_enable="YES"
gateway_enable="YES"
network_interfaces="ep0 ep1 lo0"
ifconfig_ep0="inet 10.0.0.55 netmask 255.255.255.0"
ifconfig_ep1="inet 212.187.0.39 netmask 255.255.248.0"
ifconfig_ep1_alias0="inet 194.134.130.170 netmask 255.255.255.255"
defaultrouter="212.187.0.1"
hostname="nisser.com"
saver="blank"
blanktime="300"
keyrate="fast"
ntpdate_flags="ntp0.nl.net"
ntpdate_enable="YES"
named_enable="YES"

nisser:~$ cat /etc/rc.conf.local | grep -v ^#
firewall_enable=YES
firewall_type=open
natd_enable=YES
natd_interface=ep1
natd_flags=-f /etc/natd.conf

nisser:~$ cat /etc/natd.conf
# as used in rc.conf.local
use_sockets yes
same_ports
#redirect_port tcp 212.187.0.39:8080 10.0.0.3:80
#proxy_rule type encode_ip_hdr port 8080 server 10.0.0.3:80

nisser:~# ipfw list
00100 divert 8668 ip from any to any via ep1
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
01000 deny tcp from any to any 23,143,110,79,111 in recv ep1
01000 deny tcp from any to any 5800,5801,5802,5900,5901,5902 in recv ep1
65000 allow ip from any to any
65535 deny ip from any to any

nisser:~$ cat /root/bin/locHans
ipfw add 2000 fwd 10.0.0.3,80 tcp from any to 10.0.0.55 8080 in via ep0

nisser:~$ cat /root/bin/redirHans
natd -n ep1 -use_sockets -same_ports -redirect_port tcp 212.187.0.39:8080
10.0.0.3:80

-- 
Home is where the (@) http://eboa.com/ is.
Telekabel home http://nisser.com/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?384FFEC6.276F4A1E>