Hi,
Thanks to Juanjon Ciarlante. He help me to turn on the kernel debug log
to trace the problem.
>From the log file, I found that the 3rd packet reset and the destinate
host unable to successfully
shot UDP packet back to source host. The fail reason was because I
already had one firewall which is Linux 2.0.33 and most of the hosts
inside the firewall was gated to 192.168.1.254(only one machine was
gated to 192.168.1.91). At this time, I add-on another new firewall for
testing which is Linux 2.1.126.
Althought MASQ work well on new firewall, but, the inside host is not
really gated to 192.168.1.91(new firewall). Therefore, make the port
forwarding looks like malfunction.
Anyway, the port forwarding function is now work fine here.
203.75.nn.68 192.168.1.254
+--------------------------------+
203.75.nn.x --+-->| Linux 2.0.33 |-->+--->192.168.1.x
| +--------------------------------+ |
| |
| 203.75.nn.90 192.168.1.91 |
| +--------------------------------+ |
+-->| Linux 2.1.126 |-->+
+--------------------------------+
Also, thanks to Fuzzy Fox for his comments. I agree that the firewall
should be set up more tightly and now I really apply it.
Fuzzy Fox wrote:
>
> Ping Lee <[EMAIL PROTECTED]> wrote:
> >
> > ipchains -F input
> > ipchains -F output
> > ipchains -F forward
> > ipchains -P input ACCEPT
> > ipchains -P output ACCEPT
> > ipchains -P forward MASQ
>
> I think you will find your problem here. Your input/output rules are
> sufficient (except from a security standpoint, of course), but it is not
> a good idea to make MASQ the default policy. This means that any packet
> coming into your firewall will be masqueraded, whether it's traveling in
> from the Internet, or out from the local LAN. You really only want to
> masquerade from the local LAN, outward.
>
> I suggest that you set up more specific rules to masquerade only packets
> traveling in specific directions (say, sourced from one of your local
> networks, and destined for a non-local, non-routable network).
>
> If I recall, you did say that you are trying to bridge two networks.
> Can they route between one another, or is the masquerade required in
> order to get them to talk to each other? If so, you'll need to add a
> couple of masquerade rules there, too.
>
> It is bad, though, when a box on your local network can spoof other
> boxes by making your masq box appear to be the source of the connection.
> That is more of a security issue, though also a performance issue, since
> traffic might travel the network multiple times.
>
> > But, I can not successfully setup the port-forwarding to redirect some
> > ports(eg. telnet, ftp, www, etc.) from external world to internal
> > net.(from 0/0 to 192.168.1.x)
>
> I'm not really sure at what level port-forwarding occurs. It might be
> that the packet is "picked up" by your default forwarding rule before it
> gets noticed at the port-forwarding. If your masq setup were more
> tightly controlled, this might not be an issue anymore.
>
> > 15:06:33.059762 SRC.4262 > DST.telnet: S 1027008000:1027008000(0) win
> > 61440 <mss 1460>
> > 15:06:33.060666 DST.telnet > SRC.4262: S 806912000:806912000(0) ack
> > 1027008001 win 61440 <mss 512>
> > 15:06:33.061919 SRC.4262 > DST.telnet: R 1027008001:1027008001(0) win 0
> > .....(REPEAT 4 TIMES)
>
> When the connection is trying to open, what does "ipchains -M -L" tell
> you? You should see a masquerade tunnel created for this connection.
> Is it possible that a second masq tunnel is being created for the reply
> ACK, because of the loose masquerade policy?
>
> I'm just guessing, unfortunately.
>
Ping Lee
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
