Hey everyone,
I have setup my bering 1.1 firewall with 3 NICs, one for external (eth0) and the other two for a couple of small Windows Workgroups. Here's the setup for the internal interfaces:
eth1 = wkgrp1 (192.168.1.0/24) eth2 = wkgrp2 (192.168.2.0/24)
This seems to be working okay. I can get out from both subnets, resolv names with dnscache, etc; but I can't see a host from one subnet to the other. In other words, if I ping a host on wkgrp2 from a host on wkgrp1, I get a "destination port unreachable" response. However, if I ping 192.168.2.254 from a host on wkgrp1, or 192.168.1.254 from a host on wkgrp2, I get a response.
That the two things act differently is no surprise, since iptables and SHorewall process them very differently. The first involves the LEAF router in actual routing ... a task that involves the FORWARD chain, and many user-defined chains, of the filter table. The second does not route (since 192.168.2.254 is one of the router's own addresses) ... so it involves the INPUT and OUTOUT chains of the filter table.
What actual host(s) have you been trying to ping? Did you try it before generating the output you posted? I ask because if you work through the FORWARD chain references, packets from eth1 to eth2 should end up at the loc2loc chain. You report it as follows:
Chain loc2loc (4 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.18 state NEW tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.18 state NEW tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 state NEW tcp dpt:22
52 5280 all2all all -- * * 0.0.0.0/0 0.0.0.0/0
Nothing in this chain provides for forwarding pings ... an icmp type ... from one LAN to the other. NEW tcp packets will pass on to the newnotsyn chain, which simply DROPs them. Even NEW packets to port 80 or 22 will hit the newnotsun rule before the rules specific to them, so they too should be DROPped.
All ICMP (and UDP) packets hit the last rule, which does nothing, so they return to wherever they came from, and so probably hit a DENY rule or policy somewhere else in the table (I didn't trace it that far). And this is the only rule that reports a non-zero packet count ... so if you did generate this listing after trying a ping, that count reinforces my reading of this ruleset.
I may of course have misread the rule sequence ... Shorewall sets up fairly intricate tables and rules ... and if I did, please accept my apologies. If I didn't, though, this is the cause of your problem.
[detailed diagnostics deleted here]In shorewall, didn't define an additional zone for the second subnet, just adding it to the existing loc subnet.
The following is the output from...
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ------------------------------------------------------------------------ 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
