So I have a server hosted at Serverbeach (Debian Etch). This box has an IP (eth0) in one subnet (192.168.0.2 netmask 255.255.255.128). I have also been granted 3 extra IPs (eth0:0, eth0:1, eth0:2) in another subnet (192.168.1.2 through 192.168.1.4 netmask 255.255.255.0). I have read through the Aliased IP docs, but still can''t seem to get it to work. My goal is to have EACH of the IPs be able to be able controlled (e.g. I would like each IP to have its own zone). Here is what I have setup: zones: fw firewall net0 ipv4 net1 ipv4 net2 ipv4 net3 ipv4 interfaces: - eth0 192.168.0.128,192.168.1.255 norfc1918,routefilter,dhcp,tcpflags,logmartians,nosmurfs (NOTE: I tried without any options) hosts: net0 eth0:192.168.0.2 net1 eth0:192.168.1.2 net2 eth0:192.168.1.3 net3 eth0:192.168.1.4 policy: $FW net0 ACCEPT net0 $FW ACCEPT net0 all ACCEPT $FW net1 ACCEPT net1 $FW ACCEPT net1 all ACCEPT $FW net2 ACCEPT net2 $FW ACCEPT net2 all ACCEPT $FW net3 ACCEPT net3 $FW ACCEPT net3 all ACCEPT all all REJECT info There are no rules set since the policy is set to ACCEPT for all for testing purposes. If I startup shorewall with (safe-start and this config) my server drops off the earth for 60 seconds. Does anyone see anything wrong with this config? Thanks in advance. Let me know if you need any other info, but everything else on the box shorewall related is default config (basically empty). -Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 05:21:15PM -0500, Eric Faden wrote:> So I have a server hosted at Serverbeach (Debian Etch). This box has an > IP (eth0) in one subnet (192.168.0.2 netmask 255.255.255.128). I have > also been granted 3 extra IPs (eth0:0, eth0:1, eth0:2) in another subnet > (192.168.1.2 through 192.168.1.4 netmask 255.255.255.0). I have read > through the Aliased IP docs, but still can''t seem to get it to work. My > goal is to have EACH of the IPs be able to be able controlled (e.g. I > would like each IP to have its own zone). Here is what I have setup: > > zones: > fw firewall > net0 ipv4 > net1 ipv4 > net2 ipv4 > net3 ipv4 >Why do you need a seperate zone for each IP?> > interfaces: > - eth0 192.168.0.128,192.168.1.255 > norfc1918,routefilter,dhcp,tcpflags,logmartians,nosmurfs (NOTE: I > tried without any options) >I don''t think that you realistically have an interface with an RFC1918 address and then give it the norfc1918 option.> hosts: > net0 eth0:192.168.0.2 > net1 eth0:192.168.1.2 > net2 eth0:192.168.1.3 > net3 eth0:192.168.1.4 >If you don''t insist on having a different zone for each IP, then you don''t need a hosts file. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, 2007-11-21 at 17:21 -0500, Eric Faden wrote:> So I have a server hosted at Serverbeach (Debian Etch). This box has an > IP (eth0) in one subnet (192.168.0.2 netmask 255.255.255.128). I have > also been granted 3 extra IPs (eth0:0, eth0:1, eth0:2) in another subnet > (192.168.1.2 through 192.168.1.4 netmask 255.255.255.0). I have read > through the Aliased IP docs, but still can''t seem to get it to work. My > goal is to have EACH of the IPs be able to be able controlled (e.g. I > would like each IP to have its own zone).That isn''t possible. And besides that, it is meaningless because these IP addresses are all _inside_ your firewall so they are essential parts of the firewall zone. The Aliased IP doc is complete -- there are no other undocumented silly things you can do with multiple IP addresses on a single interface.> Here is what I have setup: > > zones: > fw firewall > net0 ipv4 > net1 ipv4 > net2 ipv4 > net3 ipv4 > > > interfaces: > - eth0 192.168.0.128,192.168.1.255 > norfc1918,routefilter,dhcp,tcpflags,logmartians,nosmurfs (NOTE: I > tried without any options) > > hosts: > net0 eth0:192.168.0.2 > net1 eth0:192.168.1.2 > net2 eth0:192.168.1.3 > net3 eth0:192.168.1.4The above is unworkable. It defines net0 as the single host with IP address 192.168.0.2 connected through eth0. Given that 192.168.0.2 is an address on the firewall and not one outside of the firewall, the zone is essentially empty. Same for the other netX zones you have defined.> > policy: > $FW net0 ACCEPT > net0 $FW ACCEPT > net0 all ACCEPT > $FW net1 ACCEPT > net1 $FW ACCEPT > net1 all ACCEPT > $FW net2 ACCEPT > net2 $FW ACCEPT > net2 all ACCEPT > $FW net3 ACCEPT > net3 $FW ACCEPT > net3 all ACCEPT > all all REJECT info > > > There are no rules set since the policy is set to ACCEPT for all for > testing purposes. If I startup shorewall with (safe-start and this > config) my server drops off the earth for 60 seconds. Does anyone see > anything wrong with this config?Yes -- you are trying to do something that cannot be done with Shorewall. -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 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, 2007-11-21 at 14:49 -0800, Tom Eastep wrote:> On Wed, 2007-11-21 at 17:21 -0500, Eric Faden wrote: > > So I have a server hosted at Serverbeach (Debian Etch). This box has an > > IP (eth0) in one subnet (192.168.0.2 netmask 255.255.255.128). I have > > also been granted 3 extra IPs (eth0:0, eth0:1, eth0:2) in another subnet > > (192.168.1.2 through 192.168.1.4 netmask 255.255.255.0). I have read > > through the Aliased IP docs, but still can''t seem to get it to work. My > > goal is to have EACH of the IPs be able to be able controlled (e.g. I > > would like each IP to have its own zone). > > That isn''t possible. And besides that, it is meaningless because these > IP addresses are all _inside_ your firewall so they are essential parts > of the firewall zone. The Aliased IP doc is complete -- there are no > other undocumented silly things you can do with multiple IP addresses on > a single interface.I guess it makes sense in a way. You want a zone that is defined as "all external hosts that communicate through a particular firewall interface using a particular address on that interface". You are not the first to want to do something like that so it may be something to consider for Shorewall 4.2. It would require some sort of magic in the hosts file such as: net0 eth0:0.0.0.0/0 address=<local ip address>, ... I''ll see what I can come up with. -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 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, 2007-11-21 at 15:42 -0800, Tom Eastep wrote:> > I guess it makes sense in a way. You want a zone that is defined as "all > external hosts that communicate through a particular firewall interface > using a particular address on that interface". You are not the first to > want to do something like that so it may be something to consider for > Shorewall 4.2. > > It would require some sort of magic in the hosts file such as: > > net0 eth0:0.0.0.0/0 address=<local ip address>, ... > > I''ll see what I can come up with.This idea quickly turns sticky. A zone as contemplated, seems of little practical use except for fw <-> zone rules and policies. Suppose I have: /etc/shorewall/zones: fw firewall net1 ipv4 net2 ipv4 loc ipv4 /etc/shorewall/interfaces: - eth0 ... loc eth1 ... /etc/shorewall/hosts: net1 eth0:0.0.0.0/0 local=206.124.146.176,... net2 eth0:0.0.0.0/0 local=206.124.146.177,... Consider this rule: DNAT net1 loc:192.168.1.4 tcp 80 That would appear to require that the ORIGINAL DEST column default to 206.124.146.176 because that is the local address of net1. If fact, that seems like the only possible legitimate value for ORIGINAL DEST as well. What does this rule mean? ACCEPT net1 loc all Or this one? ACCEPT loc net1 all How is the local address relevant in that rule? Does it mean that all traffic from eth1 through eth0 should be SNATted with the local address of net1? Should the local address simply be ignored? How about this entry in /etc/shorewall/masq? eth0 eth1 206.124.146.177 And how does it impact the previous rule. Does it mean that loc->net1 connections are essentially impossible with those two entries? The way that I would deal with Eric''s problem today would be as follows: /etc/shorewall/params: IP1=206.124.146.176 IP2=206.124.146.177 FW1=fw:206.124.146.176 FW2=fw:206.124.146.177 Then I can have rules: ACCEPT net $FW1 tcp 22 ACCEPT net loc all DNAT net loc:192.168.1.4 tcp 80 - $IP1 and in /etc/shorewall/masq: eth0 eth1 $IP2 And the meaning of each entry is clear and unambiguous. On the other hand, it appears that defining clear and unambiguous semantic behavior for the ''local'' address in a host entry would be difficult. -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 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> On Wed, 2007-11-21 at 15:42 -0800, Tom Eastep wrote: > >> I guess it makes sense in a way. You want a zone that is defined as "all >> external hosts that communicate through a particular firewall interface >> using a particular address on that interface". You are not the first to >> want to do something like that so it may be something to consider for >> Shorewall 4.2. >> >> It would require some sort of magic in the hosts file such as: >> >> net0 eth0:0.0.0.0/0 address=<local ip address>, ... >> >> I''ll see what I can come up with. >> > > This idea quickly turns sticky. A zone as contemplated, seems of little > practical use except for fw <-> zone rules and policies. > > Suppose I have: > > /etc/shorewall/zones: > > fw firewall > net1 ipv4 > net2 ipv4 > loc ipv4 > > /etc/shorewall/interfaces: > > - eth0 ... > loc eth1 ... > > /etc/shorewall/hosts: > > net1 eth0:0.0.0.0/0 local=206.124.146.176,... > net2 eth0:0.0.0.0/0 local=206.124.146.177,... > > Consider this rule: > > DNAT net1 loc:192.168.1.4 tcp 80 > > That would appear to require that the ORIGINAL DEST column default to > 206.124.146.176 because that is the local address of net1. If fact, that > seems like the only possible legitimate value for ORIGINAL DEST as well. > > What does this rule mean? > > ACCEPT net1 loc all > > Or this one? > > ACCEPT loc net1 all > > How is the local address relevant in that rule? Does it mean that all > traffic from eth1 through eth0 should be SNATted with the local address > of net1? Should the local address simply be ignored? > > How about this entry in /etc/shorewall/masq? > > eth0 eth1 206.124.146.177 > > And how does it impact the previous rule. Does it mean that loc->net1 > connections are essentially impossible with those two entries? > > The way that I would deal with Eric''s problem today would be as follows: > > /etc/shorewall/params: > > IP1=206.124.146.176 > IP2=206.124.146.177 > > FW1=fw:206.124.146.176 > FW2=fw:206.124.146.177 > > Then I can have rules: > > ACCEPT net $FW1 tcp 22 > ACCEPT net loc all > DNAT net loc:192.168.1.4 tcp 80 - $IP1 > > and in /etc/shorewall/masq: > > eth0 eth1 $IP2 > > And the meaning of each entry is clear and unambiguous. On the other > hand, it appears that defining clear and unambiguous semantic behavior > for the ''local'' address in a host entry would be difficult. > > -Tom > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >Tom & Roberto: Thanks for the replies. I suppose my main justification for it was to treat each of the interfaces completely independently to allow for individual control to ports by IP, which I understand is a little odd and I''m not even sure it makes sense. After some more thought and reading both of your emails it seems for now my best bet is to follow what Tom wrote in the last email. I think that will work fine for what I am doing and will be the least confusing. For reference what I wound up with is.... zones: fw firewall net ipv4 interfaces: net eth0 detect norfc1918,routefilter,dhcp,tcpflags,logmartians,nosmurfs params: IP0=<eth0 ip> IP1=<eth0:0 ip> IP2=<eth0:1 ip> IP3=<eth0:2 ip> FW0=fw:$IP0 FW1=fw:$IP1 FW2=fw:$IP2 FW3=fw:$IP3 hosts: EMPTY policy: $FW net ACCEPT net $FW DROP info net all DROP info all all REJECT info rules (examples of my test): Ping/ACCEPT net $FW0 Ping/REJECT net $FW SSH/ACCEPT net $FW ACCEPT $FW net icmp That setup correctly accepts pings on IP0, but rejects the rest. If I change the first two to Ping/REJECT net $FW0 Ping/ACCEPT net $FW It rejects on the IP0 and ACCEPTS on the rest. So I suppose that the simplest solution seems to be the best. Thanks all. -Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 11:44:13PM -0500, Eric Faden wrote:> Thanks for the replies. I suppose my main justification for it was to > treat each of the interfaces completely independently to allow for > individual control to ports by IP, which I understand is a little odd > and I''m not even sure it makes sense.It''s certainly a very strange thing to do. Without knowing why you''re doing this it''s hard to be sure, but you might be trying to use NAT to solve a problem that should be solved with routing. The basic problem with what you''re attempting is that it''s insecure in the general case: there''s no guarantee that the hosts connected to this interface will send packets stamped with one IP address and not another, so using different filtering rules for them doesn''t really accomplish anything. In the case where you control the hosts, you would want to be using 802.1q VLANs instead, in which case you''ll get the behaviour you want from shorewall. If you told us why you''re doing all this, we might come up with some more ideas. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/