Re: [Openslp-users] OpenSLP, ports, and firewalls
I guess I was thinking about the line that talks about the destination port for all SLP messages... personally, I consider a reply an SLP message! :) There's not much I can set in my client... it's using the LiveTribe Java SLP package for the User Agent, and (like OpenSLP) it pretty much only lets me set the port for SLP or Notification messages. Defaults for them are the standard 427 and 1847, and I've changed the SLP port to match the port I'm using on the slpd server (1). Maybe it's time to look at the OpenSLP Java client instead... but if it's written to the rfc it would have the same issue. I can see where the rfc says to send replies and acks on the port from which they were received. But since those replies are not from a connected socket, that doesn't appear to make it very firewall friendly... unless I'm missing something. I'm now curious... how do other folks deal with SLP for their firewall config? Do they not use firewalls on each machine? Or just open both src and dest SLP ports? Once again, thanks for taking the time to look at this! 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...@wingedbeast.org mailto:ne...@wingedbeast.org 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 ssolo...@kynen.com mailto:ssolo...@kynen.com 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 ssolo...@kynen.com mailto:ssolo...@kynen.com 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 1 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 0-2 open, 1 for SLP and the other two for other client app usage. When I start up my client app, Wireshark shows me the
[Openslp-users] OpenSLP, ports, and firewalls
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 1 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 0-2 open, 1 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. SourceDestination Protocol Info 5 10.18.60.108 239.255.255.253 UDP Source port: 2 Destination port: 1 6 10.18.60.151 10.18.60.108 UDP Source port: 1 Destination port: 2 9 10.18.60.108 239.255.255.253 UDP Source port: 47672 Destination port: 1 10 10.18.60.151 10.18.60.108 UDP Source port: 1 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 1 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 1 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 1, 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 Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
Re: [Openslp-users] OpenSLP, ports, and firewalls
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 ssolo...@kynen.com mailto:ssolo...@kynen.com 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 1 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 0-2 open, 1 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. SourceDestination Protocol Info 5 10.18.60.108 239.255.255.253 UDP Source port: 2 Destination port: 1 6 10.18.60.151 10.18.60.108 UDP Source port: 1 Destination port: 2 9 10.18.60.108 239.255.255.253 UDP Source port: 47672 Destination port: 1 10 10.18.60.151 10.18.60.108 UDP Source port: 1 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 1 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 1 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 1, 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
