Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Wednesday 12 February 2003 10:44 pm, Tom Eastep wrote: snip Here is the connection tracking table: udp 17 177 src=192.168.1.1 dst=12.77.140.250 sport=1347 dport=1193 src=12.77.140.250 dst=12.243.227.207 sport=1193 dport=1347 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1348 dport=1039 src=12.77.140.250 dst=12.243.227.207 sport=1039 dport=1348 [ASSURED] use=1 udp 17 18 src=10.175.0.1 dst=255.255.255.255 sport=67 dport=68 [UNREPLIED] src=255.255.255.255 dst=10.175.0.1 sport=68 dport=67 use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1037 dport=1194 src=12.77.140.250 dst=12.243.227.207 sport=1194 dport=1037 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1349 dport=1040 src=12.77.140.250 dst=12.243.227.207 sport=1040 dport=1349 [ASSURED] use=1 tcp 6 431989 ESTABLISHED src=192.168.1.1 dst=216.187.103.211 sport=1304 dport=5501 src=216.187.103.211 dst=12.243.227.207 sport=5501 dport=1304 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1038 dport=1195 src=12.77.140.250 dst=12.243.227.207 sport=1195 dport=1038 [ASSURED] use=1 The ICMP 11,0 packets in the log are explained by the third entry which suggests that the culprit is a DHCP client using an RFC 1918 source address. 216.187.103.211 is chat.eyeball.com - the EyeBall Chat server. Sean's IP address is 12.243.227.207 and 12.77.140.250 is Mom's IP address. So: a) The Magic Technology worked without any races on Sean's end (we didn't see any denied packets). b) The 5 UDP connections between Sean and Mom are as described in the EyeBall documentation. c) Sean -- is the AOL subscriber that you mention able to connect with EyeBall users other than yourself? I think most, if not all, of AOL services are proxy'ed and likely VPN'ed as well the last time I looked. I know a lot of services are not working as advertised on AOL, especially when the connection is to the internet at-large. Maybe their proxy messes this up. I would still like to get your tcpdump capture Sean to see if Ray's conjecture is correct. I would to. It would be quite interesting to see how the connection is setup initally w/o port-fw'ing. It's not breaking in the NAT ports, so this must be application specific, especially with use of TCP . Very interesting! ;-) Thanks, -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
I'd be more than willing to help debug this. I have both the Dachstein and Bering firewalls setup, I just switch the cables and I'm set to go. If you want specifics of the setups, tell me what you need and I'll send it to you. Eyeball Chat says it does NOT use H323 (is that the correct number?) video conferencing protocol, so I'm not sure that Dachstein's ipmasq setting would have helped. I am using the Dachstein CD 1.02. I added some rules for SSH and VNC. I did nothing specific for Eyeball Chat. I can send whatever config files you might want. I was using Bering Stable, with Shorewall 1.3.12a. I upgraded the shorewall to 1.3.14 last night. I haven't tried Eyeball since the upgrade. I used the 2 nic version and added some DNAT for ssh and VNC. Let me know what you want me to log on each firewall and I'll give it a go. I'd like to avoid opening ports, esp. since its a p2p app, and who would I open them for? My inlaws are on dial-up. I've seen posts on Google Groups of users saying it just worked through their firewall when other apps didn't. What I like is that it compresses video and audio so it is usable on a dial-up connection. Ray, I'll attempt some connections tonight (If I get a chance) and send the output from Dachstein and Bering that you suggested. Sean There is something that we are missing here regarding the difference between his Dachstein and Bering configurations. Not only would these high ports have to have been open but they would have to have been forwarded to the internal machine running his P2P application. That would have required an explicit configuration action on his part. I *think* this assertion is incorrect. The firewall paper Sean referred us to *seems* to be describing a workaround for exactly this requirement. I don't fully understand how they do it (either the paper intentionally omits some key technical detail, or I just missed it). Lynn's suggestion above, a more succinct expression of the thought I talked about in rambly form, is probably closer to the target. The exception would be if the application is built on some standard technology like IRC where a masquerade module is available on Dachstein but not on Bering. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
BTW, I did send Eyeball Chat a help request, but since it is free software, I'm not holding my breath. I'm willing to pursue this just to see if this magic silver bullet they have going actually works. Strange that they have instructions on how to blow holes in your firewall (static patch) if their magic firewall approach works so well... On Wed, 2003-02-12 at 09:37, Tom Eastep wrote: Sean E. Covel wrote: I'd be more than willing to help debug this. I have both the Dachstein and Bering firewalls setup, I just switch the cables and I'm set to go. If you want specifics of the setups, tell me what you need and I'll send it to you. Under Bering: a) shorewall reset b) Try to connect c) shorewall status /tmp/status d) Send us the /tmp/status file. Eyeball Chat says it does NOT use H323 (is that the correct number?) video conferencing protocol, so I'm not sure that Dachstein's ipmasq setting would have helped. Something clearly did. I am using the Dachstein CD 1.02. I added some rules for SSH and VNC. I did nothing specific for Eyeball Chat. I can send whatever config files you might want. They won't mean anything to me but they probably will to Ray. I was using Bering Stable, with Shorewall 1.3.12a. I upgraded the shorewall to 1.3.14 last night. I haven't tried Eyeball since the upgrade. I used the 2 nic version and added some DNAT for ssh and VNC. Let me know what you want me to log on each firewall and I'll give it a go. I'd like to avoid opening ports, esp. since its a p2p app, and who would I open them for? My inlaws are on dial-up. The ultimate solution is probably going to be that you will have to forward some additional ports. If that's unacceptable to you then we may as will not persue this. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Sean E. Covel wrote: BTW, I did send Eyeball Chat a help request, but since it is free software, I'm not holding my breath. I'm willing to pursue this just to see if this magic silver bullet they have going actually works. Strange that they have instructions on how to blow holes in your firewall (static patch) if their magic firewall approach works so well... I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. That little trick will not work with Shorewall because the NetFilter connection tracking table identifies connection endpoints by (ip,protocol,port) rather than just by (protocol,port). So just because EyeBall running on 192.168.12.12 is connected to the EyeBall server via external address w.x.y.z and port P doesn't mean that EyeBall user at address a.b.c.d can open port P on w.x.y.z and be able to successfully connect through the firewall to 192.168.12.12. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Tom, I'm a complete iptables noob, and you are obviously an expert at this point. Eyeball Chat does claim that it works with iptables. Is the connection tracking table a recent addition? Can you think of what might have to be done for it to work with iptables? If they ever get back to me about this, I'll be sure to let you know! Sean On Wed, 2003-02-12 at 10:13, Tom Eastep wrote: Sean E. Covel wrote: BTW, I did send Eyeball Chat a help request, but since it is free software, I'm not holding my breath. I'm willing to pursue this just to see if this magic silver bullet they have going actually works. Strange that they have instructions on how to blow holes in your firewall (static patch) if their magic firewall approach works so well... I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. That little trick will not work with Shorewall because the NetFilter connection tracking table identifies connection endpoints by (ip,protocol,port) rather than just by (protocol,port). So just because EyeBall running on 192.168.12.12 is connected to the EyeBall server via external address w.x.y.z and port P doesn't mean that EyeBall user at address a.b.c.d can open port P on w.x.y.z and be able to successfully connect through the firewall to 192.168.12.12. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 07:13 AM 2/12/03 -0800, Tom Eastep wrote: Sean E. Covel wrote: BTW, I did send Eyeball Chat a help request [...] I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. Tom -- Can you expand on this just a little bit more? (Or Lynn, can you?) This conclusion is kind of where I got to last night, but only for TCP. What is the equivalent of SYN packet detection for UDP? Or, to put it another way, how does iptables (or Shorewall) determine the state associated with a UDP packet? I can't figure it out from the iptables docs I have. And Sean ... if you are really willing to put in the work needed to pin ghtis down for sure, I think you're going to need to run a packet sniffer on the router's external interface. This will let you sort out both the state issue that Tom, Lynn, and I have all raised (though our terminology has varied) and the then a miracle happens elements of their slightly obscure explanation of how their trick works (how does the client figure out what port the p2p connections has been MASQ'd to and communicate it to the EyeBall server? is the one that has me stumped). -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Ray Olszewski wrote: At 07:13 AM 2/12/03 -0800, Tom Eastep wrote: Sean E. Covel wrote: BTW, I did send Eyeball Chat a help request [...] I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. Tom -- Can you expand on this just a little bit more? (Or Lynn, can you?) This conclusion is kind of where I got to last night, but only for TCP. What is the equivalent of SYN packet detection for UDP? Or, to put it another way, how does iptables (or Shorewall) determine the state associated with a UDP packet? I can't figure it out from the iptables docs I have. It's actually easier for UDP since UDP is connectionless. Applications can simply send a datagram to (external_ip,external_port). If the port is in the masquerade range, then it will be open and if the EyeBall client running on (internal_ip) has established a port mapping entry in the firewall of (external_port,internal_port) by having sent a datagram to the EyeBall server (who notes the external_port), then the incoming packets will sail right through. After having given it some more thought, I don't believe that the same trick will work with TCP because it would require the EyeBall application to listen() on a connected socket. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 08:41 AM 2/12/03 -0800, Tom Eastep wrote: Ray Olszewski wrote: At 07:13 AM 2/12/03 -0800, Tom Eastep wrote: Sean E. Covel wrote: BTW, I did send Eyeball Chat a help request [...] I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. Tom -- Can you expand on this just a little bit more? (Or Lynn, can you?) This conclusion is kind of where I got to last night, but only for TCP. What is the equivalent of SYN packet detection for UDP? Or, to put it another way, how does iptables (or Shorewall) determine the state associated with a UDP packet? I can't figure it out from the iptables docs I have. It's actually easier for UDP since UDP is connectionless. Applications can simply send a datagram to (external_ip,external_port). If the port is in the masquerade range, then it will be open and if the EyeBall client running on (internal_ip) has established a port mapping entry in the firewall of (external_port,internal_port) by having sent a datagram to the EyeBall server (who notes the external_port), then the incoming packets will sail right through. After having given it some more thought, I don't believe that the same trick will work with TCP because it would require the EyeBall application to listen() on a connected socket. Yeah, this was my reasoning too (though my thinking about TCP is a bit more involved). And in reading between the lines a bit, I pretty much inferred that EyeBall uses UDP for the p2p part, and TCP only for the connection to the EyeBall server (where no trickery is needed). But it still leaves unanswered one question that I really would appreciate your (or somebody's -- Lynn?) help with: iptables lets me specify state rules for ACCEPTing all packet types, not just TCP. For UDP, what test does ipchains apply to a packet to classify it as NEW, ESTABLISHED, RELATED, or INVALID? I see nothing in the UDP spec that it can use (for NEW vs ESTABLISHED, specifically). Is this a bogus capability, or is there some neat trick that I cannot fathom? -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Ray Olszewski wrote: But it still leaves unanswered one question that I really would appreciate your (or somebody's -- Lynn?) help with: iptables lets me specify state rules for ACCEPTing all packet types, not just TCP. For UDP, what test does ipchains apply to a packet to classify it as NEW, ESTABLISHED, RELATED, or INVALID? I see nothing in the UDP spec that it can use (for NEW vs ESTABLISHED, specifically). Is this a bogus capability, or is there some neat trick that I cannot fathom? See: http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Tom -- Can you expand on this just a little bit more? (Or Lynn, can you?) This conclusion is kind of where I got to last night, but only for TCP. What is the equivalent of SYN packet detection for UDP? Or, to put it another way, how does iptables (or Shorewall) determine the state associated with a UDP packet? I can't figure it out from the iptables docs I have. That's because it doesn't have one - UDP is connectionless and stateless. each packet is atomic in itself, and independent of a handshake or index in a packet stream. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Wednesday 12 February 2003 11:05 am, Ray Olszewski wrote: Yeah, this was my reasoning too (though my thinking about TCP is a bit more involved). And in reading between the lines a bit, I pretty much inferred that EyeBall uses UDP for the p2p part, and TCP only for the connection to the EyeBall server (where no trickery is needed). OK, Dachstein doesn't filter any high UDP ports which leaves the NAT'ing udp ports open for connection Shorewall does through the conntrack filter. I'm assuming the TCP portion of the connection (and possibly the UDP connetion setup) is done through Eyeball's server. This will also work with iptables if conntrack is NOT loaded, and also what I imagine the Eyeball doc eludes to. But it still leaves unanswered one question that I really would appreciate your (or somebody's -- Lynn?) help with: iptables lets me specify state rules for ACCEPTing all packet types, not just TCP. For UDP, what test does ipchains apply to a packet to classify it as NEW, ESTABLISHED, RELATED, or INVALID? I see nothing in the UDP spec that it can use (for NEW vs ESTABLISHED, specifically). Is this a bogus capability, or is there some neat trick that I cannot fathom? I don't think it does, I believe they sniff the connection through their application and locate the NAT port that is being used on the remote firewall(s). I don't believe there is a SYN-type UDP packet involved in the connection. But this is merely a WAG. I really am not seeing anything that Tom hasn't stated and I haven't gone through any white-papers on this type of exploit (connection). ;-) It will definately be interesting if there is something else involved though.. I would like to hear about it as well! -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Let me first apologize to everyone here except (I hope) Lynn and Tom. This is a somewhat tedious thread for leaf-user (it might be better suited to leaf-devel). But I think it is important to sort out why the EyeBall service works with Dachstein (ipchains) but not Bering/Shorewall (iptables), so we can give good advice when similar questions come up in the future (and I've no doubt they will ... if this technique works at all well, the p2p crowd will flock to it). In the movie The Heist, at one point Gene Hackman's character is asked: How do you figure out these schemes? or something like that. He replies, approximately: I just pretend that I'm someone smarter than me, and I ask myself how he'd do it. In trying to translate the method outlined in the Any-Firewall White Paper into concrete terms, I felt like I was trying to do the same thing. But the conntrack reference Tom provided gave me, I think, the last clue I needed to figure out how such a service *could* work through a NAT'ing firewall, even a stateful firewall. Since Sean's experience is that it does not work with Bering/Shorewall, something is missing still. I'm writing this outline in the hope that someone can either spot the mistake or spot the Bering/Shorewell setting that makes it not work. Terminology: EyeBall is a p2p service, so we have Peer A and Peer B, both behind NAT'ing firewall/routers, and identical except for having different router external IP addresses. We also have EyeBall Server, able to accept TCP and UDP connections at an address:port the EyeBall software knows. Arbitrarily, Peer A will be the one to initiate the connection. Here's what happens behind the curtain: 1. When Peer A starts, it opens a TCP connection to EyeBall Server. Nothing tricky about this. It also does whatever it needs to to keep the connection open (mainly needing to cope with MASQ timeouts and changing dynamic router addresses, also old hat stuff) for as long as the Peer A EyeBall application is running. 2. Peer B does the same thing. These connections mean that EyeBall Server can send instructions and information to both Peers. And the EyeBall Server now knows the external IP addresses of both Peers (as well as whatever the software itself provides in the way of identification). 3. Peer A tries to initiate a connection to Peer B. I don't know how it finds Peer B, but this too is a conventional problem with conventional solutions in the p2p world ... a buddy list, say, which may involve using the established TCP connections to find that Peer B is open for business. Anyway, somehow it finds Peer B and its external IP address. 4. Peer A opens a UDP socket and sends a UDP message to EyeBall Server telling it the IP address (and maybe other info) of the client (Peer B) it wishes to connect to. It may also send additional information via the TCP connection to EyeBall Server. This UDP message is NAT'd, and EyeBall Server sees the NAT port it comes from. 5. EyeBall Server sends (over the established TCP channel) to Peer B instructions to open a UDP connection to the NAT'd UDP port on Peer A that step 4 identified to EyeBall Server. 6. Peer B opens a UDP socket and sends a UDP message to EyeBall Server acknowledging the instructions in 5 (and maybe some additional response on the TCP connection). EyeBall server now knows the NAT'd port that Peer B is using. 7. EyeBall Server sends (over the established TCP channel) to Peer A instructions to open a UDP connection to Peer B at the NAT'd UDP port on Peer B that step 6 identified to EyeBall Server. 8. (Tricky part.) Peer B now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer A. 9. (Tricky part, part 2.) Peer A now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer B. Now, there will be some initial timing issues, so each end has to send the other a few filler UDP packets to start with. But after a short time, each Peer will have sent a UDP packet to the other and then received a UDP packet from the other ... meeting the definition of ESTABLISHED UDP connection in the iptables reference Tom provided. It seems to me that this should work, if a hidden assumption (the tricky part) in steps 8 and 9 is true -- namely, that when each Peer's UDP socket switches destination address:port, iptables continues to MASQ it at the same port. I don't know if this is true for iptables (or for ipchains), but if it isn't, I can't come up with a reasonable way for EyeBall Server to figure out what NAT'd port each Peer is using. The Peer itself has no way to know, so it can't tell EyeBall Server. Someone suggested that EyeBall Server port-scans the Peer's external IP address ... but we know how unreliable port scans are for UDP, not to mention how many red flags would go up if they did this routinely ... so I'm skeptical of that guess. Once again, this is still all guesswork, based on nothing
Re: [leaf-user] Bering/Shorewall vs. Dachstein
8. (Tricky part.) Peer B now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer A. 9. (Tricky part, part 2.) Peer A now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer B. Those tricky parts are standard when using UDP. Now, there will be some initial timing issues, so each end has to send the other a few filler UDP packets to start with. But after a short time, each Peer will have sent a UDP packet to the other and then received a UDP packet from the other ... meeting the definition of ESTABLISHED UDP connection in the iptables reference Tom provided. It seems to me that this should work, if a hidden assumption (the tricky part) in steps 8 and 9 is true -- namely, that when each Peer's UDP socket switches destination address:port, iptables continues to MASQ it at the same port. I don't know if this is true for iptables (or for ipchains), but if it isn't, I can't come up with a reasonable way for EyeBall Server to figure out what NAT'd port each Peer is using. The Peer itself has no way to know, so it can't tell EyeBall Server. Someone suggested that EyeBall Server port-scans the Peer's external IP address ... but we know how unreliable port scans are for UDP, not to mention how many red flags would go up if they did this routinely ... so I'm skeptical of that guess. The key difference again between ipchains and iptables is that when the destination IP address changes from the EyeBall server to the other Peer, Netfilter considers that to be a NEW CONNECTION whereas ipchains does not. Furthermore, since the source IP, protocol and port duplicate the ones in the peer-server connection tracking entry, that entry is removed! So when UDP packets from the other peer arrive, there is no connection tracking entry that they match and they are considered NEW. Unless there are port forwarding rules in place, these NEW packets are rejected (or probably dropped) by the firewall. I'm sure that Sean's Bering box is logging these when he tries to connect. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 11:34 AM 2/12/03 -0800, Tom Eastep wrote: 8. (Tricky part.) Peer B now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer A. 9. (Tricky part, part 2.) Peer A now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer B. [...] The key difference again between ipchains and iptables is that when the destination IP address changes from the EyeBall server to the other Peer, Netfilter considers that to be a NEW CONNECTION whereas ipchains does not. Furthermore, since the source IP, protocol and port duplicate the ones in the peer-server connection tracking entry, that entry is removed! So when UDP packets from the other peer arrive, there is no connection tracking entry that they match and they are considered NEW. Unless there are port forwarding rules in place, these NEW packets are rejected (or probably dropped) by the firewall. Are you sure? Look at my steps 8 and 9 in closer focus. 8a. Peer B sends the first UDP packet to the NAT'd port at Peer A. This has two effects: -- starts a NEW outgoing UDP connection on Peer B -- packet is REJECTed or DENYed at Peer A 9a. Peer A simultaneously sends the first UDP packet to the NAT'd port at Peer B. This has two effects: -- starts a NEW outgoing UDP connection at Peer A -- packet is REJECTed or DENYed at Peer B 8b. Peer B sends the second UDP packet to the NAT'd port at Peer A. This: -- continues the NEW outgoing connection at Peer B created in step 8a. -- causes the NEW connection at Peer A to become ESTABLISHED, since the response comes from the correct address:port at Peer B 9b. Peer A sends the second UDP packet to the NAT'd port at Peer B. This: -- continues the NEW outgoing connection at Peer A created in step 9a. -- causes the NEW connection at Peer B to become ESTABLISHED, since the response comes from the correct address:port at Peer A All subsequent packets go through since both ends are now ESTABLISHED. Of course, real-world latencies will make the exchange less tidy, so more than four packets will usually be needed to make this work. But it *seems* to be consistent with the conntrack rules for UDP connections in the reference you sent. What am I missing here? One possibility I can think of is that the Any-Firewall protocol tries to continue communication over this same UDP socket to both the EyeBall Server and the Peer ... which you indicate will keep clearing the conntrack entry from the table. This behavior should be fixable by EyeBall, if that's the only problem (the EyeBall Server has the TCP connection so doen't really need this UDP connection for any purpose once it has identified the NAT port). Another is that a REJECT response clears the conntrack table (if Shorewall REJECTs rather than DENYs), so this dodge ball packet-flinging trick is never able to get to the ESTABLISHED state. I doubt this has a workaround on the EyeBall side. The third is that your explanation includes the (unstated) detail that when the destination IP address changes, Netfilter switches to a new MASQ port. This was the undertainty I raised in my prior message, my reason for calling these steps tricky. If that is what you meant to imply, then you are right that it is hopeless (but I then wonder in what sense EyeBall even thinks its system works with iptables). Or am I misunderstanding your explanation and so missing something obvious? -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
Tom wrote: I just read their Magic Bullet paper and I think that it works with Dachstein because on Dachstein (as with Seawall), the Masquerade Port Range is left open by the firewall. This allows incoming SYN packets to sail right through the firewall AND will even route it to the correct internal system. It is a cute trick except that it is based on being able to exploit the primative capabilities of ipchains. I only want to point out that Dachstein does not only open (not forward, only open) all ports in the Masquerade port range, it opens all TCP and UDP ports from 1024 to 65535. Perhaps this statement helps finding the problem. I don't know if this helps and I can't say more about the EyeBall problem because I know too less about how p2p tools like kazaa (and EyeBall) etc. works. so long -- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch| http://leaf.sourceforge.net/devel/sminola --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Ray Olszewski wrote: At 11:34 AM 2/12/03 -0800, Tom Eastep wrote: 8. (Tricky part.) Peer B now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer A. 9. (Tricky part, part 2.) Peer A now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer B. [...] The key difference again between ipchains and iptables is that when the destination IP address changes from the EyeBall server to the other Peer, Netfilter considers that to be a NEW CONNECTION whereas ipchains does not. Furthermore, since the source IP, protocol and port duplicate the ones in the peer-server connection tracking entry, that entry is removed! So when UDP packets from the other peer arrive, there is no connection tracking entry that they match and they are considered NEW. Unless there are port forwarding rules in place, these NEW packets are rejected (or probably dropped) by the firewall. Are you sure? Look at my steps 8 and 9 in closer focus. 8a. Peer B sends the first UDP packet to the NAT'd port at Peer A. This has two effects: -- starts a NEW outgoing UDP connection on Peer B -- packet is REJECTed or DENYed at Peer A 9a. Peer A simultaneously sends the first UDP packet to the NAT'd port at Peer B. This has two effects: -- starts a NEW outgoing UDP connection at Peer A -- packet is REJECTed or DENYed at Peer B 8b. Peer B sends the second UDP packet to the NAT'd port at Peer A. This: -- continues the NEW outgoing connection at Peer B created in step 8a. -- causes the NEW connection at Peer A to become ESTABLISHED, since the response comes from the correct address:port at Peer B 9b. Peer A sends the second UDP packet to the NAT'd port at Peer B. This: -- continues the NEW outgoing connection at Peer A created in step 9a. -- causes the NEW connection at Peer B to become ESTABLISHED, since the response comes from the correct address:port at Peer A Ah -- yes, now I see what you are getting at. Yet, it's apparently not working -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Tom Eastep wrote: Ah -- yes, now I see what you are getting at. Yet, it's apparently not working I'm trying to keep up with this thread while at the same time following a distributed training exercise on another monitor. During the lunch break, I got a chance to look at what Ray wrote more closely :-) One other thing to remember is that because Netfilter tracks (ip,protocol[,port]), it usually doesn't have to remap ports the way that ipchains does. So the external port shouldn't change when the peers switch from sending to the server to sending to their opposite. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
So, after much discussion, is there anything specific you would like me to do Shorewall before I gather statistics? I can shut off all my other machines and turn on/off everything/nothing, logg everything...whatever. Just let me know what. How about Dachstein? I'll be making my attempt in about 3 hours (8:30 est) after the young one goes to bed. I've got to find a patient relative who will put up with my trouble-shooting. Let me know, Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Eastep Sent: Wednesday, February 12, 2003 3:46 PM To: Ray Olszewski Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Bering/Shorewall vs. Dachstein Tom Eastep wrote: Ah -- yes, now I see what you are getting at. Yet, it's apparently not working I'm trying to keep up with this thread while at the same time following a distributed training exercise on another monitor. During the lunch break, I got a chance to look at what Ray wrote more closely :-) One other thing to remember is that because Netfilter tracks (ip,protocol[,port]), it usually doesn't have to remap ports the way that ipchains does. So the external port shouldn't change when the peers switch from sending to the server to sending to their opposite. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Sean wrote: So, after much discussion, is there anything specific you would like me to do Shorewall before I gather statistics? I can shut off all my other machines and turn on/off everything/nothing, logg everything...whatever. Just let me know what. How about Dachstein? I'll be making my attempt in about 3 hours (8:30 est) after the young one goes to bed. I've got to find a patient relative who will put up with my trouble-shooting. For a first shot on Bering, I think that the procedure that I outlined before is still appropriate. If you have tcpdump on the Dachstein box, I'd love to capture everything that happens on your remote interface during a successful connection. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 02:45 PM 2/12/03 -0800, Tom Eastep wrote: Sean wrote: So, after much discussion, is there anything specific you would like me to do Shorewall before I gather statistics? I can shut off all my other machines and turn on/off everything/nothing, logg everything...whatever. Just let me know what. How about Dachstein? I'll be making my attempt in about 3 hours (8:30 est) after the young one goes to bed. I've got to find a patient relative who will put up with my trouble-shooting. For a first shot on Bering, I think that the procedure that I outlined before is still appropriate. I agree, with one possible addition (I'm not sure quite how much shorewall status /tmp/status reports). I'd like to see a report on MASQ'd connections while you are trying to make an EyeBall connection (the equivalent command to netstat -M on 2.2.x kernels - Tom, do you know offhand what the command is for 2.4.x kernels, I can't remember). If you have tcpdump on the Dachstein box, I'd love to capture everything that happens on your remote interface during a successful connection. Me too (for that matter, I'd like to see this for the Bering/Shorewall connection failure too). In the long run, I think we're going to need this level of info to pin the exact problem, and I hope a solution, down. But if you don't have tcpdump, I'd settle for your running netstat -M /tmp/msaq_ports.txt ipchains -NVL /tmp/ipchains_rulesets.txt while the connection is active, then sending us the resulting files. -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Ray Olszewski wrote: At 02:45 PM 2/12/03 -0800, Tom Eastep wrote: For a first shot on Bering, I think that the procedure that I outlined before is still appropriate. I agree, with one possible addition (I'm not sure quite how much shorewall status /tmp/status reports). I'd like to see a report on MASQ'd connections while you are trying to make an EyeBall connection (the equivalent command to netstat -M on 2.2.x kernels - Tom, do you know offhand what the command is for 2.4.x kernels, I can't remember). Ray -- Everything you could possibly want is in shorewall status :-) -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Sean wrote:
Son of a ...
It worked first try. 2 changes from last time. I went from Shorewall
1.3.12a to 1.3.4. I connected to a MSN user, not an AOL user. Don't
know if either made a difference. I'll send you the shorewall status
file anyway. I didn't bother with the Dachstein ('cause my mother felt
like talking ;-) Let me know if you still want that info. I do have
tcpdump on my CD. Tom, I can't wait to hear your analysis of their
MAGIC technology.
Actually, I believe that Ray probably had it nailed perfectly in his
analysis. The key is that both peers are trying to connect to each other
at the same time using the other's external port.
I'm curious if you see some dropped UDP packets being logged about the
time of the connection and would like to at least get the shorewall
status output. Such dropped packets would be consistent with Ray's
analysis. If we don't see the dropped packets then I would like to look
at the packet trace to see what exactly is going on.
Thanks,
-Tom
--
Tom Eastep\ Shorewall - iptables made easy
Shoreline, \ http://www.shorewall.net
Washington USA \ [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
Thanks for your responses. After spending more time on their website, sarcasm I discovered their Any-Firewall-Whitepaper where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT./sarcasm Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only outgoing connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle. Thanks, Sean Snip--- The solution was posted on their website. Apparently by default it uses dynamic UDP and TCP but there is a static port patch for v2.2 located here: http://www.eyeballchat.com/download/patches/fixed_ports_patch22.reg Then you need to open up these ports: - UDP ports 5700, 5701 and 5702 and - TCP ports 5500 and 5501. Eyeball Chat should then work correctly. snip--- I use an app, EyeBall chat, to video chat to relatives. It worked just fine under Dachstein. It is NOT working under Bering. It appears the app uses a number of dynamic UDP and TCP connections for the audio/video portions of the chat. I didn't see anything in the shorewall logs that was helpful. Anyone got any thoughts? Snip--- I would imagine that since it worked with Dachstein, there was probably some high port UDP traffic that iptables stops with conntrack (statefule connection tracking). -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Tuesday 11 February 2003 07:53 pm, Sean wrote: Thanks for your responses. After spending more time on their website, sarcasm I discovered their Any-Firewall-Whitepaper where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT./sarcasm That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only outgoing connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle. Really the largest security risk in doing this is highly dependant on the application listening on these ports. You'll probably need to portfw the TCP ports at a minimum for the remote side to initiate a connection, but I may be wrong in this assumption w/o trying the application first. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Lynn Avants wrote: That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. There is something that we are missing here regarding the difference between his Dachstein and Bering configurations. Not only would these high ports have to have been open but they would have to have been forwarded to the internal machine running his P2P application. That would have required an explicit configuration action on his part. The exception would be if the application is built on some standard technology like IRC where a masquerade module is available on Dachstein but not on Bering. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
At 08:53 PM 2/11/03 -0500, Sean wrote: Thanks for your responses. After spending more time on their website, sarcasm I discovered their Any-Firewall-Whitepaper where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT./sarcasm Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only outgoing connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle. I've been watching this one from the sidelines, mostly because the information I found at EyeBallChat site was mostly bafflegab (except for the static ports stuff Lynn had already directed you to). I don't know this service ... but usually with p2p, *somebody* needs to be able to accept connections. Either half of each pair needs this ability (I believe Direct Connect, for example, works this way), or the system relays through a central site to bypass firewalling problems (I believe GoToMyPC, for example, works this way) ... making it not really p2p, of course. From reading the Firewalling White Paper you alluded to, it becomes clear that EyeBallChat adopts a mixed approach,one somewhat similar to the hub portion of popular p2p packages but a bit more capable in that it can handle identifying the IP address and source port on the fly. This is actually a neat workaround. (Anyone curious can find the White Paper at http://www.eyeball.com/solutions/Any-FirewallWhitePaper.pdf -- it is actually interesting.) Reading this paper suggests to me that you shouldn't actually need to adopt the static-port solution ... fortunately, since they don't define open up and I'm having trouble guessing what they mean by the term (probably port forward, but I'm way far from sure). The While Paper claims their standard approach works with both ipchains and iptables, and since it did work for you with Dachstein (=ipchains), I'm inclined to believe them, at least provisionally. So, I suggest you tell us a bit more, namely: 1. What were the high UDP ports used by Dachstein? I'm guessing they were in the range (roughly 6-65000) Linux kernels use for outgoing NAT'd connections. And were there *really* only UDP ports ... no TCP? 2. On Bering, what does your firewall ruleset look like? We just care about the forwarding parts, but this is divided between two tables, so we need to see iptables -t nat -nvL iptables -t filter -nvL or the built-in Shorewall equivalents (which I continue to forget, no matter how many times Mike reminds me). Run these commands *after* an unsuccessful attempt with EyeBallChat, so we can look for rules that blocked a bunch of packets. It is now sounding to me like Shorewall (or conceivably some other kernel setting) is doing something specific to block you, and we need more than the blather that EyeBallChat provides to figure out what. 3. Do you still have the Dachstein firewall running anywhere? If so, it would be instructive to see its rulesets too: ipchains -nvL I suppose it is possible that the EyeBallChat solution sorts out the address/port stuff right, but leaves both ends with the impression that they are initiating the connection. This could cause incoming TCP packets (if it uses TCP, as the static solution appears to) to have the wrong flags set, and so be blocked by Shorewall seeing them as NEW rather than ESTABLISHED (the Dach firewall may not have checked for this). It is unclear to me if there might be a similar problem with UDP ... UDP itself has no concept of a connection, but the iptables documentation is a bit inexact about how an iptables kernel decides if a UDP packet is NEW, ESTABLISHED, or one of the other states (and I don't really recall if ipchains even has these concepts for UDP traffic). If it is the problem, it would be worth calling it to their attenton, since it represents a weakness in their trademarked solution that they will want to fix (or at least, I hope, feel obliged to disclose). This part is just speculation, though. If you do end up using the static-port solution, and if open up really means port forward ... then the risk you run is that the EyeBallChat software itself has a security hole. It is the same risk you run every time you port forward to a server running a service, or a p2p app that uses fixed ports, on your LAN or DMZ. This is not really a LEAF, or even a Linux, question ... I suggest you turn to third-party EyeBallChat commentary to assess this. -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] ---
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 07:14 PM 2/11/03 -0800, Tom Eastep wrote: Lynn Avants wrote: That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. There is something that we are missing here regarding the difference between his Dachstein and Bering configurations. Not only would these high ports have to have been open but they would have to have been forwarded to the internal machine running his P2P application. That would have required an explicit configuration action on his part. I *think* this assertion is incorrect. The firewall paper Sean referred us to *seems* to be describing a workaround for exactly this requirement. I don't fully understand how they do it (either the paper intentionally omits some key technical detail, or I just missed it). Lynn's suggestion above, a more succinct expression of the thought I talked about in rambly form, is probably closer to the target. The exception would be if the application is built on some standard technology like IRC where a masquerade module is available on Dachstein but not on Bering. -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Sunday 09 February 2003 08:58 pm, Sean wrote: I have been using Dachstein for a few years. I recently decided to give Bering a try. I use an app, EyeBall chat, to video chat to relatives. It worked just fine under Dachstein. It is NOT working under Bering. It appears the app uses a number of dynamic UDP and TCP connections for the audio/video portions of the chat. I didn't see anything in the shorewall logs that was helpful. Anyone got any thoughts? If there isn't anything in your logs, then likely the application has problems working with NAT. Personally, I would ask the company that writes the program what needs to be done to work with a stateful firewall (iptables). I would imagine that since it worked with Dachstein, there was probably some high port UDP traffic that iptables stops with conntrack (statefule connection tracking). -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
The solution was posted on their website. Apparently by default it uses dynamic UDP and TCP but there is a static port patch for v2.2 located here: http://www.eyeballchat.com/download/patches/fixed_ports_patch22.reg Then you need to open up these ports: Open the following ports in your firewall (may require assistance from your system administrator): - UDP ports 5700, 5701 and 5702 and - TCP ports 5500 and 5501. Eyeball Chat should then work correctly. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Lynn Avants Sent: Monday, February 10, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Re: [leaf-user] Bering/Shorewall vs. Dachstein On Sunday 09 February 2003 08:58 pm, Sean wrote: I have been using Dachstein for a few years. I recently decided to give Bering a try. I use an app, EyeBall chat, to video chat to relatives. It worked just fine under Dachstein. It is NOT working under Bering. It appears the app uses a number of dynamic UDP and TCP connections for the audio/video portions of the chat. I didn't see anything in the shorewall logs that was helpful. Anyone got any thoughts? If there isn't anything in your logs, then likely the application has problems working with NAT. Personally, I would ask the company that writes the program what needs to be done to work with a stateful firewall (iptables). I would imagine that since it worked with Dachstein, there was probably some high port UDP traffic that iptables stops with conntrack (statefule connection tracking). -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Bering/Shorewall vs. Dachstein
I have been using Dachstein for a few years. I recently decided to give Bering a try. I use an app, EyeBall chat, to video chat to relatives. It worked just fine under Dachstein. It is NOT working under Bering. It appears the app uses a number of dynamic UDP and TCP connections for the audio/video portions of the chat. I didn't see anything in the shorewall logs that was helpful. Anyone got any thoughts? Thanks, Sean p.s. www.eyeballchat.com if you want to see their software. I guess there is a way to restrict the app to some static ports, but i'm not to sure about opening ports to just anyone. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
