All of my secondary interfaces (to recognize the full block of IPs) are
defined like this...
auto eth0:209
iface eth0:209 inet static
address 216.87.84.209
netmask 255.255.255.224
broadcast 216.87.84.255
network 216.87.84.0
gateway 216.87.84.208
However I've noticed the large number of default routes present when I
do a route command, but never thought anything of it. As I said before,
the thing that really puzzles me is that the setup for routing packets
to the other servers in the DMZ appears to be identical, so I don't
understand why this is the only server that seems to be affected.
One more curious bit to add to the mix... I currently have only port 53
defined to route to 10.0.0.203/211. There is no other mention in
shorewall of these IPs. And yet if I stop BIND on that server, I am
still seeing the martian logs. If I change the IP in shorewall to
10.0.0.9, the martian logs immediately follow the change.
If I can't get this figured out soon, I may go ahead and set up
shorewall on each of my DMZ servers, then I can just have the firewall
directly route ALL traffic from specific IP's over to specific servers,
and let the server figure out it's own traffic. If nothing else, it
would probably help reduce the amount of processing the firewall needs
to do.
Tom Eastep wrote:
On 6/17/10 8:50 PM, Jeff Taylor wrote:
I've been running both commands for about an hour, and have NOT seen any
results from the tcdump commands on either nic. Martian logs are
continuing as normal.
Okay, so the martians have undergone NAT prior to routing and have had
their destination address rewritten to 10.0.0.xxx (it is in the routing
step that reverse path filtering is done). The fascinating thing about
the martians is that their source IP address is always one of the
firewall's own addresses. It's a real mystery how such packets are
arriving from outside the firewall.
The only odd thing that I see in the dump is in the main routing table:
Table main:
216.87.95.1 via 216.87.84.208 dev eth0
216.87.84.192/27 dev eth0 proto kernel scope link src 216.87.84.210
173.160.58.0/24 dev eth4 proto kernel scope link src 173.160.58.202
10.0.0.0/16 dev eth1 proto kernel scope link src 10.0.0.254
10.20.0.0/16 dev eth3 proto kernel scope link src 10.20.0.254
10.10.0.0/16 dev eth2 proto kernel scope link src 10.10.0.254
10.250.0.0/16 dev eth5 proto kernel scope link src 10.250.0.254
default
nexthop via 216.87.84.208 dev eth0 weight 1
nexthop via 173.160.58.206 dev eth4 weight 2
default via 173.160.58.206 dev eth4 src 173.160.58.205 metric 100
default via 173.160.58.206 dev eth4 src 173.160.58.204 metric 100
default via 173.160.58.206 dev eth4 src 173.160.58.203 metric 100
default via 173.160.58.206 dev eth4 src 173.160.58.201 metric 100
default via 216.87.84.208 dev eth0 src 216.87.84.214 metric 100
default via 216.87.84.208 dev eth0 src 216.87.84.212 metric 100
default via 216.87.84.208 dev eth0 src 216.87.84.211 metric 100
default via 216.87.84.208 dev eth0 src 216.87.84.209 metric 100
default via 173.160.58.206 dev eth4 metric 100
default via 216.87.84.208 dev eth0 metric 100
Note all of the silly default routes with metric 100. It appears that
you have included a 'default' specification in /etc/network/interfaces
as part of the stanza of each secondary IP address. I wouldn't think
that would cause what you are seeing though.
-Tom
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
