2 NIC FW /etc/shorewall/interfaces net1 eth0 detect dhcp,blacklist net2 eth1 detect dhcp,blacklist /etc/shorewall/policy fw net1 ACCEPT info fw net2 ACCEPT info # net1 fw DROP info net2 fw DROP info /etc/shorewall/rules # IMAP # ACCEPT net1 fw tcp 993 ACCEPT net2 fw tcp 993 The thing here is that, I''m considering both net1 and net2 as Internet Enabled interfaces (though it''s really on a local LAN). I want IMAP to only be listening on net2, but if I comment out net1 in the rules file, imap will be filtered. Log messages show this (when I nmap probe it) net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET2_IP <--In from Net1 and not NET2? net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET1_IP I would believe that the above is mainly due to the policy file? But how come everything comes in to the net1 chain and not through the net2 chain? -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 1.5GB RAM 98% Microsoft(tm) Free!! Neuromancer 10:38:53 up 1 day, 23:13, 7 users, load average: 1.18, 0.76, 0.70 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Wednesday 14 September 2005 19:47, Ow Mun Heng wrote:> The thing here is that, I''m considering both net1 and net2 as Internet > Enabled interfaces (though it''s really on a local LAN). > > I want IMAP to only be listening on net2, but if I comment out net1 in > the rules file, imap will be filtered. Log messages show this (when I > nmap probe it) > > net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET2_IP <--In from Net1 and not NET2? > net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET1_IP > > > I would believe that the above is mainly due to the policy file? But how > come everything comes in to the net1 chain and not through the net2 > chain?I assume that the two NICs interface to different ISPs -- if not, TURN ONE OF THEM OFF; you clearly don''t know enough to run that kind of configuration (Hint: *I* have difficulty running that configuration). Otherwise, please read the following: http://www.shorewall.net/FAQ.htm#faq32 http://www.shorewall.net/Shorewall_and_Routing.html If you still can''t solve your problem then please follow the instructions at http://www.shorewall.net/support.htm and supply the information asked for in that article. -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
On Wed, 2005-09-14 at 20:11 -0700, Tom Eastep wrote:> On Wednesday 14 September 2005 19:47, Ow Mun Heng wrote: > > > The thing here is that, I''m considering both net1 and net2 as Internet > > Enabled interfaces (though it''s really on a local LAN). > > > > I want IMAP to only be listening on net2, but if I comment out net1 in > > the rules file, imap will be filtered. Log messages show this (when I > > nmap probe it) > > > > net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET2_IP <--In from Net1 and not NET2? > > net12fw:DROP:IN=eth0 SRC=MY_IP DST=NET1_IP > > > > > > I would believe that the above is mainly due to the policy file? But how > > come everything comes in to the net1 chain and not through the net2 > > chain? > > I assume that the two NICs interface to different ISPs -- if not, TURN ONE OF > THEM OFF; you clearly don''t know enough to run that kind of configuration > (Hint: *I* have difficulty running that configuration).As stated previously, it''s on the same LAN. 2 NICs on the same box using 2 different IPs(both local) eg: eth0 - 192.168.10.57 eth1 - 192.168.10.53 What is intended is nothing of the sort of redundant link/multiple ISP or anything of the sort. It''s just to separate which IP serves what service. In this case, I want IMAP to be listening to net2 and not net1.> > Otherwise, please read the following: > > http://www.shorewall.net/FAQ.htm#faq32 > http://www.shorewall.net/Shorewall_and_Routing.html >I have read through all of those and while I fully understand it, what I don''t understand is why routing would matter. It doesn''t really matter (to me) how it routes out of the box (the 2 NICs both has the same default GW out) $route -n | grep -i ug 0.0.0.0 192.168.10.100 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 192.168.10.100 0.0.0.0 UG 0 0 0 eth0 For the time being, testing it out on my vmware sandbox, it works. (This is basically using the same shorewall configs from the problematic box.) I''ll find out more when I get to the box again.> If you still can''t solve your problem then please follow the instructions at > http://www.shorewall.net/support.htm and supply the information asked for in > that article.shorewall 2.4.1 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.57 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.53 127.0.0.0/8 via 127.0.0.1 dev lo scope link default via 192.168.10.100 dev eth1 default via 192.168.10.100 dev eth0 1: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:04:41:52 brd ff:ff:ff:ff:ff:ff inet 192.168.10.57/24 brd 192.168.10.255 scope global eth0 inet6 fe80::20c:29ff:fe04:4152/64 scope link valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:04:41:5c brd ff:ff:ff:ff:ff:ff inet 192.168.10.53/24 brd 192.168.10.255 scope global eth1 inet6 fe80::20c:29ff:fe04:415c/64 scope link valid_lft forever preferred_lft forever -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 1.5GB RAM 98% Microsoft(tm) Free!! Neuromancer 20:59:37 up 2 days, 9:34, 9 users, load average: 1.55, 1.06, 1.46 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 17:48, Ow Mun Heng wrote:> > > > I assume that the two NICs interface to different ISPs -- if not, TURN > > ONE OF THEM OFF; you clearly don''t know enough to run that kind of > > configuration (Hint: *I* have difficulty running that configuration). > > As stated previously, it''s on the same LAN. 2 NICs on the same box using > 2 different IPs(both local) >Then when you make that work, I truly hope that you will write an article for us to include on the Shorewall documentation. Because your problems almost surely have nothing to due with Shorewall and are hard to solve (trust me, I''ve tried!). I suggest that you investigate the following: a) /proc/sys/net/ipv4/conf/<interface>/arp_ignore -- this is very important in your sort of configuration. Shorewall 3.0 will include inbuilt support for configuring it. b) arpfilter -- I believe that you will need to configure rules using this utility. But it has almost no documentation. c) I''ve been playing with the above two features for over a month in my simulated environment for two ISPs and I still need hourly cron jobs doing ''arping'' to make a config like yours work. And if you don''t understand what ''arping'' does, you need to investigate that too. d) I recommend that you make one ''net'' zone and associate it with both NICs -- it will make things less confusing for you. In short, the problems involved in this configuration are hard to solve and at their root seem to have absolutely nothing to do with Shorewall.> I have read through all of those and while I fully understand it, what I > don''t understand is why routing would matter. It doesn''t really matter > (to me) how it routes out of the box (the 2 NICs both has the same > default GW out)Which only shows how little you understand about the problem and how much you have to learn. The Shorewall documentation is full of warnings not to connect two network interfaces to the same hub/switch -- if the two interfaces are configured on the same IP network, things get even harder because the ''arp_filter'' approach doesn''t work. -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 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
<snip>> I have read through all of those and while I fully understand it, what I > don''t understand is why routing would matter. It doesn''t really matter > (to me) how it routes out of the box (the 2 NICs both has the same > default GW out) > > $route -n | grep -i ug > 0.0.0.0 192.168.10.100 0.0.0.0 UG 0 0 0 eth1 > 0.0.0.0 192.168.10.100 0.0.0.0 UG 0 0 0 eth0 > > For the time being, testing it out on my vmware sandbox, it works. (This > is basically using the same shorewall configs from the problematic box.) > > I''ll find out more when I get to the box again. > > > If you still can''t solve your problem then please follow the instructions at > > http://www.shorewall.net/support.htm and supply the information asked for in > > that article. > > shorewall 2.4.1 > > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.57 > 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.53 > 127.0.0.0/8 via 127.0.0.1 dev lo scope link > default via 192.168.10.100 dev eth1 > default via 192.168.10.100 dev eth0 > > 1: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast > qlen 1000 > link/ether 00:0c:29:04:41:52 brd ff:ff:ff:ff:ff:ff > inet 192.168.10.57/24 brd 192.168.10.255 scope global eth0 > inet6 fe80::20c:29ff:fe04:4152/64 scope link > valid_lft forever preferred_lft forever > 2: eth1: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast > qlen 1000 > link/ether 00:0c:29:04:41:5c brd ff:ff:ff:ff:ff:ff > inet 192.168.10.53/24 brd 192.168.10.255 scope global eth1 > inet6 fe80::20c:29ff:fe04:415c/64 scope link > valid_lft forever preferred_lft forever >I''ve found this to be helpful: http://www.justlinux.com/forum/showthread.php?t=84253 In a nut shell, you need to create routing tables, do policy routing, and turn on arp_filter for the interfaces involved. Jerry> https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 19:00, Jerry Vonau wrote:> > I''ve found this to be helpful: > http://www.justlinux.com/forum/showthread.php?t=84253 > > In a nut shell, you need to create routing tables, do policy routing, and > turn on arp_filter for the interfaces involved. >Thanks Jerry -- I suspect that I tried arp_filter without the proper policy routes in place (remember the early ''loose'' debacle -- turned out to be needed but for a different reason). -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
On Thursday 15 September 2005 18:50, Tom Eastep wrote:> > > I have read through all of those and while I fully understand it, what I > > don''t understand is why routing would matter. It doesn''t really matter > > (to me) how it routes out of the box (the 2 NICs both has the same > > default GW out) > > Which only shows how little you understand about the problem and how much > you have to learn. The Shorewall documentation is full of warnings not to > connect two network interfaces to the same hub/switch -- if the two > interfaces are configured on the same IP network, things get even harder > because the ''arp_filter'' approach doesn''t work.Let me try to summarize everything here and give the OP some pointers. a) Jerry has pointed out that policy routing is essential here to make this work. I agree -- you can set that up using the providers file. b) Either arp_filter or arp_ignore=1 is essential. The arp_filter option is available in most versions of Shorewall and arp_ignore may be set using the Development branch. As Jerry has also pointed out, arp_filter won''t work in your setup without policy routing. c) It is a good idea to run arping in your /etc/shorewall/init script to ensure that the upstream router and other hosts on the network have the correct IP->interface mapping for your two interfaces: arping -U -I $IF1 -c 2 $IP1 > /dev/null arping -U -I $IF2 -c 2 $IP2 > /dev/null Note that some distributions will do this for you when the interface is brought up but if significant time passes between the time that the interfaces are brought up and the when you start Shorewall then hosts on the LAN (including the default gateway) can send ARP who-has requests that can be responded to through the wrong interface. Be sure that you have the correct version of arping that supports the -U command. d) The providers file has nothing to do with redundancy. If one ISP link fails, the system will grind to a halt (see recent posts on the list). The routing principles are the same in your case as in a 2-ISP setup, even if you don''t choose to believe it. e) My problems with the 2-ISP test setup dealt with trying to do Proxy ARP through one of the interfaces. Once I got the two interfaces to not answer ARP requests intended for the other, I started having problem with Proxy ARP. Luckily my upstream router accept gratuitous ARP so I scheduled an ''arping'' each hour to work around the problem. -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