Hi,
I have a setup problem with Shorewall 4.0.6, which I can''t figure out
why
it is not working:
I want to install a fireall with 2 extra interfaces :
- My serv ("dmz") zone is a /28 subnet behind eth1, with a small
number of SUN
servers (IPs between ABC.DEF.75.1 and .13), one of which is a DHCP server for
the 75 subnet.
- The loc zone are PCs in the 75 subnet behind eth2 with IPs between
ABC.DEF.75.17 and .253
- The fw zone is the firewall itself (SuSE 10.2) (eth0)
The setup of the network cards is:
eth0 eth1 (for zone serv) eth2 (for zone loc)
IP: ABC.DEF.70.201 ABC.DEF.75.14 ABC.DEF.75.254
HN: pcfw0 (prompt) (pcfw0) (prompt) (pcfw0) (prompt)
SM: 255.255.255.0 255.255.255.240 255.255.255.0
GA: ABC.DEF.70.254 ABC.DEF.70.254 ABC.DEF.70.254
BA: ABC.DEF.70.255 ABC.DEF.75.15 ABC.DEF.75.255
NS1: ABC.DEF.254.100 ABC.DEF.254.100 ABC.DEF.254.100
NS2: ABC.DEF.254.101 ABC.DEF.254.101 ABC.DEF.254.101
NS3: ABD.XYZ.254.100 ABD.XYZ.254.100 ABD.XYZ.254.100
/etc/shorewall/zones
fw firewall
net ipv4
loc ipv4
serv ipv4
/etc/shorewall/interfaces
net eth0 detect proxyarp,tcpflags,routefilter,nosmurfs,logmartians,norfc1918
serv eth1 detect dhcp
loc eth2 detect dhcp,tcpflags,nosmurfs,blacklist
(no masq file, no proxyarp file)
This is also the setup for a firewall for the same local network
(Shorewall 1.0.3) which works for several years. I just want to replace
the older PC with a newer one ...
I have tested out this setup on that newer PC disconnected from our
local network, using 3 extra PC''s (one to simulate a
''serv'' zone PC, 75.10,
one for a ''loc'' zone PC, 75.121, one for a
''net'' zone PC, 70.200.
I checked out onnections between many different zone combinations, all
behaved as wanted and expected in the test setup.
When I put the new firewall in out real network, NOT a single connection
works, pings report Unreachable, or No route. (?)
The output of netstat -nr is:
Destination Gateway Genmask Flags MSS Window irtt Iface
ABC.DEF.75.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
ABC.DEF.75.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
ABC.DEF.70.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 ABC.DEF.70.254 0.0.0.0 UG 0 0 0 eth0
In /var/log/firewall I get DROP and REJECT messages for connections with
also should be dropped or rejected according to my rules en policy setup.
For connections that should work (but don''t), I do not get a DROP or
REJECT message..
In /var/log/messages however there are a lot of strange messages
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.230 on eth0
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.145 on eth0
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.100 on eth0
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.38 on eth0
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.87 on eth0
kernel martian source ABC.DEF.254.100 from ABC.DEF.75.188 on eth0
(the IPs on the right hand side are those of PCs currently in use on
our local network)
why isn''t is working???
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Pieter Donche wrote:> > why isn''t is working??? >Do you have two of the interfaces connected to the same HUB/Switch?? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Certainly not (I saw it in the doc files that this was a common cause...) The ''net'' interface is connected to a wall outlet to the 70-subnet, the ''loc'' inerface to a wall outled to the 75-subnet and the ''serv'' outlet to a CISCO switch with the servers. These are the cables which are used to the ''old'' firewall, and which I plugged in into the new firewall (and quickly back to the old, since nothing connected to nothing :-) ). \_______________ / Pieter Donche \____________________________________________ | ITC Manager e-mail Pieter.Donche@ua.ac.be \ | Dept. Mathem. & Computer Science, University of Antwerp | | (UA) Middelheimlaan 1, B 2020 Antwerpen, BELGIUM (EU) | | room G1.16, tel +32 03.265.3870, fax +32 03.265.3777 | |____________________________________________________________| On Mon, 25 Feb 2008, Tom Eastep wrote:> Pieter Donche wrote: > >> >> why isn''t is working??? >> > > Do you have two of the interfaces connected to the same HUB/Switch?? > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > >------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Pieter Donche wrote:>I want to install a fireall with 2 extra interfaces : > >- My serv ("dmz") zone is a /28 subnet behind eth1, with a small number of SUN >servers (IPs between ABC.DEF.75.1 and .13), one of which is a DHCP server for >the 75 subnet. >- The loc zone are PCs in the 75 subnet behind eth2 with IPs between >ABC.DEF.75.17 and .253 >- The fw zone is the firewall itself (SuSE 10.2) (eth0) > > >The setup of the network cards is: > eth0 eth1 (for zone serv) eth2 (for zone loc) >IP: ABC.DEF.70.201 ABC.DEF.75.14 ABC.DEF.75.254 >HN: pcfw0 (prompt) (pcfw0) (prompt) (pcfw0) (prompt) >SM: 255.255.255.0 255.255.255.240 255.255.255.0 >GA: ABC.DEF.70.254 ABC.DEF.70.254 ABC.DEF.70.254 >BA: ABC.DEF.70.255 ABC.DEF.75.15 ABC.DEF.75.255You are aware that this is not a valid IP configuration aren''t you ? ABC.DEF.75.0/28 (serv) is a subnet of ABC.DEF.75..0/24 (loc), and so you have overlapping address spaces (eg, ABC.DEF.75..1 is valid on two networks) which means that the required routing is ambiguous. Also, ABC.DEF.70.254 is not a valid gateway address for the serv network - it''s not in the subnet. Ditto for the loc network. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 25 Feb 2008, Simon Hobson wrote:> Pieter Donche wrote: > >> I want to install a fireall with 2 extra interfaces : >> >> - My serv ("dmz") zone is a /28 subnet behind eth1, with a small number of SUN >> servers (IPs between ABC.DEF.75.1 and .13), one of which is a DHCP server for >> the 75 subnet. >> - The loc zone are PCs in the 75 subnet behind eth2 with IPs between >> ABC.DEF.75.17 and .253 >> - The fw zone is the firewall itself (SuSE 10.2) (eth0) >> >> >> The setup of the network cards is: >> eth0 eth1 (for zone serv) eth2 (for zone loc) >> IP: ABC.DEF.70.201 ABC.DEF.75.14 ABC.DEF.75.254 >> HN: pcfw0 (prompt) (pcfw0) (prompt) (pcfw0) (prompt) >> SM: 255.255.255.0 255.255.255.240 255.255.255.0 >> GA: ABC.DEF.70.254 ABC.DEF.70.254 ABC.DEF.70.254 >> BA: ABC.DEF.70.255 ABC.DEF.75.15 ABC.DEF.75.255 > > You are aware that this is not a valid IP configuration aren''t you ? > > ABC.DEF.75.0/28 (serv) is a subnet of ABC.DEF.75..0/24 (loc), and so > you have overlapping address spaces (eg, ABC.DEF.75..1 is valid on > two networks) which means that the required routing is ambiguous.In the machines in the real serv and loc zone, the settings are: serv: SM: 255.255.255.0 GA: ABD.DEF.75.14 loc: SM: 255.255.255.0 GA: ABD.DEF.75.255 In fact the 75 subnet in not really divided in two subnets, they remain one, but there is only a difference in GATEWAY between the serv machines and the loc machines.> Also, ABC.DEF.70.254 is not a valid gateway address for the serv > network - it''s not in the subnet. Ditto for the loc network.In SuSE 10.2 Linux, whenever I change a Gateway adress for one network interface, is automatically changes for any other network interface in the same thing (as does also when you change the hostname). If I read the netstat -nr tables the routing looks to follow the directions I want. The setup worked for years in Shorewall 1.0.3 and also in my test setup in Shorewall 4.0.6. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Pieter Donche wrote:> On Mon, 25 Feb 2008, Simon Hobson wrote:nge the hostname).> > > If I read the netstat -nr tables the routing looks to follow the directions > I want. > > > The setup worked for years in Shorewall 1.0.3 and also in my test setup > in Shorewall 4.0.6. >Shorewall cannot cause the martian messages you are seeing. Given that we''ve established that you haven''t bridged the interfaces externally, I would next carefully check the cabling. Traffic from your local network is arriving on eth0 -- that means that eth0 is cabled to the local network even though you have defined eth0 as your ''net'' interface. The detection of interfaces is non-deterministic in recent kernels so the distributions have installed measures to insure that the assignment of interface names to NICs is stable. But that should also be checked. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, 26 Feb 2008, Tom Eastep wrote:> Pieter Donche wrote: >> On Mon, 25 Feb 2008, Simon Hobson wrote: > nge the hostname). >> >> >> If I read the netstat -nr tables the routing looks to follow the directions >> I want. >> >> >> The setup worked for years in Shorewall 1.0.3 and also in my test setup >> in Shorewall 4.0.6. >> > > Shorewall cannot cause the martian messages you are seeing. Given that we''ve > established that you haven''t bridged the interfaces externally, I would next > carefully check the cabling. Traffic from your local network is arriving on > eth0 -- that means that eth0 is cabled to the local network even though you > have defined eth0 as your ''net'' interface.Maybe my description was not so clear: I want ABC.DEF.75.* to be behind my firewall (75.1-13 are my servers, 75.16-253 are other PCs in my building), everthing else I consider as ''net'', and this is a campus netwerk ABC.DEF.XXX.YYY, with XXX e.g. 70, 71-74, 76-79, 80, 81, etc... and also the whole rest of the ''Internet''. 143.129.70.201 is the address where everything (either from the campus or from Internet) is routed to if it has a ABC.DEF.75.* destination address. (Sorry, I may have referred to my campus network as my ''local network'', ''local'' was not the appropriate word to use, since in fact it just the opposite of what my ''loc'' zone is...)> The detection of interfaces is non-deterministic in recent kernels so the > distributions have installed measures to insure that the assignment of > interface names to NICs is stable. But that should also be checked.Sorry, this is a bit too high-brow, I am afraid I don''t grasp what you mean.. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Pieter Donche wrote:> On Tue, 26 Feb 2008, Tom Eastep wrote: > >> Pieter Donche wrote: >>> On Mon, 25 Feb 2008, Simon Hobson wrote: >> nge the hostname). >>> >>> If I read the netstat -nr tables the routing looks to follow the directions >>> I want. >>> >>> >>> The setup worked for years in Shorewall 1.0.3 and also in my test setup >>> in Shorewall 4.0.6. >>> >> Shorewall cannot cause the martian messages you are seeing. Given that we''ve >> established that you haven''t bridged the interfaces externally, I would next >> carefully check the cabling. Traffic from your local network is arriving on >> eth0 -- that means that eth0 is cabled to the local network even though you >> have defined eth0 as your ''net'' interface. > > Maybe my description was not so clear: I want ABC.DEF.75.* to be behind > my firewall (75.1-13 are my servers, 75.16-253 are other PCs in my > building), everthing else I consider as ''net'', and this is a campus netwerk > ABC.DEF.XXX.YYY, with XXX e.g. 70, 71-74, 76-79, 80, 81, etc... > and also the whole rest of the ''Internet''. 143.129.70.201 is the address > where everything (either from the campus or from Internet) is routed to if > it has a ABC.DEF.75.* destination address. > > (Sorry, I may have referred to my campus network as my ''local network'', > ''local'' was not the appropriate word to use, since in fact it just > the opposite of what my ''loc'' zone is...) > >> The detection of interfaces is non-deterministic in recent kernels so the >> distributions have installed measures to insure that the assignment of >> interface names to NICs is stable. But that should also be checked. > > Sorry, this is a bit too high-brow, I am afraid I don''t grasp what > you mean..It means that it is possible for the assignment of names to network interfaces may be random and may change every time that you boot. So what is eth0 one time you boot might be eth2 the next time. Recent distributions track the interfaces by MAC address and once all of the interfaces have been detected by the kernel, they are renamed as necessary. This ensures that the same interface will have the name ''eth0'' each time that you boot. This can be a problem if you install a recent kernel on an old distribution and given that you are seeing local traffic arriving on your net interface, it means that you have the local network cabled to eth0. So either the cabling is wrong or the interfaces are changing identities behind your back. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/