> maybe you should be a bit more specific of what you did and what _exactly_
> gets dropped.
Can do. Here's some more detail on the setup:
key:
beringfw --> Bering 1.0-stable box
fw --> hardware nat/firewall (netgear FR314)
hostA --> a host on the network behind beringfw
(DSL Connection)
|
|
|--------------------|
| PPPoE interface |
| |
| **fw** |
| |
| 192.168.0.1/24 |
|--------------------|
|
|
|--------------------|
| 192.168.0.4/24 |
| |
| **beringfw** |
| |
| 192.168.1.254/24 |
|--------------------|
|
|
|--------------------|
| 192.168.1.11/24 |
| |
| **hostA** |
|--------------------|
I'm using this setup right now while I'm learning about Bering (i.e.,
that's why Bering is still behind another firewall). The behavior that
I'd like to see right now is for hostA to be able to access the internet
by going through both beringfw and fw.
Here's some more information about beringfw:
firewall: -root-
# uname -a
Linux firewall 2.4.18 #1 Sun Nov 10 17:40:20 UTC 2002 i586 unknown
firewall: -root-
# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:24:e4:66:ea brd ff:ff:ff:ff:ff:ff
inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:cc:57:e7:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
Here's what the problem is:
>From the perspective of hostA, I can't connect to the internet. For
illustration, I'll show what happens when hostA tries to ssh to
128.8.129.2.
* hostA sends a packet to 128.8.129.2. This packet goes through beringfw
and is successfully snat'd (i.e., the source address for the packet is now
192.168.0.4).
* This packet travels through fw, and I assume that is working properly
for the purposes of this discussion. This is a valid assumption because
the next thing that I see is a reply from 128.8.129.2 after it goes
through fw. This reply is now destined for 192.168.0.4 (aka beingfw).
When beringfw receives the packet, it drops it, and logs it with the
following message in /var/log/messages:
Jan 20 11:40:49 firewall kernel: Shorewall:man1918:DROP:IN=eth0 OUT=
MAC=00:a0:24:e4:66:ea:00:30:ab:06:6c:9c:08:00 SRC=128.8.129.2
DST=192.168.0.4 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=17230 DF PROTO=TCP
SPT=22 DPT=39534 WINDOW=25920 RES=0x00 ACK SYN URGP=0
The same thing happens when I try to establish any type of connection from
hostA to the internet in this fashion.
Based on the behavior I'm seeing, I would think that there is something
wrong with the firewall ruleset. And this is where I'm confused. I
haven't touched the ruleset since installing bering. It is the default
ruleset included with bering 1.0-stable. You can view my ruleset at the
following URL (it was too long to post here):
http://www.cs.umd.edu/~bdpayne/iptables.rules
Thanks for any help you can provide! If you need more information, let me
know and I will post it.
-bryan
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
