On my router I have the following policy: loc net ACCEPT loc $FW ACCEPT loc all REJECT $FW net ACCEPT $FW loc REJECT $FW all REJECT net $FW DROP net loc DROP net all DROP all all REJECT and the following rules: DNAT net loc:192.168.0.3 tcp 50000 DNAT net loc:192.168.0.3 udp 50000 ACCEPT $FW loc icmp ACCEPT $FW net icmp And yet I''m able to ssh from a machine on the local network to the router via the external IP address. Does the router still know that I''m coming from the inside and thus allow it or is something wrong? Also a bittorrent client works on 192.168.0.3 even though I''m forwarding a different port than the one the client is set to listen on. How can that be? - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:> On my router I have the following policy: > > loc net ACCEPT > loc $FW ACCEPT > loc all REJECT > $FW net ACCEPT > $FW loc REJECT > $FW all REJECT > net $FW DROP > net loc DROP > net all DROP > all all REJECT > > and the following rules: > > DNAT net loc:192.168.0.3 tcp 50000 > DNAT net loc:192.168.0.3 udp 50000 > ACCEPT $FW loc icmp > ACCEPT $FW net icmp > > And yet I''m able to ssh from a machine on the local network to the > router via the external IP address. Does the router still know that > I''m coming from the inside and thus allow itOf course -- would you really want to use a firewall that was so easily outwitted?> > Also a bittorrent client works on 192.168.0.3 even though I''m > forwarding a different port than the one the client is set to listen > on. How can that be? >While I don''t use bittorrent, myself, IIRC the client will somewhat work with incoming connections blocked. -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > On my router I have the following policy: > > > > loc net ACCEPT > > loc $FW ACCEPT > > loc all REJECT > > $FW net ACCEPT > > $FW loc REJECT > > $FW all REJECT > > net $FW DROP > > net loc DROP > > net all DROP > > all all REJECT > > > > and the following rules: > > > > DNAT net loc:192.168.0.3 tcp 50000 > > DNAT net loc:192.168.0.3 udp 50000 > > ACCEPT $FW loc icmp > > ACCEPT $FW net icmp > > > > And yet I''m able to ssh from a machine on the local network to the > > router via the external IP address. Does the router still know that > > I''m coming from the inside and thus allow it > > Of course -- would you really want to use a firewall that was so easily > outwitted?Ok, sounds like no cause for alarm.> > Also a bittorrent client works on 192.168.0.3 even though I''m > > forwarding a different port than the one the client is set to listen > > on. How can that be? > > > > While I don''t use bittorrent, myself, IIRC the client will somewhat work > with incoming connections blocked.But how can it possibly do that? - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:>>> On my router I have the following policy: >>> >>> loc net ACCEPT >>> loc $FW ACCEPT >>> loc all REJECT >>> $FW net ACCEPT >>> $FW loc REJECT >>> $FW all REJECT >>> net $FW DROP >>> net loc DROP >>> net all DROP >>> all all REJECT >>> >>> and the following rules: >>> >>> DNAT net loc:192.168.0.3 tcp 50000 >>> DNAT net loc:192.168.0.3 udp 50000 >>> ACCEPT $FW loc icmp >>> ACCEPT $FW net icmp >>> >>> And yet I''m able to ssh from a machine on the local network to the >>> router via the external IP address. Does the router still know that >>> I''m coming from the inside and thus allow it >> Of course -- would you really want to use a firewall that was so easily >> outwitted? > > Ok, sounds like no cause for alarm. > >>> Also a bittorrent client works on 192.168.0.3 even though I''m >>> forwarding a different port than the one the client is set to listen >>> on. How can that be? >>> >> While I don''t use bittorrent, myself, IIRC the client will somewhat work >> with incoming connections blocked. > > But how can it possibly do that? >Because it''s primary connections are outgoing, not incoming. -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >>> On my router I have the following policy: > >>> > >>> loc net ACCEPT > >>> loc $FW ACCEPT > >>> loc all REJECT > >>> $FW net ACCEPT > >>> $FW loc REJECT > >>> $FW all REJECT > >>> net $FW DROP > >>> net loc DROP > >>> net all DROP > >>> all all REJECT > >>> > >>> and the following rules: > >>> > >>> DNAT net loc:192.168.0.3 tcp 50000 > >>> DNAT net loc:192.168.0.3 udp 50000 > >>> ACCEPT $FW loc icmp > >>> ACCEPT $FW net icmp > >>> > >>> And yet I''m able to ssh from a machine on the local network to the > >>> router via the external IP address. Does the router still know that > >>> I''m coming from the inside and thus allow it > >> Of course -- would you really want to use a firewall that was so easily > >> outwitted? > > > > Ok, sounds like no cause for alarm. > > > >>> Also a bittorrent client works on 192.168.0.3 even though I''m > >>> forwarding a different port than the one the client is set to listen > >>> on. How can that be? > >>> > >> While I don''t use bittorrent, myself, IIRC the client will somewhat work > >> with incoming connections blocked. > > > > But how can it possibly do that? > > > > Because it''s primary connections are outgoing, not incoming. > > > -TomBut how could anyone make a request of the machine if there are no ports forwarded to it? - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:> > But how could anyone make a request of the machine if there are no > ports forwarded to it?They couldn''t unless the connection were already established before the rules and/or port assignment was modified. -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > But how could anyone make a request of the machine if there are no > > ports forwarded to it? > > They couldn''t unless the connection were already established before the > rules and/or port assignment was modified. > > > -TomI''ve had a hefty upload rate on bittorrent for over a year with the same shorewall settings. The ports have never been forwarded properly. - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:>>> But how could anyone make a request of the machine if there are no >>> ports forwarded to it? >> They couldn''t unless the connection were already established before the >> rules and/or port assignment was modified. >> >> >> -Tom > > I''ve had a hefty upload rate on bittorrent for over a year with the > same shorewall settings. The ports have never been forwarded > properly.From http://btfaq.com/serve/cache/25.html "BitTorrent will usually work fine in a NAT (network address translation) environment, since it can function with only outbound connections. Such environments generally include all situations where multiple computers share one publicly-visible IP address, most commonly: computers on a home network sharing a cable or xDSL connection." -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:>On my router I have the following policy: > >loc net ACCEPT >loc $FW ACCEPT >loc all REJECT >$FW net ACCEPT >$FW loc REJECT >$FW all REJECT >net $FW DROP >net loc DROP >net all DROP >all all REJECT > >and the following rules: > >DNAT net loc:192.168.0.3 tcp 50000 >DNAT net loc:192.168.0.3 udp 50000 >ACCEPT $FW loc icmp >ACCEPT $FW net icmp > >And yet I''m able to ssh from a machine on the local network to the >router via the external IP address. Does the router still know that >I''m coming from the inside and thus allow it or is something wrong?Yes it knows, and it allows it because you''ve told it to : loc $FW ACCEPT>Also a bittorrent client works on 192.168.0.3 even though I''m >forwarding a different port than the one the client is set to listen >on. How can that be?Define ''works'' ? It won''t work fully, but it will work as long as enough peers are working correctly. You have this policy rule : loc net ACCEPT That allows the client to make outbound connections. It will be able to contact the tracker and find a list of potential peers - it can then make outbound connections to those peers AS LONG AS THEY ARE FULLY WORKING. What will fail is inbound connections, so other peers cannot connect to you and that means you will most likely NOT be able to seed once you have completed your download - tut tut. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> You have this policy rule : > loc net ACCEPT > > That allows the client to make outbound connections. It will be able > to contact the tracker and find a list of potential peers - it can > then make outbound connections to those peers AS LONG AS THEY ARE > FULLY WORKING. What will fail is inbound connections, so other peers > cannot connect to you and that means you will most likely NOT be able > to seed once you have completed your download - tut tut.How can I test that? I''ve done a whole lot of seeding and ended up with some really high ratios. - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Thu, Dec 13, 2007 at 06:42:03PM +0000, Simon Hobson wrote:> That allows the client to make outbound connections. It will be able > to contact the tracker and find a list of potential peers - it can > then make outbound connections to those peers AS LONG AS THEY ARE > FULLY WORKING. What will fail is inbound connections, so other peers > cannot connect to you and that means you will most likely NOT be able > to seed once you have completed your download - tut tut.I haven''t studied the matter closely, but my understanding is that most clients notice that their inbound path is broken, and simply start making connections to other peers at random and then try to send them stuff. On an active torrent, they won''t take long to find something to upload. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Grant wrote:> > You have this policy rule : >> loc net ACCEPT >> >> That allows the client to make outbound connections. It will be able >> to contact the tracker and find a list of potential peers - it can >> then make outbound connections to those peers AS LONG AS THEY ARE >> FULLY WORKING. What will fail is inbound connections, so other peers >> cannot connect to you and that means you will most likely NOT be able >> to seed once you have completed your download - tut tut. > >How can I test that? I''ve done a whole lot of seeding and ended up >with some really high ratios.I''ve only used Azureus so can''t comment on any other programs or protocols other than Bittorrent. Also, this is one of those things I have set up on a computer in the back room, I just drop torrent files into it''s watch folder and leave it to get on with it - so it''s a while since I''ve fiddled with any of this stuff ... Azureus has, IIRC, a function to test your NAT setup, and flags up if it isn''t working (an amber or red NAT status light in the main window ?) Also, when you are downloading or seeding, double clicking on a torrent brings up the details, and on the peers tab it has a column to show whether the connection was inbound or outbound - if you only ever have inbound connections then that''s an indication that you don''t have your port forwarding configured right. Sorry to be a bit vague, but I''m not that familiar with troubleshooting these problems, I''m more used to just setting them up right - cue smug expression ;-) This isn''t really a Shorewall issue, you will probably get better information from the resources dedicated to the application you are using - working through NAT and firewall is probably THE no1 issue, so there WILL be help available for dealing with the problems ! ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Andrew Suffield wrote:> > I haven''t studied the matter closely, but my understanding is that > most clients notice that their inbound path is broken, and simply > start making connections to other peers at random and then try to send > them stuff. On an active torrent, they won''t take long to find > something to upload. >I''ve been playing with this thing and have found one anomaly in the Azureus NAT/Firewall test. The Azureus client first establishes an HTTP connection (port 80) to a remote host. The remote host then attempts to establish a TCP connection back the the originator of the HTTP connection. This of course can go stupidly wrong if there is an HTTP proxy. -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > That allows the client to make outbound connections. It will be able > > to contact the tracker and find a list of potential peers - it can > > then make outbound connections to those peers AS LONG AS THEY ARE > > FULLY WORKING. What will fail is inbound connections, so other peers > > cannot connect to you and that means you will most likely NOT be able > > to seed once you have completed your download - tut tut. > > I haven''t studied the matter closely, but my understanding is that > most clients notice that their inbound path is broken, and simply > start making connections to other peers at random and then try to send > them stuff. On an active torrent, they won''t take long to find > something to upload.If that is how it works then that would explain it. - Grant ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> > I''ve been playing with this thing and have found one anomaly in the Azureus > NAT/Firewall test. The Azureus client first establishes an HTTP connection > (port 80) to a remote host. The remote host then attempts to establish a TCP > connection back the the originator of the HTTP connection. This of course > can go stupidly wrong if there is an HTTP proxy. >In my case, I''m running Asureus on a system that uses one-to-one NAT to 206.124.146.178. I use a transparent proxy whose local IP address is 206.124.146.176. I have worked around the problem by adding the Azureus address block (81.19.16.0/21) to the exclusion list in my REDIRECT rule. YMMV, -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: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace