Hi All, Apparently today is the day that I am too dumb to operate Shorewall. I cannot DNAT standard ports. For example: DNAT net loc:10.0.50.50:80 tcp 81 Works. I can point my (external) browser to my site:81 and the web server on 10.0.50.50:80 comes up. This, however: DNAT net loc:10.0.50.50 tcp 80 Does not work. The log shows the connection being allowed in, but nothing comes back you (much like my earlier gateway problem which is now rectified). I have tried many permutations of the standard 80 <-> 80 forward to no avail. I have tried: Web/DNAT loc:10.0.50.50 tcp and even DNAT net loc:10.0.50.50:80 tcp 80 But no go. There are no other rules with http or port 80 in them in the rules file and my rule is the very first one. It seems that the primary part of the DNAT is working, but the return is broken somehow. Again, DNAT functions perfectly if I DNAT from external port 81, 999, and 5000 just to name a few. It''s just port 80 that doesn''t work. Anyone have any ideas..? I''m not sure what to attach for documentation. Thanks! J ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> > Anyone have any ideas..? >Are you sure that your ISP isn''t blocking SYN,ACK replies from port 80?> I''m not sure what to attach for documentation.http://www.shorewall.net/support.htm#Guidelines. But -- these issues are virtually never problems that you can diagnose by looking just at the firewall itself. The DNAT troubleshooting tips in FAQs 1a and 1b are still your best friends (as is a packet sniffer like tcpdump or wireshark). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 3/16/07, Jon <me@jonwatson.ca> wrote:> I cannot DNAT standard ports. For example: > > DNAT net loc:10.0.50.50:80 tcp 81 > > Works. I can point my (external) browser to my site:81 and the web > server on 10.0.50.50:80 comes up.Have you tried binding the local server to port 81 and redirecting port 80 to 81? Just a thought, but if you''re having problems going A->A, it can''t hurt to try alternatives. Also, it might be wise to run a separate server for external and internal users to prevent security problems. Apache can do this by itself, but I don''t know if you''re running Apache. Will ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Are you sure that your ISP isn''t blocking SYN,ACK replies from port 80?Pretty sure. We have a one of the higher level business packages with 5 statics which is 2 above their entry level business package. Plus, I''m looking at the logs on my firewall and I see nothing coming back from my local machine. My ISP has no knowledge of those packets. Plus, plus, double-plus, I only provided port 80 as an example. The same situation (standard fails but non-standard works) applies to SMTP, POP, HTTP, HTTPS, and SSH (admittedly SSH is DNAT''d from external 2222 to internal 10.0.50.50:22 but the rest are straight through).>> I''m not sure what to attach for documentation.>> > http://www.shorewall.net/support.htm#Guidelines. Well, OK. I had hoped that would be overkill for this situation, but here it is (lower).> But -- these issues are virtually never problems that you can diagnose > by looking just at the firewall itself. The DNAT troubleshooting tips in > FAQs 1a and 1b are still your best friends (as is a packet sniffer like > tcpdump or wireshark).Based on your tips earlier about my other problem I have been over and over 1a and 1b. Unless I misread, they consist of two concepts: ensure the gateway on your local machine points to your firewall and ensure that a reverse DNS lookup resolves. Both are true in my case (after fixing the gateway issue earlier today on your pointer). I could supply logs to this extent, but I think the fact that standard ports for smpt, pop, http, and https work correctly via DNAT should be enough although I will provide logs if required. I must admit that I had hoped such a succinct problem as "standard ports don''t work but non-standard ports do" would ring a bell amongst the list members. I hope that I''m not a "one of". Being a one-of is an interesting thing for those who come after, but a truly crappy thing to be in the first place. Requested info: ---- root@server:~# shorewall version 3.0.4 ---- root@server:~# 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 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:95:c5:0b:83 brd ff:ff:ff:ff:ff:ff inet 137.186.135.69/22 brd 137.186.135.255 scope global eth0 inet6 fe80::211:95ff:fec5:b83/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:d4:b1:6c:ff brd ff:ff:ff:ff:ff:ff inet 10.0.50.10/24 brd 10.0.50.255 scope global eth1 inet6 fe80::213:d4ff:feb1:6cff/64 scope link valid_lft forever preferred_lft forever 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 ---- root@server:~# ip route show 10.0.50.0/24 dev eth1 proto kernel scope link src 10.0.50.10 137.186.132.0/22 dev eth0 proto kernel scope link src 137.186.135.69 default via 137.186.132.1 dev eth0 ---- Oh...hell...that should have been a lot more painful. Is there something else I should provide that I didn''t? Thanks for your help! Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> > Well, OK. I had hoped that would be overkill for this situation, but > here it is (lower). > >> But -- these issues are virtually never problems that you can diagnose >> by looking just at the firewall itself. The DNAT troubleshooting tips in >> FAQs 1a and 1b are still your best friends (as is a packet sniffer like >> tcpdump or wireshark).Have you used a packet sniffer yet to see what is happening?> I must admit that I had hoped such a succinct problem as "standard ports > don''t work but non-standard ports do" would ring a bell amongst the list > members.The only difference between "standard" and "non-standard" ports is in your mind. Neither Shorewall nor any of the software that it configures understands the concept of "standard" vs "non-standard" ports (although Netfilter has support for certain problem applications like FTP). I hope that I''m not a "one of". Being a one-of is an> interesting thing for those who come after, but a truly crappy thing to > be in the first place. > > Requested info:You are having a connection problem (external clients cannot connect to your internal server. According to the flowchart and text in the support guidelines, that calls for the output of "shorewall dump" collected in a particular manner. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> The only difference between "standard" and "non-standard" ports is in your > mind.I know - that''s why it''s so unbelievably weird. At least to me.> You are having a connection problem (external clients cannot connect to your > internal server. According to the flowchart and text in the support > guidelines, that calls for the output of "shorewall dump" collected in a > particular manner.Correct. I will dive back into this problem tomorrow and if I can''t sort it then I will supply the correct data. Thanks! Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Will Murnane wrote:> Have you tried binding the local server to port 81 and redirecting > port 80 to 81? Just a thought, but if you''re having problems going > A->A, it can''t hurt to try alternatives.I did think of that, but this is a Scalix install and there are a number of services running on it. I''m confident that there is a solution to forwarding the correct ports, so that''s where I''m spending my energy.> Also, it might be wise to run a separate server for external and > internal users to prevent security problems. Apache can do this by > itself, but I don''t know if you''re running Apache.Ultimately, I agree this is ideal. At the moment, however, we''re in the setup/testing phase and not working in what will be the production environment. Although, you bring up a good point, why don''t I just DMZ this machine...? THanks! J ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Morning, Tom Eastep wrote:> You are having a connection problem (external clients cannot connect to your > internal server. According to the flowchart and text in the support > guidelines, that calls for the output of "shorewall dump" collected in a > particular manner.Attached is a shorewall dump from my current imperfect setup. To recap: I am attempting to DNAT a myriad of requests through the Shorewall firewall to a local machine. The firewall has two NICs where eth1 is an internal 10.0.50.10 and eth0 is an external to the ISP. The machine I am trying to DNAT to is 10.0.50.50 and I wish to DNAT smtp, http, https, pop3, imap, and imaps all on their standard ports. The quirky thing is that if I configure Shorewall to DNAT from a non-standard port on the firewall to a standard port on the local machine, everything works. For example, if I configure the firewall to listen on port 26 and send those requests to port 25 on the local machine, that works and I can send mail. However, using standard ports fail. For example, configuring the firewall to accept all connections and then just route them to the local machine on the originating port fails. Likewise, rules specifying standard ports (like configuring the firewall to accept requests on port 25 and specifically route them to the local machine on port 25) also fail. I see in the syslog that requests make it through the firewall with the appropriate dnat_net notation in the log so it appears to be a matter of the traffic not coming back out. I have attempted to tcpdump the interface, but my skills are somewhat rudimentary in this area. Both successful non-standard port and unsuccessful standard port conversations look the same to me. I''m really not sure if this is a Shorewall issue -in fact, I somehow doubt it is. However, I have spent several days on this already and I am totally out of ideas at this point. Any and all help is appreciated. Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> > I am attempting to DNAT a myriad of requests through the Shorewall > firewall to a local machine. The firewall has two NICs where eth1 is an > internal 10.0.50.10 and eth0 is an external to the ISP.You have exactly one DNAT rule -- for port 25.> > The machine I am trying to DNAT to is 10.0.50.50 and I wish to DNAT > smtp, http, https, pop3, imap, and imaps all on their standard ports. > > The quirky thing is that if I configure Shorewall to DNAT from a > non-standard port on the firewall to a standard port on the local > machine, everything works. For example, if I configure the firewall to > listen on port 26 and send those requests to port 25 on the local > machine, that works and I can send mail.What do you mean by "listen on port 26"? Are you just describing a DNAT rule that rewrites the destination port number?> > However, using standard ports fail. For example, configuring the > firewall to accept all connections and then just route them to the local > machine on the originating port fails.Your terminology is wrong. In the context of your problem, Shorewall has nothing to do with routing. Shorewall directs Netfilter to rewrite the destination IP address (and/or destination port number) on certain incoming packets -- that''s all it does.> Likewise, rules specifying > standard ports (like configuring the firewall to accept requests on port > 25 and specifically route them to the local machine on port 25) also fail.Again, Shorewall can configure Netfilter to rewrite addresses and port numbers -- the only two times that Shorewall affects routing are a) If you use /etc/shorewall/proxyarp and specify No in the HAVEROUTE column; and b) If you have entries in /etc/shorewall/providers.> > I see in the syslog that requests make it through the firewall with the > appropriate dnat_net notation in the log so it appears to be a matter of > the traffic not coming back out.> > I have attempted to tcpdump the interface, but my skills are somewhat > rudimentary in this area. Both successful non-standard port and > unsuccessful standard port conversations look the same to me.You are certainly handicapped when trying to run a Unix-based router/gateway/firewall when you aren''t familiar with the basic diagnostic tools of the platform.> > I''m really not sure if this is a Shorewall issue -in fact, I somehow > doubt it is. However, I have spent several days on this already and I am > totally out of ideas at this point. > > Any and all help is appreciated. >One odd thing that I notice is that you are attempting to test from host 161.184.172.35 which is in the ''admin'' zone rather than in the ''net'' zone (which is what your DNAT rule specifies). While I don''t see where that should make a material difference give that the admin->loc policy is ACCEPT, it indicates that you apparently don''t have a crisp idea of what you are testing. I also notice that host 161.184.172.35 appears to be included twice in the ''admin'' zone. Another odd thing about your config is that while the admin->loc policy is ACCEPT, you also have ACCEPT admin->loc rules!!?? What I suggest that you try is: a) On the firewall system, "tcpdump -nvvi eth0 host 61.184.172.35 and port 25". b) From 61.184.172.35, "telnet 137.186.135.69 25". Are you seeing response packets? Do they have the correct checksum (tcpdump will complain if they don''t). Do they have the correct Source IP (137.186.135.69)? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> What I suggest that you try is: > > a) On the firewall system, "tcpdump -nvvi eth0 host 61.184.172.35 and port 25". > > b) From 61.184.172.35, "telnet 137.186.135.69 25". > > Are you seeing response packets? Do they have the correct checksum (tcpdump > will complain if they don''t). Do they have the correct Source IP > (137.186.135.69)?Looks like, but as we''ve already established I''m not an expert. 13:17:34.572203 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum 0x7414 (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss 1460,sackOK,timestamp 2690993 18165458,nop,wscale 2> 13:17:35.985329 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum 0x72ae (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss 1460,sackOK,timestamp 2691351 18165458,nop,wscale 2> J ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> Tom Eastep wrote: >> What I suggest that you try is: >> >> a) On the firewall system, "tcpdump -nvvi eth0 host 61.184.172.35 and >> port 25". >> >> b) From 61.184.172.35, "telnet 137.186.135.69 25". >> >> Are you seeing response packets? Do they have the correct checksum >> (tcpdump >> will complain if they don''t). Do they have the correct Source IP >> (137.186.135.69)? > > Looks like, but as we''ve already established I''m not an expert. > > 13:17:34.572203 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: > TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum > 0x7414 (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss > 1460,sackOK,timestamp 2690993 18165458,nop,wscale 2> > 13:17:35.985329 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: > TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum > 0x72ae (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss > 1460,sackOK,timestamp 2691351 18165458,nop,wscale 2>Those are duplicate packets (only the checksum and window size are different and there is no intervening packet in the other direction) which suggests that the recipient (161.184.172.35) isn''t getting them. Looks like it''s time to get a packet trace on 161.184.172.35. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Those are duplicate packets (only the checksum and window size are > different and there is no intervening packet in the other direction) > which suggests that the recipient (161.184.172.35) isn''t getting them. > Looks like it''s time to get a packet trace on 161.184.172.35.I just noticed something that I suspect is the crux of the problem. With Shorewall running, no loc <->loc traffic works despite their being a loc loc ACCEPT policy in effect. When I attempt to ping, telnet, ssh, etc from 10.0.50.10 with Shorewall on, I get a connection refused error. With Shorewall cleared, the connection succeeds. The routing table looks the same, but with shorewall on an attempt to ping 10.0.50.50 from 10.0.50.10 results in a ''destination host unreachable'' error. This is officially over my head. J ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Jon wrote: >> Tom Eastep wrote: >>> What I suggest that you try is: >>> >>> a) On the firewall system, "tcpdump -nvvi eth0 host 61.184.172.35 and >>> port 25". >>> >>> b) From 61.184.172.35, "telnet 137.186.135.69 25". >>> >>> Are you seeing response packets? Do they have the correct checksum >>> (tcpdump >>> will complain if they don''t). Do they have the correct Source IP >>> (137.186.135.69)? >> Looks like, but as we''ve already established I''m not an expert. >> >> 13:17:34.572203 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: >> TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum >> 0x7414 (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss >> 1460,sackOK,timestamp 2690993 18165458,nop,wscale 2> >> 13:17:35.985329 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: >> TCP (6), length: 60) 137.186.135.69.25 > 161.184.172.35.58597: S, cksum >> 0x72ae (correct), 702401703:702401703(0) ack 2900661819 win 5792 <mss >> 1460,sackOK,timestamp 2691351 18165458,nop,wscale 2> > > Those are duplicate packets (only the checksum and window size are > different and there is no intervening packet in the other direction) > which suggests that the recipient (161.184.172.35) isn''t getting them. > Looks like it''s time to get a packet trace on 161.184.172.3Note that those are the SYN,ACK packets that are returned by the server in response to the client''s initial SYN. And it isn''t the advertised window that changed -- it''s the timestamp; sorry for the confusion. You can tell that they are SYN,ACK by the "S," before the ''cksum and the fact that they ''ack'' sequence 2900661819. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> With Shorewall running, no loc <->loc traffic works despite their being > a loc loc ACCEPT policy in effect. > > When I attempt to ping, telnet, ssh, etc from 10.0.50.10 with Shorewall > on, I get a connection refused error. With Shorewall cleared, the > connection succeeds. The routing table looks the same,How many times must I explain to you that Shorewall doesn''t change your routing table?> but with > shorewall on an attempt to ping 10.0.50.50 from 10.0.50.10 results in a > ''destination host unreachable'' error.First of all, 10.0.50.10 is the IP address of eth1 on your firewall. So when you ping 10.0.50.50 from 10.0.50.10, the initial connection is from the firewall ($FW = ''fw'') to ''loc'', not loc->loc. Your fw->loc rules are: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 137,138,139,445 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,135,137,138,139,445,1900,40000 0 0 ACCEPT udp -- * * 0.0.0.0/0 10.0.60.255 multiport dports 135,137,138,139,445 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 all2all all -- * * 0.0.0.0/0 0.0.0.0/0 which looks like you are accepting SMB, DNS, UPnP and UDP 40000 (whatever that is). You also are accepting ''ping'' which makes be very curious why you would get ''destination host unreachable'' -- are there log messages generated when you try this ''ping''? At any rate, all this is unlikely to have any relevance to your primary DNAT 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> How many times must I explain to you that Shorewall doesn''t change your > routing table?This has all been very disheartening. In a world of unlimited time and money I would have the time to solve this myself. I would have the time to become proficient in all of the tools and concepts. However, I (like many other IT people I would speculate) rarely have that luxury and sometimes have to rely on the good will of others who have been there before and hopefully return the favour when they are the ones who have been there before. I see I have exceeded your patience so I will look elsewhere. Thanks for your help, Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> Tom Eastep wrote: > >> How many times must I explain to you that Shorewall doesn''t change your >> routing table? > > This has all been very disheartening. > > In a world of unlimited time and money I would have the time to solve > this myself. I would have the time to become proficient in all of the > tools and concepts. However, I (like many other IT people I would > speculate) rarely have that luxury and sometimes have to rely on the > good will of others who have been there before and hopefully return the > favour when they are the ones who have been there before. > > I see I have exceeded your patience so I will look elsewhere.I''m sorry that you are giving up -- I realize that my bedside manner may leave something to be desired but I''m really a pretty good Doctor ;-) Be that at it may, if you wish to ''...look elsewhere'', it appears to me that there is a firewall between your Shorewall box and 161.184.172.35 that is dropping SYN,ACK packets from standard ports. Despite your opinion to the contrary, that sounds very much like the work of your ISP. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 3/19/07, Jon <me@jonwatson.ca> wrote:> Tom Eastep wrote: > > > How many times must I explain to you that Shorewall doesn''t change your > > routing table? > > This has all been very disheartening. > > In a world of unlimited time and money I would have the time to solve > this myself. I would have the time to become proficient in all of the > tools and concepts. However, I (like many other IT people I would > speculate) rarely have that luxury and sometimes have to rely on the > good will of others who have been there before and hopefully return the > favour when they are the ones who have been there before. > > I see I have exceeded your patience so I will look elsewhere.If you''re looking for a slightly more user-friendly network diagnostic tool, check out Ethereal instead of tcpdump. It captures the same information but presents it in a GUI view and labels things a little nicer. It''s available on Linux and Windows, so if you''re more comfortable with Windows you can go to a machine on the internet, install Ethereal, and capture your conversation with your server. Ethereal will produce pcap files, which you can upload somewhere so we can look at them, or post to the list directly if they''re small enough. Don''t give up yet - firewalls are not straightforward, and giving up won''t teach you anything. A bit more debugging is likely to show you the cause. Will ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Will Murnane wrote:> If you''re looking for a slightly more user-friendly network diagnostic > tool, check out Ethereal instead of tcpdump. It captures the sameThanks Will. Using Ethereal made it immediately apparent that Tom was right (big surprise) in that there are no ACKs coming back from the server in question. I didn''t make the "Your ISP is blocking SYN/ACK packets" leap because the server in question is not mine. Therefore "my ISP" to me means by rather tried and true connection which I knew be clean. Of course Tom wouldn''t know that and as soon as I realized that we could be talking about the other server, it all came together. The owner of that server does indeed have a "home" account and therefore it looks like ACKs are being blocked. I presume, anyhow, that''s what this type of trace shows? I am the 142. and the server in question is the 66. There are no other packets with those IPs in the trace and since I only see SYNs. I see other connections in the trace that show ACKs, just nothing involving these two IPs. I''m attaching a small screen cap (which may not make it) because Ethereal is giving me some stupid "you don''t have permission to move the capture file" error when I try to save it despite starting Ethereal as root. And...really...I''ve burned enough time on this. Thanks for the tip! Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 3/20/07, Jon <me@jonwatson.ca> wrote:> I didn''t make the "Your ISP is blocking SYN/ACK packets" leap because > the server in question is not mine. Therefore "my ISP" to me means by > rather tried and true connection which I knew be clean. Of course Tom > wouldn''t know that and as soon as I realized that we could be talking > about the other server, it all came together. The owner of that server > does indeed have a "home" account and therefore it looks like ACKs are > being blocked.Yep, no great surprise there. I wish ISPs wouldn''t filter my internet traffic at all, but that''s not likely to happen any time soon.> I presume, anyhow, that''s what this type of trace shows? I am the 142. > and the server in question is the 66. There are no other packets with > those IPs in the trace and since I only see SYNs. I see other > connections in the trace that show ACKs, just nothing involving these > two IPs.That''s correct. You could add a rule in the filtering with something like "host 66.222.148.326" and it''ll only show packets to or from that host.> Thanks for the tip!Glad to hear it helped. Will ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Will Murnane wrote:> Glad to hear it helped. >Thanks for continuing to help Jon, Will. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jon wrote:> > I presume, anyhow, that''s what this type of trace shows? I am the 142. > and the server in question is the 66. There are no other packets with > those IPs in the trace and since I only see SYNs. I see other > connections in the trace that show ACKs, just nothing involving these > two IPs.Provided that you can see the SYN,ACKs leaving 66.222.148.236, then dropped SYN,ACKs would seem to be the explanation. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV