View Single Post
Old 2nd January 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

You don't have to post over 1400 lines of tcpdump output.

The first thing you have to make sure is: Do I see the outgoing request packets and the incoming answers from a wired network host in those xterms? If something gets blocked it will show up in the tcpdump pflog0 xterm
That is to confirm that the basic debugging strategy works.

After confirmation repeat using a wireless client.
Now
Code:
13:17:00.243508 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0800 70: 192.168.2.254 > 192.168.2.99: icmp: host 17.149.36.197 unreachable
[code]If the firewall has been blocking does, the tcpdump -eni pflog0 xterm should show this type of blocked packets. Does it? If it does it means your pf.conf needs to be adjusted.

Analysis of the first couple of packets
Code:
13:16:40.908888 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0
[1n] [1au] ANY (Cache flush)? touchPod.local. (71)

A request to the 224.0.0.0 multicast block

13:16:40.911770 0800 91: 192.168.2.99.57739 > 83.169.185.161.53:
59379+ A? safebrowsing.clients.google.com. (49)

A DNS request source port 57739 -> dest port 53

13:16:40.919842 0800 211: 83.169.185.161.53 > 192.168.2.99.57739:
59379 7/0/0 CNAME clients.l.google.com.,[|domain]

The answer source port 53 ->  destination port 5773 
So these DNS requests have no trouble passing

13:16:41.157010 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0
[1n] [1au] ANY? touchPod.local. (71)
Looks like a DNS request packet to the 224.0.0.0 multicast block

13:16:41.261481 0806 42: arp who-has 169.254.255.255 tell 192.168.2.99
An ARP inquiry

13:16:41.406013 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0 [1n] [1au] ANY? touchPod.local. (71)
13:16:41.655503 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81)
Looks like  DNS request packets to the 224.0.0.0 multicast block

13:16:41.661492 0806 42: arp who-has 169.254.255.255 tell 192.168.2.99
An ARP inquiry

13:16:42.652756 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81)
13:16:44.667696 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81)
Repeated cache flush requests to 224.0.0.0 multicast block

13:16:44.667828 0800 44: 192.168.2.99.5353 > 192.168.2.254.5351:[|domain]
A truncated (by tcpdump)  DNS packet 

13:16:44.667962 0800 70: 192.168.2.254 > 192.168.2.99: icmp: 192.168.2.254 udp port 5351 unreachable
An icmp message informing 192.168.2.99 that udp prt 5351 cannot be reached 


13:16:44.668086 0800 170: 192.168.2.99.61471 > 192.168.2.254.1900: udp 128
13:16:44.668155 0800 70: 192.168.2.254 > 192.168.2.99: icmp: 192.168.2.254 udp port 1900 unreachable
A SSDP packet  and a message informing the sender that port 1900 cannot be reached
Open up ports 1900 and 5351 for UDP traffic and retry
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote