So
syntax is as follow, editing out part of public address, this is on a router running pfsense (based on freebsd 11).
The intended action of the rule is for outgoing ipv6 requests that are trying to use external resolvers to be forced to use my internal resolver.
I had diagnosed using the firewall log and packet capture's.
The firewall log reports the source ip as the ip of my client machine (which is good) and the destination ip as I put in the rule for the redirect, so in other words the log indicates its working perfect.
The packet capture shows the request from the client machine, it shows the internal dns resolver replying to the request as well, so the packet capture indicates the 'rdr' rule is doing exactly as expected and the resolver is even sending a reply and the reply is going back to the exact correct address.
The issue is the dns request times out on the client machine meaning the reply isnt making it there. If I do a dns lookup directly to the 2001:fff:ffff:a6c3::1 ip which has the same src and dst combination, it works.
There is no deny rules been hit, I confirmed easily by adding log to the deny rules.
I then checked the packet capture for ipv4, and noticed something different.
Note that the dst ip address even tho its redirected, it is reporting the actual target ip for both the destination and the response source.
This is the outcome from the ipv6 test
Notice that the dst ip is rewritten to the actual diverted destination.
I checked the sysctl's.
net.inet6.ip6.forwarding: 1
net.inet6.ip6.redirect: 1
I set net.inet6.ip6.forwarding=0, I had a random hunch that perhaps it was trying to reply to the wrong interface for some odd reason.
Bam suddenly I get the replies and also this from packet capture. Note it no longer is reporting the redirected ip and is now behaving same as ipv4.
But of course with forwarding disabled my devices have no access to the internet over ipv6. This would seem to be a bug.
For reference the ipv4 rdr.
So to summarise the inconsistent behaviour between protocols.
ipv4 forwarding enabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, successful redirect and reply.
ipv6 forwarding enabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, however the reply never makes it back to the client, redirect and reply failed.
ipv6 forwarding disabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, reply arrives, redirect seemingly works but forwarding been disabled stops it been a router for ipv6 packets.
syntax is as follow, editing out part of public address, this is on a router running pfsense (based on freebsd 11).
Code:
rdr pass log on igb1.1 inet6 proto { tcp udp } from any to !fe80::1:1 port 53 -> 2001:fff:ffff:a6c3::1The intended action of the rule is for outgoing ipv6 requests that are trying to use external resolvers to be forced to use my internal resolver.
I had diagnosed using the firewall log and packet capture's.
The firewall log reports the source ip as the ip of my client machine (which is good) and the destination ip as I put in the rule for the redirect, so in other words the log indicates its working perfect.
The packet capture shows the request from the client machine, it shows the internal dns resolver replying to the request as well, so the packet capture indicates the 'rdr' rule is doing exactly as expected and the resolver is even sending a reply and the reply is going back to the exact correct address.
The issue is the dns request times out on the client machine meaning the reply isnt making it there. If I do a dns lookup directly to the 2001:fff:ffff:a6c3::1 ip which has the same src and dst combination, it works.
There is no deny rules been hit, I confirmed easily by adding log to the deny rules.
I then checked the packet capture for ipv4, and noticed something different.
Code:
22:33:02.955413 IP 192.168.1.124.62728 > 8.5.8.8.53: UDP, length 38
22:33:02.955511 IP 8.5.8.8.53 > 192.168.1.124.62728: UDP, length 106Note that the dst ip address even tho its redirected, it is reporting the actual target ip for both the destination and the response source.
This is the outcome from the ipv6 test
Code:
22:35:02.628389 IP6 2001:fff:ffff:a6c3::124.60510 > 2606:4700:4700::1113.53: UDP, length 90
22:35:02.628500 IP6 2001:fff:ffff:a6c3::1.53 > 2001:fff:ffff:a6c3::124.60510: UDP, length 152Notice that the dst ip is rewritten to the actual diverted destination.
I checked the sysctl's.
net.inet6.ip6.forwarding: 1
net.inet6.ip6.redirect: 1
I set net.inet6.ip6.forwarding=0, I had a random hunch that perhaps it was trying to reply to the wrong interface for some odd reason.
Bam suddenly I get the replies and also this from packet capture. Note it no longer is reporting the redirected ip and is now behaving same as ipv4.
Code:
22:38:02.405792 IP6 2001:fff:ffff:a6c3::124.51567 > 2606:4700:4700::1113.53: UDP, length 90
22:38:02.405874 IP6 2606:4700:4700::1113.53 > 2001:fff:ffff:a6c3::124.51567: UDP, length 152But of course with forwarding disabled my devices have no access to the internet over ipv6. This would seem to be a bug.
For reference the ipv4 rdr.
Code:
rdr pass on igb1.1 proto { tcp udp } from any to !192.168.1.252 port 53 -> 192.168.1.252So to summarise the inconsistent behaviour between protocols.
ipv4 forwarding enabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, successful redirect and reply.
ipv6 forwarding enabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, however the reply never makes it back to the client, redirect and reply failed.
ipv6 forwarding disabled, rdr enabled, dns request to internet routable ip.
result is served by pfsense dns resolver, reply arrives, redirect seemingly works but forwarding been disabled stops it been a router for ipv6 packets.