port forwarding: still stuck (long)

[Michael Jinks <michael twopoint com>]

This is the latest in a series of questions posted to various newsgroups
while trying to get port forwarding to work on a masquerading Linux
router.  Please excuse the cross-posting, as my/our efforts to get any
response so far have met with dismal results.  A summary of my own
efforts so far and current status follows, for whatever good it may do
anyone:

Contents:
I.   My Setup
II.  My Goal
III. My Efforts So Far
IV.  Where I Am Now (stuck)

APPENDIX A: original config files



I. My setup:
 
Crude diagram:

[Internet]
  ^
  |
  v
public net 209.64.88.0
  ^
  |
  v
209.64.88.26 <-- public interface of lurch.twopoint.com:"eth1"
|} lurch.twopoint.com
192.168.1.1  <-- private interface of lurch.twopoint.com:"eth0"
  ^
  |
  V
"private" net 192.168.1.0


lurch.twopoint.com masqs all IP connections originating from 192.168.1.0
and destined for 209 or any other subnet. (for output of "route" and
"ipfwadm -l" commands before any adjustments were made, see APPENDIX A
below; ipfwadm rules were generated by me using the dotfile generator.) 
lurch works just fine for what it now does, and has for several months.


II. My Goal

I want to add IP port forwarding features in order to allow selective
inbound connections for public-net-connected hosts; specifically, I want
to allow our employees, while connected to their own ISP's, to check for
mail on a server which lives on the protected net.  [aside: YES I have
to do it this way; ssh or proxying is not an option. :( ]

My thought process for accomplishing this follows:

I don't want all requests coming in to eth1 to be forwarded to the
protected net (almost defeats the purpose of a firewall), so the obvious
solution seems like adding an aliased interface next to eth1, and
"forwarding" selected ports on that interface to interface(s) which live
on the protected net.  For example, on lurch.twopoint.com, add the
interface eth1:0 with address 209.64.88.199, and forward port 25 of
209.64.88.199 to the (internal) interface 192.168.1.4 (also port 25). 
Crude diagram:

  ^                                       ^
  |                                       |
  v              <lurch.twopoint.com>     v
|=(209.64.88.26)==========================(209.64.88.199)====|
|   eth1                                    eth1:0           |
|   permits ack-packets                     forwards port 25 |
|     only inbound                            to 192.168.1.4 |
|   ^                                      ^                 |
|   |                                      |                 |
|===|===============(192.168.1.1/eth0)=====|=================|
    | <-------\                            |
    v         |                            v
192.168.1.0 (all outgoing             |=192.168.1.4/25 (mail only)=|
            requests and their        |===<alice.twopoint.com>=====|
            answers)


Since mail can be a little bit cumbersome to debug, I decided to test
using an interactive service, telnet, so all of my attempts so far have
been directed at port 23 instead of 25, but I assume that any setup
which works successfully for telnet will also work for mail.


III. My Efforts So Far

With that in mind, I followed the instructions at
http://www.ox.compsoc.net/~steve/portforwarding.html (the only source I
can find on Linux port forwarding); here's a synapsis of my steps:

1. Obtained and compiled the ipportfw utility

2. Obtained and compiled kernel version 2.0.35, patched and configured
to include support for ipportfw; installed the new kernel image on my
firewall, and booted it (no problems; functionality seems to be
identical to my old 2.0.34 kernel so far).

3. As a test, ran ipportfw -L; a blank table came back, suggesting that
the kernel patch was successful.

4. Did not adjust ipfwadm rules; the existing ones seemed consistent
with the brief example at the web page; for details of my (more
complicated) setup see APPENDIX A

5. Added eth1:0, with address 209.64.88.199 on lurch; tested by pinging
that address from the _public_ net (success).


6. Added a route for that interface, like so:

[root lurch /root]# route add -host 209.64.88.199 eth1:0
[root lurch /root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
209.64.88.199   *               255.255.255.255 UH    0      0        0
eth1:0
192.168.1.0     *               255.255.255.0   U     0      0        6
eth0
209.64.88.0     *               255.255.255.0   U     0      0       11
eth1
127.0.0.0       *               255.0.0.0       U     0      0        0
lo
default         209.64.88.1     0.0.0.0         UG    0      0        8
eth1



7. Added one ipportfw rule, using this command:

[root lurch /root]# ipportfw -A -t 209.64.88.199/23 -R 192.168.1.4/23

. . . verified like so:


[root lurch /root]# ipportfw -L
Prot Local Addr/Port > Remote Addr/Port                        

TCP 209.64.88.199/23 > 192.168.1.4/23     
                     


According to the web page, at this point I expected to be able to start
on the public net, telnet to 209.64.88.199, and contact our (internal)
192.168.1.4; but telnet just hangs, suggesting that packets are getting
lost somewhere.


IV. Where I Am Now (stuck)

Trying to diagnose my current status has proven confusing.  For example,
tcpdump -i eth1:0 is completely silent, even while I am successfully
pinging that interface's IP address.

My next course of action was to query ipfwadm to trace packet paths
through the system.  Like so:


{packets come in to the telnet port of lurch's external interface}

[root lurch /root]# ipfwadm -I -c -P tcp -S 209.64.88.25 8112 -D
209.64.88.199 23 -W eth1:0 -V 209.64.88.199
packet accepted     

{packets are released from eth1:0 on their way to the internal host}

[root lurch /root]# ipfwadm -O -c -P tcp -S 209.64.88.25 8112 -D
192.168.1.4 23 -W eth1:0 -V 209.64.88.199
packet accepted

{packets allowed onto private interface from public card}

[root lurch /root]# ipfwadm -I -c -P tcp -S 209.64.88.199 23 -D
192.168.1.4 23 -W eth0 -V 192.168.1.1
packet accepted

{packets allowed off the private card on their way to the internal host}

[root lurch /root]# ipfwadm -O -c -P tcp -S 209.64.88.25 8112 -D
192.168.1.4 23 -W eth0 -V 192.168.1.1
packet accepted

Do I need an extra forwarding rule?  I guessed not, since that seems to
be what port forwarding is supposed to do.  There may also be errors or
omissions in my method of tracing packet paths, but to me it looks as if
this should be working, provided packets are being rewritten the way
Port Forwarding says they should be.


Are there more sources of info on this?  Have I left out a step
(something more to route, maybe)?

Any clue why tcpdump doesn't record _anything_ for eth1:0?


Any thoughts or guesses gratefully appreciated.

Cheers,
m




APPENDIX A: output of ipfwadm -Iln, ipfwadm -Oln, ipfwadm -Fln, and
route commands before any adjustments were made:

[root lurch /root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.1.0     *               255.255.255.0   U     0      0        5
eth0
209.64.88.0     *               255.255.255.0   U     0      0        5
eth1
127.0.0.0       *               255.0.0.0       U     0      0        0
lo
default         209.64.88.1     0.0.0.0         UG    0      0        1
eth1


[root lurch /root]# ipfwadm -Iln
IP firewall input rules, default policy: accept
type  prot source               destination          ports
deny  all  127.0.0.0/8          0.0.0.0/0            n/a
deny  all  192.168.1.0/24       0.0.0.0/0            n/a
deny  all  10.0.0.0/8           0.0.0.0/0            n/a
deny  all  0.0.0.0/0            10.0.0.0/8           n/a
deny  all  172.16.0.0/12        0.0.0.0/0            n/a
deny  all  0.0.0.0/0            172.16.0.0/12        n/a
deny  all  192.168.0.0/16       0.0.0.0/0            n/a
deny  all  0.0.0.0/0            192.168.0.0/16       n/a
acc   tcp  0.0.0.0/0            209.64.88.26         1:65535 -> *
acc   tcp  0.0.0.0/0            209.64.88.26         20 -> 1024:65535
acc   udp  0.0.0.0/0            209.64.88.26         53 -> *
acc   tcp  0.0.0.0/0            209.64.88.26         * -> 25
deny  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
deny  udp  0.0.0.0/0            0.0.0.0/0            * -> *


[root lurch /root]# ipfwadm -Oln
IP firewall output rules, default policy: accept
type  prot source               destination          ports
rej   all  10.0.0.0/8           0.0.0.0/0            n/a
rej   all  0.0.0.0/0            10.0.0.0/8           n/a
rej   all  172.16.0.0/12        0.0.0.0/0            n/a
rej   all  0.0.0.0/0            172.16.0.0/12        n/a
rej   all  192.168.0.0/16       0.0.0.0/0            n/a
rej   all  0.0.0.0/0            192.168.0.0/16       n/a
acc   tcp  209.64.88.26         0.0.0.0/0            * -> 1:65535
acc   tcp  209.64.88.26         0.0.0.0/0            1024:65535 -> 20
acc   udp  209.64.88.26         0.0.0.0/0            * -> 53
acc   udp  209.64.88.26         0.0.0.0/0            * -> 33434:33523
rej   tcp  0.0.0.0/0            0.0.0.0/0            * -> *
rej   udp  0.0.0.0/0            0.0.0.0/0            * -> *


[root lurch /root]# ipfwadm -Fln
IP firewall forward rules, default policy: deny
type  prot source               destination          ports
acc   all  192.168.1.0/24       192.168.1.0/24       n/a
rej   all  192.168.1.0/24       192.168.1.0/24       n/a
rej   all  192.168.1.0/24       10.0.0.0/8           n/a
rej   all  192.168.1.0/24       172.16.0.0/12        n/a
rej   all  192.168.1.0/24       192.168.0.0/16       n/a
acc/m all  192.168.1.0/24       0.0.0.0/0            n/a