PDA

View Full Version : client-side firewall issues



nico
2007-03-16, 12:09
Lots has been written about opening 9000 & 3483 on the server-side firewall, but I have hit an issue i believe concerns the client-side firewall. My topography looks like this:

SB <-> client_side_fw <-> (WAN) <-> server_side_fw <-> SS

In other words my squeezebox and softsqueeze clients are connecting to my slimserver across the Internet. The clients are located at my work, the server at home.

recently we upgraded our firewall at work to a beast that has a lot more features (SonicWall PRO 2040); after that the clients stopped working. The control channels (eg display) work, but no streaming audio. also the http web interface is ok, as is stream.mp3 playback over the 9000 tcp channel. Trying to figure out what the problem is with the clients.

i know many firewalls have a default rule that allows a LAN client to initiate a tcp connection to any external (WAN) server. thus the slim HELO protocol on tcp:3483 is working fine. but then if the server responds by sending UDP packets or tries to initiate a new tcp connection on a different port (eg 9000) back to that client, the client-side firewall will block that incoming traffic unless a rule has been set up. UDP poses extra problems as it's a connectionless protocol so there's no notion of "initiating a connection".

Does anyone know if the *server* initiates any tcp connections back to the client? Or whether the stateless UDP packets from server to client could be the problem?

TIA,
Nico

nico
2007-03-16, 14:29
I think I nailed the basic problem.... the Sonic Wall had a "content filtering" security service enabled and was snooping the packets coming out of the client. When I pressed "play" the client initiates a tcp connection to the server on port 9000 and sends the request "GET /stream.mp3". The sonic wall thought this was some kind of http request and was waiting for the remainder of the http header to follow before deciding what to do with it. Ultimately it ended up discarding the packet and not forwarding it to the server (because it's really not a proper http request). When I switched this feature off, the client immediately started working.

But there is perhaps one lingering problem. What happens when you drive the client from the http web browser UI? I can imagine the following sequence:

1. client starts and contacts the server on tcp:3483, says HELO
2. user then sees the new client appear on the http UI
3. user selects music to play for that player via the http ui
4. what happens now? does the server connect back to the client to stream the music? or does it send a control message on the already-establised 3483 socket telling the client what to play, then the client initiates the connection to the server on tcp:9000 and requests the audio stream?

snarlydwarf
2007-03-16, 14:37
Ultimately it ended up discarding the packet and not forwarding it to the server (because it's really not a proper http request).

It is a proper HTTP 0.9 request.



4. what happens now? does the server connect back to the client to stream the music? or does it send a control message on the already-establised 3483 socket telling the client what to play, then the client initiates the connection to the server on tcp:9000 and requests the audio stream?

The client and server already have a connection on 3483. It should send a "STRM" command to the client telling it to fetch the next file. The client then would make a request to port 9000 for the next file. (It would do this whether using the web interface or the remote... remember the client has no clue what a playlist is.)

nico
2007-03-16, 16:57
Cool! Thanks so much for clearing this up.