Solved [PF] Unbound drill -S not working properly with pf

M

mamalos

Hi all!

I am trying to set unbound by following the handbook (I am running FreeBSD 10.0-RELEASE-p9). When I run drill -S FreeBSD.org @8.8.8.8 using Google's DNS servers and have pf on, the DNSKEY response is blocked by pf. When pf is off, the query works just fine.

My pf.conf is very simple:
Code: 
block drop log all
pass out quick on em0 inet from $my_ip to any keep state

The output of tcpdump -netvi em0 host 8.8.8.8 shows:
Code: 
de:ad:be:ef > de:ad:ba:be, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 11059, offset 0, flags [none], proto UDP (17), length 68)
    1.2.3.4.56508 > 8.8.8.8.53: 57191+% [1au] A? freebsd.org. (40)
de:ad:ba:be > de:ad:be:ef, ethertype IPv4 (0x0800), length 397: (tos 0x0, ttl 49, id 20525, offset 0, flags [none], proto UDP (17), length 383)
    8.8.8.8.53 > 1.2.3.4.56508: 57191$ 2/0/1 freebsd.org. A 8.8.178.110, freebsd.org. RRSIG (355)
de:ad:be:ef > de:ad:ba:be, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 11060, offset 0, flags [none], proto UDP (17), length 68)
    1.2.3.4.51805 > 8.8.8.8.53: 16063+% [1au] DNSKEY? freebsd.org. (40)
de:ad:ba:be > de:ad:be:ef, ethertype IPv4 (0x0800), length 933: (tos 0x0, ttl 49, id 11762, offset 0, flags [none], proto UDP (17), length 919)
    8.8.8.8.53 > 1.2.3.4.51805: 16063$ 3/0/1 freebsd.org. DNSKEY, freebsd.org. DNSKEY, freebsd.org. RRSIG (891)
de:ad:be:ef > de:ad:ba:be, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 11062, offset 0, flags [none], proto UDP (17), length 68)
    1.2.3.4.59486 > 8.8.8.8.53: 31828+% [1au] DS? freebsd.org. (40)
de:ad:ba:be > de:ad:be:ef, ethertype IPv4 (0x0800), length 293: (tos 0x0, ttl 49, id 26672, offset 0, flags [none], proto UDP (17), length 279)
    8.8.8.8.53 > 1.2.3.4.59486: 31828$ 2/0/1 freebsd.org. DS, freebsd.org. RRSIG (251)
de:ad:be:ef > de:ad:ba:be, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 11063, offset 0, flags [none], proto UDP (17), length 60)
    1.2.3.4.57025 > 8.8.8.8.53: 56542+% [1au] DNSKEY? org. (32)
de:ad:ba:be > de:ad:be:ef, ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 49, id 31833, offset 0, flags [+], proto UDP (17), length 1500)
    8.8.8.8.53 > 1.2.3.4.57025: 56542$ 7/0/1 org. DNSKEY, org. DNSKEY, org. DNSKEY, org. DNSKEY, org. RRSIG, org. RRSIG, org. RRSIG[|domain]
de:ad:ba:be > de:ad:be:ef, ethertype IPv4 (0x0800), length 187: (tos 0x0, ttl 49, id 31833, offset 1480, flags [none], proto UDP (17), length 173)
    8.8.8.8 > 1.2.3.4: ip-proto-17

And the output of tcpdump -netvi pflog0 host 8.8.8.8 shows:
Code: 
rule 0..16777216/0(match): block in on em0: (tos 0x0, ttl 49, id 31833, offset 0, flags [+], proto UDP (17), length 1500)
    8.8.8.8.53 > 1.2.3.4.57025: 56542$ 7/0/1 org. DNSKEY, org. DNSKEY, org. DNSKEY, org. DNSKEY, org. RRSIG, org. RRSIG, org. RRSIG[|domain]
rule 0..16777216/0(match): block in on em0: (tos 0x0, ttl 49, id 31833, offset 1480, flags [none], proto UDP (17), length 173)
    8.8.8.8 > 1.2.3.4: ip-proto-17
From where we can see that there seems to be a problem with state keeping on the last sent packet from my IP (from port 57025), since its reply gets blocked from pf.

I suspect this must be a packet size issue, since the reply size (1500 bytes) is - I think - the max-limit of DNS UDP packets, but I am not sure, nor do I know how to resolve this problem.

Thank you all for your time in advance!
 
Open the port 53 tTCP besides 53 UDP. Yes, TCP, I am not drunk and try again. Then read the unbound.conf file which came with the port.
 
Oko said:
Open the port 54 tcp besides 54 udp. Yes tcp Iam not drunk and try again. Then read unbound.conf file which came with the port.
Click to expand...
Oko, are you sure you mean port 54 and not 53? Whatever the case, as you can see from my simple pf.conf, all outgoing TCP and UDP ports are open and if you see my tcpdump excerpts, the blocked replies are for UDP port 53 (not TCP) for a connection that should have been stateful.

Thank you for your answer.
 
  • Thanks
Reactions: Oko
It's already allowing all outgoing connections so opening ports is not the answer. How is the outgoing connection set up? Is MTU set up properly?
 
Add to /etc/pf.conf
Code: 
scrub on em0
Basically the packets you are getting as replies are too big so they must be fragmented. Since PF see two invalid "half" packets, there is no match. You can see this in the tcpdump(1) output from your pflog(4) interface as the second packet has no port. If you tell PF to reassemble fragments, which is the default when you enable scrubbing, PF will reassemble them then be able to match off the state of the outbound connection.
 
Thanks junovitch, this was the answer. I hoped I wouldn't have to scrub packets though, because I've had problems with packet reassembling in other pf based setups and some random sites.

Nevertheless, it works just fine, thanks again!

PS. How do I change the subject to RESOLVED in this new forum?
 
You must log in or register to reply here.
Back
Top