Its not my syle, but I have had enough. This nonsense of not being able to handle 2 internet connections and process http, https and sendmail is going away. I redid shorewall as you suggested, using tarball not rpm (but yes, I noticed the missing --nodeps in your rpm reminder), and there was no change whatever in the logging output. Because I have to get on with things, I''ll strip out eth1 as a second net connection which will get rid of the martian messages permanently, reinstall Mandrake''s shorewall rpm as it was originally - let it do whatever it feels like doing, however it feels like doing it, and then begin to build a second system to handle the secure connection. What a waste of machinery, but it works! I''ve appreciated your interest, Tom, but 4/5 months of fiddling around with systems has taken a terrible toll, and its time I get into more positive things ..... Sincerely, "George" G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
G. Walsh wrote:> Its not my syle, but I have had enough. This nonsense of not being able > to handle 2 internet connections and process http, https and sendmail is > going away. > > I redid shorewall as you suggested, using tarball not rpm (but yes, I > noticed the missing --nodeps in your rpm reminder), and there was no > change whatever in the logging output.For the record, I did not recommend that you "redo shorewall" -- I offered some suggestions for changes to your config. Since your system wasn''t operational with Shorewall started, _you_ decided to remove the Shorewall rpm and reinsall later rather than simply issuing a "shorewall clear" command. The output of "shorewall status" would have told us why the broadcasts were still getting logged. Here is what should happen: In /usr/share/shorewall/actions.std is the following line: Reject:REJECT This says that the ''Reject'' action should be taken before the REJECT policy is applied (i.e., before REJECT policy log messages are created and before the connection request is rejected). This is the primary purpose of these "common actions" - to rid your log of useless noise. In /usr/share/shorewall/action.Reject is the line: dropBcast The ''dropBcast'' action drops broadcast packets by one of two methods: a) If your kernel/iptables supports the ''pkttype'' match extension, then the dropBcast chain contains exactly two rules (the following output is taken from a Mandrake 10 official system so this is what your dropBcast chain should look like): Chain dropBcast (2 references) pkts bytes target prot opt in out source destination 20 1040 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast The first rule drops all broadcast packets (which is what you are seeing in your logs). b) If your kernel/iptables does not support the ''pkttype'' match extension then the dropBcast chain is built by parsing the output of ip -f inet addr ls Example (obtained by temporarily renaming the ''libipt_pkttype.so'' library): Chain dropBcast (2 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 206.124.146.255 0 0 DROP all -- * * 0.0.0.0/0 10.1.1.255 6251 679K DROP all -- * * 0.0.0.0/0 192.168.1.255 0 0 DROP all -- * * 0.0.0.0/0 192.168.9.255 189 20790 DROP all -- * * 0.0.0.0/0 255.255.255.255 0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/4 To create this example, I configured both the 10.1.1.0/24 and 192.168.1.0/24 networks on the same interface (eth2) to simulate what you have on your eth2. ---- My point here is that "out of the box", Shorewall should silently drop all broadcast packets before applying the "all2all" logging policy; on your system it is not working that way and there is undoubtedly an easily-discoverable reason why it is not working.> > Because I have to get on with things, I''ll strip out eth1 as a second > net connection which will get rid of the martian messages permanently, > reinstall Mandrake''s shorewall rpm as it was originally - let it do > whatever it feels like doing, however it feels like doing it, and then > begin to build a second system to handle the secure connection. What a > waste of machinery, but it works!A simple way to "get rid of martian messages permanently" would be to add this to your /etc/shorewall/init file: for file in /proc/sys/net/ipv4/conf/*/log_martians; do echo 0 > $file done and/or place this in your /etc/sysctl.conf (then restart your network): net.ipv4.conf.all.log_martians=0 The Mandrake "Internet Connection Sharing Wizard" understands how to set up simple two-interface configurations. Given the bizarre IP configuration of your firewall (apparently forced on you by the draconian policies of your ISP), it takes more than Drake''s simple wizard to configure Shorewall for your two internet connection setup.> > I''ve appreciated your interest, Tom, but 4/5 months of fiddling around > with systems has taken a terrible toll, and its time I get into more > positive things .....I want it to be clear in the mailing list archive that you first contacted the Shorewall Users''s mailing list concerning your problem 3 days prior to your "I give up" post. We on the list have not been trying to help solve your problem for 4/5 months but rather for three days. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
PLEASE! I am not suggesting anything negative toward you or the one other party that responded to my post. On the contrary, if you look back at my messages, you''ll find that I have many times expressed my gratitude for your help. I have dealt over these past 4 months with user groups, with apache groups, with the telco - there are in my log over 200 email exchanges and even a dozen snail-mails. The process for ''shutting up'' the martian loggings I have handled; I guess I was more concerned about whether there was something in the networking itself that I was not addressing and therefore setting myself up for future failures. I am in the final stages of taking this sytem from development to initial production, before we go to colo setups. I do NOT want to be a burden, Tom, which is why I suggested it would be best to ''give up''. I don''t give up gracefully, and I certainly wouldn''t give up after 4 days. Four months is another matter. I''m not sure exactly which direction I will go in now. I''ll give it some thought, I really will! Sincerely, George On Sat, 2004-07-10 at 08:00 -0700, Tom Eastep wrote:> G. Walsh wrote: > > Its not my syle, but I have had enough. This nonsense of not being able > > to handle 2 internet connections and process http, https and sendmail is > > going away. > > > > I redid shorewall as you suggested, using tarball not rpm (but yes, I > > noticed the missing --nodeps in your rpm reminder), and there was no > > change whatever in the logging output. > > For the record, I did not recommend that you "redo shorewall" -- I > offered some suggestions for changes to your config. Since your system > wasn''t operational with Shorewall started, _you_ decided to remove the > Shorewall rpm and reinsall later rather than simply issuing a "shorewall > clear" command. > > The output of "shorewall status" would have told us why the broadcasts > were still getting logged. Here is what should happen: > > In /usr/share/shorewall/actions.std is the following line: > > Reject:REJECT > > This says that the ''Reject'' action should be taken before the REJECT > policy is applied (i.e., before REJECT policy log messages are created > and before the connection request is rejected). This is the primary > purpose of these "common actions" - to rid your log of useless noise. > > In /usr/share/shorewall/action.Reject is the line: > > dropBcast > > The ''dropBcast'' action drops broadcast packets by one of two methods: > > a) If your kernel/iptables supports the ''pkttype'' match extension, then > the dropBcast chain contains exactly two rules (the following output is > taken from a Mandrake 10 official system so this is what your dropBcast > chain should look like): > > Chain dropBcast (2 references) > pkts bytes target prot opt in out source > destination > 20 1040 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 PKTTYPE = broadcast > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 PKTTYPE = multicast > > The first rule drops all broadcast packets (which is what you are seeing > in your logs). > > b) If your kernel/iptables does not support the ''pkttype'' match > extension then the dropBcast chain is built by parsing the output of > > ip -f inet addr ls > > Example (obtained by temporarily renaming the ''libipt_pkttype.so'' library): > > Chain dropBcast (2 references) > pkts bytes target prot opt in out source > destination > 0 0 DROP all -- * * 0.0.0.0/0 > 206.124.146.255 > 0 0 DROP all -- * * 0.0.0.0/0 > 10.1.1.255 > 6251 679K DROP all -- * * 0.0.0.0/0 > 192.168.1.255 > 0 0 DROP all -- * * 0.0.0.0/0 > 192.168.9.255 > 189 20790 DROP all -- * * 0.0.0.0/0 > 255.255.255.255 > 0 0 DROP all -- * * 0.0.0.0/0 > 224.0.0.0/4 > > To create this example, I configured both the 10.1.1.0/24 and > 192.168.1.0/24 networks on the same interface (eth2) to simulate what > you have on your eth2. > > ---- > > My point here is that "out of the box", Shorewall should silently drop > all broadcast packets before applying the "all2all" logging policy; on > your system it is not working that way and there is undoubtedly an > easily-discoverable reason why it is not working. > > > > > Because I have to get on with things, I''ll strip out eth1 as a second > > net connection which will get rid of the martian messages permanently, > > reinstall Mandrake''s shorewall rpm as it was originally - let it do > > whatever it feels like doing, however it feels like doing it, and then > > begin to build a second system to handle the secure connection. What a > > waste of machinery, but it works! > > A simple way to "get rid of martian messages permanently" would be to > add this to your /etc/shorewall/init file: > > for file in /proc/sys/net/ipv4/conf/*/log_martians; do > echo 0 > $file > done > > and/or place this in your /etc/sysctl.conf (then restart your network): > > net.ipv4.conf.all.log_martians=0 > > The Mandrake "Internet Connection Sharing Wizard" understands how to set > up simple two-interface configurations. Given the bizarre IP > configuration of your firewall (apparently forced on you by the > draconian policies of your ISP), it takes more than Drake''s simple > wizard to configure Shorewall for your two internet connection setup. > > > > > I''ve appreciated your interest, Tom, but 4/5 months of fiddling around > > with systems has taken a terrible toll, and its time I get into more > > positive things ..... > > I want it to be clear in the mailing list archive that you first > contacted the Shorewall Users''s mailing list concerning your problem 3 > days prior to your "I give up" post. We on the list have not been trying > to help solve your problem for 4/5 months but rather for three days. > > -Tom-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
Jens: Please see my earlier response to Tom. In no way am I unappreciative for what he has tried to do, and I agree with your sentiments. Maybe if I had started with Shorewall, but then I was becoming convinced the problem was elsewhere and I didn''t want to bring my problem to where it did not belong. Sadly, it seems I was correct about this .... George On Sat, 2004-07-10 at 08:16 -0700, Jens wrote:> On Saturday 10 July 2004 08:00, Tom Eastep wrote: > > > I want it to be clear in the mailing list archive that you first > > contacted the Shorewall Users''s mailing list concerning your problem 3 > > days prior to your "I give up" post. We on the list have not been trying > > to help solve your problem for 4/5 months but rather for three days. > > > > -Tom > > And I would like to add that not only do I appreciate Shorewall and what it > does for me but I REALLY appreciate Tom''s continued participation in almost > every thread (how do you find enough time in the day?). > It is very unusual to have this level of support available. > Thanks Tom !! > > Jens > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
G. Walsh wrote:> PLEASE! > > I am not suggesting anything negative toward you or the one other party > that responded to my post. >Sorry if I gave the impression that I took your post personally -- I certainly didn''t. I just didn''t want to leave future readers of the archives with the impression that we had worked on your problem for months and had no clue about what was going on. I''ll be happy to help you in the future whether you are running one Shorewall system or two :-) =Tp, -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hi, Tom: Yes, I can quite understand how you might want to protect your integrity and you have my unconditional support. After extracting myself from helping another lost soul with his Apache2 configuration, I felt kind of ashamed of myself for ''running away'' from my own problemsw, so here is another stab at the darkness. The idea came from your last email discussing what dropBcast should be doing. First, I discovered that some great hand takes it upon himself to overwrite /etc/sysctl.conf, resetting the log_martians equate each time. But if shorewall is started, that overrides. So ..... that problem is done away with. Mandrake, Mandrake!! Less ''magic'', more ''meat''. In the attachment is an extract from /var/sys/syslog showing shorewall data for the 12 lan IPs on eth2 as well as both the eth0 and eth1 network connections. Oh yes, and that last nuisance regarding an invalid ICMP type 3. Then there is the output of iptables -nvL, which I thought you might find of interest. Aside from shorewall status, note its not too happy about icmp either! Anyway, I hope this helps. I''m going to take my young partner to "Last Night at the Proms" at the Cathedral, which will be a great way for both of us to letgo emotionally and have a few laughs as a bonus. Point? No need to rush to get back. I''ve run shorewall ''stop'' to keep the mail channels open in the meantime. Once again, my thanks for your continued interest in this muddle. George On Sat, 2004-07-10 at 13:58 -0700, Tom Eastep wrote:> G. Walsh wrote: > > PLEASE! > > > > I am not suggesting anything negative toward you or the one other party > > that responded to my post. > > > > Sorry if I gave the impression that I took your post personally -- I > certainly didn''t. I just didn''t want to leave future readers of the > archives with the impression that we had worked on your problem for > months and had no clue about what was going on. > > I''ll be happy to help you in the future whether you are running one > Shorewall system or two :-) > > =Tp,-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
G. Walsh wrote:> First, I discovered that some great hand takes it upon himself to > overwrite /etc/sysctl.conf, resetting the log_martians equate each time.Each time what?> But if shorewall is started, that overrides. So ..... that problem is > done away with. Mandrake, Mandrake!! Less ''magic'', more ''meat''.I am inclined to not run Mandrake as a firewall (although I like the folks at Mandrake, I am a MandrakeClub member and I buy licenses for their official releases). Mandrake''s philosophy is to be on the cutting edge of Linux development which is fine for a desktop (which is where I run Drake) but not for a firewall or server. If you want to run a Mandrake Firewall, I recommend that you run MNF (which is also Shorewall-based). I AM NOT SUGGESTING THAT YOU CHANGE YOUR FIREWALL DISTRIBUTION; we don''t need more variables in your situation -- I am simply confirming what you probably already know.> > In the attachment is an extract from /var/sys/syslog showing shorewall > data for the 12 lan IPs on eth2 as well as both the eth0 and eth1 > network connections.From that extract: Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT= MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110 The first thing that we should notice is that the packets are being logged from the ''net2all'' chain. That means that Shorewall is configured with eth2 connected to the ''net'' zone. George -- I''m going to ask you this one more time; WHAT IS CONNECTED TO eth2? If your next post doesn''t make that perfectly clear then *I* am going to give up in frustration. Are there local systems connected there? What firewall services do these systems need access to? What services (if any) do these systems provide to the internet? After 4 days, the only thing that I''ve learned about eth2 is that it is the on-motherboard NIC, it has a slew of IP addresses, those IP addresses are supposedly there because of some policy of your ISP, and it _seems_ that your servers listen on those addresses (again, I''ve tried since your first post to determine where your servers run -- is that a state secret???).> > Oh yes, and that last nuisance regarding an invalid ICMP type 3. > > Then there is the output of iptables -nvL, which I thought you might > find of interest. Aside from shorewall status, note its not too happy > about icmp either!George -- one of the reasons that http://shorewall.net/support.htm says not to post the output of iptables -L (and to post the output of "shorewall status" instead) is that I spent a lot of time designing "shorewall status" to give me the information that I need to solve problems. This is a perfect example. You complain about invalid ICMP type 3''s being generated and the log extract provides the date and time of day when this occurs; unfortunately, I have no clue at what time the iptables counters were last reset so I have no way to relate the output of iptables -L to the log messages. What I want you to do is to follow the instructions at http://shorewall.net/support.htm to the letter (I know that you have sent some of this information before but I need a coherent set of data that I know was captured at the same time). You obviously have problems establishing connections to/through your firewall so the part that begins "This is Important" in bold font is relevant. I''m going to also ask you to make NO changes that I don''t ask you to make -- I am going to need to be able to have confidence that what I''m seeing isn''t the result of unseen changes. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hiya! Just before getting to bed: "each time what" refers to each time Mandrake is rebooted. This particular problem is one I consider ''solved'' - as the content provided now in /etc/shorewall/init effectively overrules /etc/sysctl.conf.> I am inclined to not run Mandrake as a firewall (although I like the > folks at Mandrake, I am a MandrakeClub member and I buy licenses for > their official releases). Mandrake''s philosophy is to be on the cutting > edge of Linux development which is fine for a desktop (which is where I > run Drake) but not for a firewall or server. If you want to run a > Mandrake Firewall, I recommend that you run MNF (which is also > Shorewall-based).Yes, I am aware of this the hard way on a number of issues. That is why I removed the Mandrake rpm of shorewall and all its files, and then installed from shorewall-2.0.4.tgz. That is what we are working with now and so the exact version of Shorewall is 2.0.4. Here is the complete exact output of ''ip addr show''. [root@flagship gwalsh]# ip addr show 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever inet6 ff02::1/128 scope global valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:05:39:78:e6 brd ff:ff:ff:ff:ff:ff inet 142.179.101.34/21 brd 142.179.103.255 scope global eth0 inet6 fe80::240:5ff:fe39:78e6/64 scope link valid_lft forever preferred_lft forever inet6 ff02::1:ff39:78e6/128 scope global valid_lft forever preferred_lft forever inet6 ff02::1/128 scope global valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:05:83:5e:88 brd ff:ff:ff:ff:ff:ff inet 10.14.122.252/18 brd 10.14.127.255 scope global eth1 inet6 fe80::240:5ff:fe83:5e88/64 scope link valid_lft forever preferred_lft forever inet6 ff02::1:ff83:5e88/128 scope global valid_lft forever preferred_lft forever inet6 ff02::1/128 scope global valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:c9:fb:18:10 brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global eth2 inet 192.168.3.2/24 brd 192.168.3.255 scope global eth2:10 inet 192.168.1.1/24 brd 192.168.1.255 scope global eth2:3 inet 192.168.2.1/24 brd 192.168.2.255 scope global eth2:6 inet 192.168.0.2/24 brd 192.168.0.255 scope global secondary eth2:1 inet 192.168.3.3/24 brd 192.168.3.255 scope global secondary eth2:11 inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth2:2 inet 192.168.1.2/24 brd 192.168.1.255 scope global secondary eth2:4 inet 192.168.1.3/24 brd 192.168.1.255 scope global secondary eth2:5 inet 192.168.2.2/24 brd 192.168.2.255 scope global secondary eth2:7 inet 192.168.2.3/24 brd 192.168.2.255 scope global secondary eth2:8 inet 192.168.3.1/24 brd 192.168.3.255 scope global secondary eth2:9 inet6 fe80::2a0:c9ff:fefb:1810/64 scope link valid_lft forever preferred_lft forever inet6 ff02::1:fffb:1810/128 scope global valid_lft forever preferred_lft forever inet6 ff02::1/128 scope global valid_lft forever preferred_lft forever 5: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 Here is the complete exact output of ''ip route show'': [root@flagship gwalsh]# ip route show 192.168.3.0/24 dev eth2 proto kernel scope link src 192.168.3.2 192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.1 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1 192.168.0.0/24 dev eth2 scope link 142.179.96.0/21 dev eth0 scope link 10.14.64.0/18 dev eth1 scope link 127.0.0.0/8 dev lo scope link default via 142.179.96.254 dev eth0> > I AM NOT SUGGESTING THAT YOU CHANGE YOUR FIREWALL DISTRIBUTION; we don''t > need more variables in your situation -- I am simply confirming what you > probably already know. > > > > > In the attachment is an extract from /var/sys/syslog showing shorewall > > data for the 12 lan IPs on eth2 as well as both the eth0 and eth1 > > network connections. > > From that extract: > > Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT= > MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 > ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110 > > The first thing that we should notice is that the packets are being > logged from the ''net2all'' chain. That means that Shorewall is configured > with eth2 connected to the ''net'' zone.According to /etc/shorewall/interfaces; net eth0 142.179.103.255 arp_filter net eth1 10.14.127.255 arp_filter loc eth2 192.168.0.255,192.168.1.255,192.168.2.255,192.168.3.255 So how is eth2 connected to the ''net'' zone?> > George -- I''m going to ask you this one more time; WHAT IS CONNECTED TO > eth2?eth2 provides for the lan connectivity for the 4 users and nothing else. These 4 users correspond directly with the 4 dns zones. They are: 192.168.0.1 nsd directionalservices.com nsd 192.168.0.2 mail.dscdirectionalservices.com mail 192.168.0.3 www.dscdirectionalservices.com www 192.168.1.1 nsx xpotentialresearch.com nsx 192.168.1.2 mail.xpotentialresearch.com mailx 192.168.1.3 www.xpotentialresearch.com wwwx 192.168.2.1 nsc.cruiseroutes.com nsc 192.168.2.2 mail.cruiseroutes.com mailc 192.168.2.3 www.cruiseroutes.com wwwc 192.168.3.1 nst.trackroutes.com nst 192.168.3.2 mail.trackroutes.com mailt 192.168.3.3 www.trackroutes.com wwwt> If your next post doesn''t make that perfectly clear then *I* am > going to give up in frustration.> Are there local systems connected > there?Nothing but!> What firewall services do these systems need access to?DNS - access to read -; the name server defined in /etc/resolv.conf is 192.168.0.1 This address will also handle secure logins (so Johnnie can get into the sytem development files.) Mail (both directions) for 192.168.0.2,192.168.1.2,192.168.2.2, 192.168.3.2 WWW (both directions) for 192.168.0.3,192.168.1.3,192.168.2.3,192.168.3.3> What > services (if any) do these systems provide to the internet? After 4 > days, the only thing that I''ve learned about eth2 is that it is the > on-motherboard NIC,.. true ..> it has a slew of IP addresses,.. true ..> those IP addresses > are supposedly there because of some policy of your ISP,.. no, eth2 being the lan connection doesn''t give a fig about the telus rules. The virtual interfacing of eth2 is designed to correspond directly with dns as I have shown above - and in turn to make it easy to cleanly remove each client/zone/department to a colocation when its time comes.> and it _seems_ > that your servers listen on those addresses (again, I''ve tried since > your first post to determine where your servers run -- is that a state > secret???).Nope, I have no secrets I know of. Sendmail and dns and apache all ''know'' about where to find things directly from this layout. While the firewall needs access to 192.168.0.1 in its defined function as the local name server, 192.168.1.1,192.168.2.1 and 192.168.3.1 are totally off limits to the firewall/internet. When there is no firewall involved, all of these services work perfectly. eth0 should listen at port 80, eth1 should listen at port 443. the default gateway through eth0 is shown correctly in the routing table.> > > > > Oh yes, and that last nuisance regarding an invalid ICMP type 3. > > > > Then there is the output of iptables -nvL, which I thought you might > > find of interest. Aside from shorewall status, note its not too happy > > about icmp either! > > George -- one of the reasons that http://shorewall.net/support.htm says > not to post the output of iptables -L (and to post the output of > "shorewall status" instead) is that I spent a lot of time designing > "shorewall status" to give me the information that I need to solve > problems.Tom, as I had earlier sent you the output of ''shorewall status'', I was just trying to help by sending the iptables -L output in the hopes it might help. That''s all.> This is a perfect example. You complain about invalid ICMP > type 3''s being generated and the log extract provides the date and time > of day when this occurs; unfortunately, I have no clue at what time the > iptables counters were last reset so I have no way to relate the output > of iptables -L to the log messages.Understood ... lets leave this nuisance for the time being? I''ll make a note to follow the time the iptables counters are reset in the future. I wonder why Mandrake uses port 8 rather than the usual port 7, but I guess that''s a minor matter.> > What I want you to do is to follow the instructions at > http://shorewall.net/support.htm to the letter (I know that you have > sent some of this information before but I need a coherent set of data > that I know was captured at the same time).My biggest handicap is I have but one machine. So, I have to take down the firewall in order to get mail out to you and receive email back.> You obviously have problems > establishing connections to/through your firewall so the part that > begins "This is Important" in bold font is relevant. > > I''m going to also ask you to make NO changes that I don''t ask you to > make -- I am going to need to be able to have confidence that what I''m > seeing isn''t the result of unseen changes.Of course. For the record, these are the additions made in the config files to the 2.04 defaults as received from your site, NOT Mandrake''s version! Add to/etc/shorewall/init: for file in /proc/sys/net/ipv4/conf/*/log_martians; do echo > $file done Add to existing defaults in /etc/shorewall/policy: fw net ACCEPT fw loc ACCEPT Add to /etc/shorewall/params: MTAS=192.168.0.2,192.168.1.2,192.168.2.2,192.168.3.2 WWW=192.168.0.3,192.168.1.3,192.168.2.3,192.168.3.3 Add to /etc/shorewall/interfaces: net eth0 142.179.103.155 arp_filter net eth1 10.14.127.255 arp_filter loc eth2 192.168.0.255,192.168.1.255,192.168.2.255, 192.168.3.255 Add to /etc/shorewall/rules: ACCEPT net fw udp 22 ACCEPT loc fw udp 22 ACCEPT net fw tcp 53 ACCEPT loc fw tcp 53 ACCEPT net $FW:$MTAS tcp 25 ACCEPT $FW net tcp 25 ACCEPT loc $FW:$MTAS tcp 25 ACCEPT net $FW:$WWW tcp 80,443 ACCEPT loc $FW:$WWW tcp 80,443 ACCEPT net fw icmp 8 ACCEPT net fw icmp 8 Okay, if this looks good to you, or there are changes you wish made, I''ll make them as requested, bring up shorewall, and test initially by sending email in from a netscape address. When that works, and I can get a reply back to the netscape address, I''ll feel able to tackle the Apache configuration which I have completely ignored for the time being. Find some R&R time for yourself over the weekend. Its 1:00am now, so that advice makes me a bit of a hypocrite. Oh well .... George -- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
On Sat, 2004-07-10 at 18:56 -0700, Tom Eastep wrote:> G. Walsh wrote: > > > First, I discovered that some great hand takes it upon himself to > > overwrite /etc/sysctl.conf, resetting the log_martians equate each time. > > Each time what? > > > But if shorewall is started, that overrides. So ..... that problem is > > done away with. Mandrake, Mandrake!! Less ''magic'', more ''meat''.Just a shot in the darkness: What''s the msec security level you choose for that server? I don''t know for sure, but that setting may affect the log_martians setting as well. Just to mention it as a possibility, since I don''t have time right now to check anything further. A personal note: Mandrake is very happy with the RPMs provided by shorewall.net. Even less hassle than using the tarball (if at all). And don''t use the Mandrake wizard at all for configuring shorewall, but you probably figured that out yourself already...> I am inclined to not run Mandrake as a firewall (although I like the > folks at Mandrake, I am a MandrakeClub member and I buy licenses for > their official releases). Mandrake''s philosophy is to be on the cutting > edge of Linux development which is fine for a desktop (which is where I > run Drake) but not for a firewall or server. If you want to run a > Mandrake Firewall, I recommend that you run MNF (which is also > Shorewall-based).As long as you don''t let those wizards mess with your good, hand-crafted shorewall configuration, it should work fine. ;-) karsten -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon 06151/273859 Fax 06151/273862
On Sunday 11 July 2004 10:07, G. Walsh wrote:> > Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT> > MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 > > ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110Well what you seem to get in the logs is CUPS printer announcement broadcasts. Those are forbidden by your policy, so nothing special about them besides the chain in which they are logged and why the heck you run a printserver on the firewall :)> > The first thing that we should notice is that the packets are being > > logged from the ''net2all'' chain. That means that Shorewall is configured > > with eth2 connected to the ''net'' zone. > > According to /etc/shorewall/interfaces; > > net eth0 142.179.103.255 arp_filter > net eth1 10.14.127.255 arp_filter > loc eth2 192.168.0.255,192.168.1.255,192.168.2.255,192.168.3.255 > > So how is eth2 connected to the ''net'' zone?Just have a look at your iptables -L output: Chain eth2_in (1 references) 36 4680 net2fw all -- * * 0.0.0.0/0 0.0.0.0/0 This means that shorewall puts your incoming traffic to net2fw instead of loc2fw. However I can''t see why it does this. Bug in shorewall Tom? Are there really no logs about your mail? Why does your mail traffic get blocked when there is nothing about that in the logfiles? I asked you this question ealier. Also tcpdump is your friend when you need to know whats really going on.>> Are there local systems connected there? > Nothing but!Do I understand that right, eth2 is not physically connected to anything else? The addresses mentioned earlier are all assigned to the fw machine.> I wonder why Mandrake uses port 8 rather than the usual port 7Port 8, port 7? All I see is a destination unreachable message from your ISPs gateway to the broadcast address of your /21.> My biggest handicap is I have but one machine. So, I have to take down > the firewall in order to get mail out to you and receive email back.From where do you write your mails and whats in the logs about port 25 when the firewall is running and you try to send mails?> Add to /etc/shorewall/interfaces: > net eth0 142.179.103.155 arp_filtertypo or cut&paste? ^ ealier in this mail it was 255 :)> Add to /etc/shorewall/rules: > ACCEPT net $FW:$MTAS tcp 25Why ever the net zone would be able to send to your rfc1918 addresses... Mh but if your eth2 traffic comes from the net zone (which the log messages suggest), then this rule would still allow traffic to the fw.> ACCEPT $FW net tcp 25 > ACCEPT loc $FW:$MTAS tcp 25You send all your mail through the mailserver running on the firewall itself, right? So $FW to net should allow traffic. I''d really like to see a log entry when you try to send mail. Also tcpdump really helps to see where packets really go!> Find some R&R time for yourself over the weekend. Its 1:00am now, so > that advice makes me a bit of a hypocrite. Oh well ....Well your mail arrived at 10:07am here in Germanny :) Alex
Alexander Gretencord wrote:> On Sunday 11 July 2004 10:07, G. Walsh wrote: > >>>Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT>>>MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 >>>ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110 > > > Well what you seem to get in the logs is CUPS printer announcement broadcasts. > Those are forbidden by your policy, so nothing special about them besides the > chain in which they are logged and why the heck you run a printserver on the > firewall :) >The interesting thing is that these are the firewall''s own broadcasts being processed as input. Apparently they are not being detected as broadcasts by the pkttype match extension: Chain dropBcast (2 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast> >>>The first thing that we should notice is that the packets are being >>>logged from the ''net2all'' chain. That means that Shorewall is configured >>>with eth2 connected to the ''net'' zone. >> >>According to /etc/shorewall/interfaces; >> >>net eth0 142.179.103.255 arp_filter >>net eth1 10.14.127.255 arp_filter >>loc eth2 192.168.0.255,192.168.1.255,192.168.2.255,192.168.3.255 >> >>So how is eth2 connected to the ''net'' zone? > > > Just have a look at your iptables -L output: > > Chain eth2_in (1 references) > 36 4680 net2fw all -- * * 0.0.0.0/0 0.0.0.0/0 > > This means that shorewall puts your incoming traffic to net2fw instead of > loc2fw. However I can''t see why it does this. Bug in shorewall Tom?I would have to see a trace of "shorwall start" to understand what is happening here. Seems unlikely that it''s a Shorewall bug given George''s Shorewall configuration is very simple and very much like 1000''s of others around the world. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
G. Walsh wrote:>>>In the attachment is an extract from /var/sys/syslog showing shorewall >>>data for the 12 lan IPs on eth2 as well as both the eth0 and eth1 >>>network connections. >> >> From that extract: >> >>Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT= >>MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 >>ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110 >> >>The first thing that we should notice is that the packets are being >>logged from the ''net2all'' chain. That means that Shorewall is configured >>with eth2 connected to the ''net'' zone. > > > According to /etc/shorewall/interfaces; > > net eth0 142.179.103.255 arp_filter > net eth1 10.14.127.255 arp_filter > loc eth2 192.168.0.255,192.168.1.255,192.168.2.255,192.168.3.255 > > So how is eth2 connected to the ''net'' zone? >Ok -- we have to solve this first. Please: shorewall trace shorewall restart 2> /tmp/trace.txt and send me the /tmp/trace.txt file. The file will be rather large so please don''t copy the list. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hmmmm ... I didn''t think of that one, Karsten. I moved it up one notch when installing - from standard to high - which isn''t a big jump but enough to let me monitor changes in the sys files every morning. Thanks for the input. George On Sun, 2004-07-11 at 12:39 +0200, Karsten Bräckelmann wrote:> On Sat, 2004-07-10 at 18:56 -0700, Tom Eastep wrote: > > G. Walsh wrote: > > > > > First, I discovered that some great hand takes it upon himself to > > > overwrite /etc/sysctl.conf, resetting the log_martians equate each time. > > > > Each time what? > > > > > But if shorewall is started, that overrides. So ..... that problem is > > > done away with. Mandrake, Mandrake!! Less ''magic'', more ''meat''. > > Just a shot in the darkness: What''s the msec security level you choose > for that server? > > I don''t know for sure, but that setting may affect the log_martians > setting as well. Just to mention it as a possibility, since I don''t have > time right now to check anything further. > > > A personal note: Mandrake is very happy with the RPMs provided by > shorewall.net. Even less hassle than using the tarball (if at all). And > don''t use the Mandrake wizard at all for configuring shorewall, but you > probably figured that out yourself already... > > > > I am inclined to not run Mandrake as a firewall (although I like the > > folks at Mandrake, I am a MandrakeClub member and I buy licenses for > > their official releases). Mandrake''s philosophy is to be on the cutting > > edge of Linux development which is fine for a desktop (which is where I > > run Drake) but not for a firewall or server. If you want to run a > > Mandrake Firewall, I recommend that you run MNF (which is also > > Shorewall-based). > > As long as you don''t let those wizards mess with your good, hand-crafted > shorewall configuration, it should work fine. ;-) > > karsten > > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
Alex: I''m trying my best to do things one at a time here. I''ve sent Tom the output he requested - UP TO his form of output from starting shorewall because, at least to this point, I get one mess in the system and so I take everything out to do the email thing, and put it back (with script for consistency) each time to work through the next stage. eth2 is the LAN on the machine, and always has been. I don''t understand why eth2 is connected to the net. That''s NOT what /etc/shorewall/interfaces says. There is only one computer involved. eth0 is the default gateway/firewall, eth1 the ''second'' external IP intended for secure traffic in the future and made necessary by the ISP demanding 2 MAC addresses for 2 static IPs. As for cups, I suppose there is no real reason why I need it - its not as if others are using the printer - another thing to follow through with. In the meantime, I have promised Tom that I would not change anything without his prior knowledge or instruction. Thanks for showing interest, though. George On Sun, 2004-07-11 at 14:27 +0200, Alexander Gretencord wrote:> On Sunday 11 July 2004 10:07, G. Walsh wrote: > > > Jul 10 17:27:11 flagship kernel: Shorewall:net2all:DROP:IN=eth2 OUT> > > MAC= SRC=192.168.3.2 DST=192.168.3.255 LEN=130 TOS=0x00 PREC=0x00 TTL=64 > > > ID=238 DF PROTO=UDP SPT=631 DPT=631 LEN=110 > > Well what you seem to get in the logs is CUPS printer announcement broadcasts. > Those are forbidden by your policy, so nothing special about them besides the > chain in which they are logged and why the heck you run a printserver on the > firewall :) > > > > The first thing that we should notice is that the packets are being > > > logged from the ''net2all'' chain. That means that Shorewall is configured > > > with eth2 connected to the ''net'' zone. > > > > According to /etc/shorewall/interfaces; > > > > net eth0 142.179.103.255 arp_filter > > net eth1 10.14.127.255 arp_filter > > loc eth2 192.168.0.255,192.168.1.255,192.168.2.255,192.168.3.255 > > > > So how is eth2 connected to the ''net'' zone? > > Just have a look at your iptables -L output: > > Chain eth2_in (1 references) > 36 4680 net2fw all -- * * 0.0.0.0/0 0.0.0.0/0 > > This means that shorewall puts your incoming traffic to net2fw instead of > loc2fw. However I can''t see why it does this. Bug in shorewall Tom? > > Are there really no logs about your mail? Why does your mail traffic get > blocked when there is nothing about that in the logfiles? I asked you this > question ealier. Also tcpdump is your friend when you need to know whats > really going on. > > >> Are there local systems connected there? > > Nothing but! > > Do I understand that right, eth2 is not physically connected to anything else? > The addresses mentioned earlier are all assigned to the fw machine. > > > I wonder why Mandrake uses port 8 rather than the usual port 7 > > Port 8, port 7? All I see is a destination unreachable message from your ISPs > gateway to the broadcast address of your /21. > > > My biggest handicap is I have but one machine. So, I have to take down > > the firewall in order to get mail out to you and receive email back. > > >From where do you write your mails and whats in the logs about port 25 when > the firewall is running and you try to send mails? > > > Add to /etc/shorewall/interfaces: > > net eth0 142.179.103.155 arp_filter > typo or cut&paste? ^ > ealier in this mail it was 255 :) > > > Add to /etc/shorewall/rules: > > ACCEPT net $FW:$MTAS tcp 25 > > Why ever the net zone would be able to send to your rfc1918 addresses... Mh > but if your eth2 traffic comes from the net zone (which the log messages > suggest), then this rule would still allow traffic to the fw. > > > ACCEPT $FW net tcp 25 > > ACCEPT loc $FW:$MTAS tcp 25 > > You send all your mail through the mailserver running on the firewall itself, > right? So $FW to net should allow traffic. I''d really like to see a log entry > when you try to send mail. Also tcpdump really helps to see where packets > really go! > > > Find some R&R time for yourself over the weekend. Its 1:00am now, so > > that advice makes me a bit of a hypocrite. Oh well .... > > Well your mail arrived at 10:07am here in Germanny :) > > > Alex > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
Tom: I''ll restart shorewall in the next 15 minutes or so, and send you the txt output exactly as you requested. George On Sun, 2004-07-11 at 07:37 -0700, Tom Eastep wrote:> Ok -- we have to solve this first. Please: > > shorewall trace shorewall restart 2> /tmp/trace.txt > > and send me the /tmp/trace.txt file. > > The file will be rather large so please don''t copy the list. > > Thanks, > -Tom-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
On Sunday 11 July 2004 22:39, G. Walsh wrote:> I''m trying my best to do things one at a time here.Absolutely, else you don''t know what it really was in the end :)> I don''t understand why eth2 is connected to the net. That''s NOT > what /etc/shorewall/interfaces says.Well I hope the trace output you sent Tom will make that clear. I''d love to hear the reason for this.> In the meantime, I have promised Tom that I would not change anything > without his prior knowledge or instruction.I didn''t ask you to do anything to your configuration. I was merely suggesting to take a closer look at the logs and traffic when "mail doesn''t work" because until now I have not seen anything mail related. Alex
G. Walsh wrote:> > eth2 provides for the lan connectivity for the 4 users and nothing else. > These 4 users correspond directly with the 4 dns zones. They are: > 192.168.0.1 nsd directionalservices.com nsd > 192.168.0.2 mail.dscdirectionalservices.com mail > 192.168.0.3 www.dscdirectionalservices.com www > 192.168.1.1 nsx xpotentialresearch.com nsx > 192.168.1.2 mail.xpotentialresearch.com mailx > 192.168.1.3 www.xpotentialresearch.com wwwx > 192.168.2.1 nsc.cruiseroutes.com nsc > 192.168.2.2 mail.cruiseroutes.com mailc > 192.168.2.3 www.cruiseroutes.com wwwc > 192.168.3.1 nst.trackroutes.com nst > 192.168.3.2 mail.trackroutes.com mailt > 192.168.3.3 www.trackroutes.com wwwtHere''s what we see on the internet when we want to connect to mail.dscdirectionalservices.com: root@lists root]# dig mail.dscdirectionalservices.com ; <<>> DiG 9.2.3 <<>> mail.dscdirectionalservices.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43381 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.dscdirectionalservices.com. IN A ;; ANSWER SECTION: mail.dscdirectionalservices.com. 653 IN A 142.179.101.34 ;; AUTHORITY SECTION: dscdirectionalservices.com. 78589 IN NS ns1.virtualdh.com. dscdirectionalservices.com. 78589 IN NS ns2.virtualdh.com. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Jul 11 15:26:27 2004 ;; MSG SIZE rcvd: 111 [root@lists root]# telnet mail.dscdirectionalservices.com 25 Trying 142.179.101.34... <timed out> [root@lists root]# So what I believe that you actually need for SMTP rules is: ACCEPT net fw tcp 25 ACCEPT loc fw tcp 25 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom: This was the <delayed> email looks like! The change in rules has been made. GJW On Sun, 2004-07-11 at 15:30 -0700, Tom Eastep wrote:> G. Walsh wrote: > > > > > > eth2 provides for the lan connectivity for the 4 users and nothing else. > > These 4 users correspond directly with the 4 dns zones. They are: > > 192.168.0.1 nsd directionalservices.com nsd > > 192.168.0.2 mail.dscdirectionalservices.com mail > > 192.168.0.3 www.dscdirectionalservices.com www > > 192.168.1.1 nsx xpotentialresearch.com nsx > > 192.168.1.2 mail.xpotentialresearch.com mailx > > 192.168.1.3 www.xpotentialresearch.com wwwx > > 192.168.2.1 nsc.cruiseroutes.com nsc > > 192.168.2.2 mail.cruiseroutes.com mailc > > 192.168.2.3 www.cruiseroutes.com wwwc > > 192.168.3.1 nst.trackroutes.com nst > > 192.168.3.2 mail.trackroutes.com mailt > > 192.168.3.3 www.trackroutes.com wwwt > > Here''s what we see on the internet when we want to connect to > mail.dscdirectionalservices.com: > > root@lists root]# dig mail.dscdirectionalservices.com > > ; <<>> DiG 9.2.3 <<>> mail.dscdirectionalservices.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43381 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mail.dscdirectionalservices.com. IN A > > ;; ANSWER SECTION: > mail.dscdirectionalservices.com. 653 IN A 142.179.101.34 > > ;; AUTHORITY SECTION: > dscdirectionalservices.com. 78589 IN NS ns1.virtualdh.com. > dscdirectionalservices.com. 78589 IN NS ns2.virtualdh.com. > > ;; Query time: 2 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Jul 11 15:26:27 2004 > ;; MSG SIZE rcvd: 111 > > [root@lists root]# telnet mail.dscdirectionalservices.com 25 > Trying 142.179.101.34... > > <timed out> > > [root@lists root]# > > So what I believe that you actually need for SMTP rules is: > > ACCEPT net fw tcp 25 > ACCEPT loc fw tcp 25 > > -Tom-- G. Walsh, Managing Director, DSC Directional Services Corp., Victoria, B.C., Canada
On Mon, 2004-07-12 at 10:01, G. Walsh wrote:> Tom: > > This was the <delayed> email looks like! > > The change in rules has been made.I''ve not been following the thread all that close...but this now works: [egreshko@misty egreshko]$ telnet mail.dscdirectionalservices.com 25 Trying 142.179.101.34... Connected to flagship.dscdirectionalservices.com (142.179.101.34). Escape character is ''^]''. 220 flagship.dscdirectionalservices.com ESMTP Sendmail 8.13.0/8.13.0; Sun, 11 Jul 2004 19:18:20 -0700 quit Regards, Ed -- "I think the problem, to be quite honest with you, is that you''ve never actually known what the question is." --The computer "Deep Thought" in "Life, The Universe and Everything"
Ed Greshko wrote:> On Mon, 2004-07-12 at 10:01, G. Walsh wrote: > >>Tom: >> >>This was the <delayed> email looks like! >> >>The change in rules has been made. > > > I''ve not been following the thread all that close...but this now works: > > [egreshko@misty egreshko]$ telnet mail.dscdirectionalservices.com 25 > Trying 142.179.101.34... > Connected to flagship.dscdirectionalservices.com (142.179.101.34). > Escape character is ''^]''. > 220 flagship.dscdirectionalservices.com ESMTP Sendmail 8.13.0/8.13.0; > Sun, 11 Jul 2004 19:18:20 -0700 > quitYes -- George and I have been working off-list and it appears that his MTA is now passing both incoming and outgoing email. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net