Unusual behaviour on my custom pfsense box with broadcasts
-
Hi there,
I have rolled my own pfsense box and integrated some commercial software into it.
2 services are run, I will call them client and server.
server is configured to listen on *:9999 (udp4)
when client is started, it broadcasts on 255.255.255.255:9999 to find any available servers.
With TCPDUMP I can see the broadcast packets, yet the server just doesnt see them, and therefore doesnt reply to the client??The funny thing is, that I have seen the same problem on some distros of linux (suse 10.2 for example).
I get the feeling that there is some network setting that is incompatible with the way my software does its broadcasts, and this network setting (or lack thereof) also exists in freebsd.
Anyone got any ideas?
Many thanks,
craig -
Have you configured the firewall rules to allow incoming broadcasts? If you run tcpdump on the pfSense host in non-promisc mode does it see the packets?
-
The firewall is set to allow all traffic, no block rules at all.
How can I do what you ask with regard to promiscuous mode. I did a tcpdump from the web interface.
-
Also just want to reiterate that the client/server software is actually running on the pfsense box itself
-
hmm I am making progress.
route get 255.255.255.255 showed that the default route for 255.255.255.255 requests were going out to my upstream router, 192.168.20.254 (which happens to be a vanilla pfsense box )
I thought maybe the broadcasts were going out to this box, and not coming back for the server software to see, so I did this :
route add 255.255.255.255 192.168.20.149 (my own boxes IP), suddenly, the server daemon is seeing the broadcasts :)
If someone could explain that to me it would be great, is it the fault of my upstream firewall?
Anyway, now I believe I am getting other problems, the server software thinks the broadcast packet is coming from 0.0.0.0, not the actual IP address which is 192.168.20.149
-
I think you need to get onto the command line ;)
If you've defined a route for the global (or local) broadcast address then that will cause you problems. From the command line what does "netstat -rn" show?
-
$ netstat -rn
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.20.149 UGS 0 752 em0
10/24 link#1 UC 0 0 vr0
127.0.0.1 127.0.0.1 UH 1 32072 lo0
192.168.20 link#2 UC 0 0 em0
192.168.20.20 00:13:20:18:47:05 UHLW 1 990 em0 1190
192.168.20.149 127.0.0.1 UGHS 2 0 lo0
192.168.20.254 00:01:02:a5:14:e8 UHLW 1 244 em0 707
192.168.20.255 ff:ff:ff:ff:ff:ff UHLWb 1 11 em0
255.255.255.255 192.168.20.149 UGHSb 0 6180 em0this is after ive been fcking round with the route add command tho, the default gateway should be 192.168.20.254
-
Try removing the route for the global broadcast address - what happens then? What happens if the client uses the network broadcast address?
-
thats the thing, I have just checked the windows version of client/server and the client does it's broadcast on 192.168.20.255 as opposed to to 255.255.255.255 whilst running on Freebsd.
The client is definitely supposed to broadcast to 192.168.20.255
Any ideas why the client is broadcasting to 255.255.255.255 instead? Is there a way of changing this? (assuming of course that it is NOT a bug in the client)
-
pfSense is FreeBSD ;)
Without knowing the software you're working with there isn't really any way to help.
-
It's more of a generic question.
Assume that the client looks at a specific system setting to determine which broadcast address to use, where is it getting 255.255.255.255 from?
Or is it falling back to 255.255.255.255 because it cannot determine the subnet broadcast address.
-
Not sure, I'm not a programmer (and you've still not said what software you're using that's doing this) so I couldn't say how it's worked out. It may well be falling back to the global broadcast address because it's intended route fails, but it's all speculation on my behalf.
