Re: [Openslp-users] OpenSLP, ports, and firewalls
Brought to you by:
jcalcote
Menu
▾
▴
Re: [Openslp-users] OpenSLP, ports, and firewalls
|
From: Steve S. <sso...@ky...> - 2012-01-10 18:44:32
|
Hey Nick, I looked into changing the LiveTribe SLP code so that it uses a defined port for the client UDP socket - just like you mentioned - and got it working. I'll have to open two ports, but that's better than opening them all! Once again, thanks for all the help. Steve On 01/10/2012 11:17 AM, Nick Wagner wrote: > Ok, looking at the first paragraph I think I misused "requests" and > "responses" a few times. What I meant to say was that if all clients > must listen to the SLP port to receive a response to their request, on > a single machine all client applications must listen on the same UDP > socket. That would require the client functionality to live in the > service/daemon. > > On Tue, Jan 10, 2012 at 10:12 AM, Nick Wagner <ne...@wi... > <mailto:ne...@wi...>> wrote: > > Is there any way you can force the client to use a port? Using > the SLP port for client reception would require that all client > responses are forwarded through a service/daemon, because there > can be only one socket receiving those requests and multiple apps > on the machine may need to perform requests. That's the reason the > SA & DA functionality is in a service. > > The section I'm referring to is 6.1 in RFC 2608. I can see how it > might be slightly ambiguous, as it states that the SLP port is the > destination port for all SLP messages, but a following sentence > clarifies how replies are acknowledgements are to be sent. > > --Nick > > > > On Mon, Jan 9, 2012 at 7:10 PM, Steve Soloski <sso...@ky... > <mailto:sso...@ky...>> wrote: > > > Hi Nick, > > The only problem with that is that the client will pick random > ports for sending out it's messages. For example, in the > snippet from below the AttrRqst message went out on port > 47672, so that was the destination port for the AttrRply > message. In other testing, I've seen various ports used for > sending from the client... which makes sense. However, since > this happens, I can't see any way - other than opening the > firewall on the source port - that will let inbound server > messages come in by just opening on a destination port. > > I'll look again, but I don't remember seeing that the replies > are sent to the to requesting port... if a connection has been > made between client and server, I could understand that. But > since the request is being made Multicast (ie connectionless) > and the reply is Unicast, I'm not sure how going back to that > same (random) port would be a good thing - at least from a > firewall perspective. > > Thanks for a quick reply, though! > > Steve > > > > > > On 01/09/2012 07:16 PM, Nick Wagner wrote: >> OpenSLP does make use of existing UDP sockets for sending >> responses, so you're right that the source port is the same >> as the multicast destination. But I don't think that's >> really the issue here. From my reading of the SLP spec, >> replies and acknowledgements are sent to the port from which >> the request was issued. So it makes sense to me that the >> responses have the destination ports listed. >> >> Could you configure the firewall to open the ports used by >> the clients for receiving as well? >> >> --Nick >> >> On Mon, Jan 9, 2012 at 1:32 PM, Steve Soloski >> <sso...@ky... <mailto:sso...@ky...>> wrote: >> >> I'm running slpd (from OpenSLP 20.0 beta 2) and am having >> an issue with >> my Fedora 15 firewall; I think it's a problem with >> OpenSLP but I wanted >> to get some input first. >> >> My client is a Java app running LiveTribe SLP; I've >> changed my SLP port >> from the default of 427 to 44441 due to Linux security >> issues. My client >> is at address 10.18.60.108, the slpd server is at address >> 10.18.60.151. >> My firewall has ports 44440-44442 open, 44441 for SLP and >> the other two >> for other client app usage. >> >> When I start up my client app, Wireshark shows me the >> following trace >> (some messages deleted for clarity): >> >> No. Source Destination Protocol Info >> 5 10.18.60.108 239.255.255.253 UDP Source port: >> 44442 >> Destination port: 44441 >> 6 10.18.60.151 10.18.60.108 UDP Source port: >> 44441 >> Destination port: 44442 >> 9 10.18.60.108 239.255.255.253 UDP Source port: >> 47672 >> Destination port: 44441 >> 10 10.18.60.151 10.18.60.108 UDP Source port: >> 44441 >> Destination port: 47672 >> 11 10.18.60.108 10.18.60.151 ICMP Destination >> unreachable >> (Host administratively prohibited) >> >> Line 5 is the clients SrvRqst message, looking for a >> specific service on >> the server. On line 6, the server responds with a SrvRply >> message, >> indicating that the service was found. Line 9 is the >> client asking for >> the services attributes with an AttrRqst message, the >> server replies on >> line 10 with an AttrRply message. So far, so good - I >> found the service, >> and got it's attributes... but then come the firewall. >> >> When I open a firewall port using system-config-firewall, >> Fedora opens >> the destination port, which makes sense... I wouldn't >> want to have my >> ports open based on the messages source port. So, if you >> look at the >> above, shouldn't the replies from the server - lines 6 an >> 10 - have >> their destination port set to 44441 instead of their >> source port? That >> is the port that I'm using for my SLP messages, and the >> port that I >> (ultimately) want to open on my client. If I only had >> port 44441 open, I >> would have blocked all of the messages coming back from >> the server... as >> evidenced in what happens on line 11, when the server has >> sent back the >> attributes. If all of those messages from the server were >> sent to a >> destination port of 44441, then everything would work. >> >> It appears that slpd is responding on the same socket >> that it got the >> incoming message on, rather than on an outgoing socket >> for slp messages. >> It appears that the way slpd is currently my firewall is >> pretty useless. >> Am I missing something here? >> >> Any enlightenment would be appreciated! :) >> >> Steve >> >> >> ------------------------------------------------------------------------------ >> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you >> don't need a complex >> infrastructure or vast IT resources to deliver seamless, >> secure access to >> virtual desktops. With this all-in-one solution, easily >> deploy virtual >> desktops for less than the cost of PCs and save 60% on >> VDI infrastructure >> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >> _______________________________________________ >> Openslp-users mailing list >> Ope...@li... >> <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/openslp-users >> >> > > > |
