PF Why do these rules prevent IPV6 connectivity?

J

japoc

Hello,

as far as I can tell I've used this set of rules for months if not years on my FreeBSD server:

Code: 
tcp_internet_out="{53, 80, 443, 123, 11371}"
udp_internet_out="{53}"
ext_if=em0
set skip on lo0

block in log (all)
block out log (all)
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 1111 # custom ssh port
pass out quick on $ext_if inet proto tcp from ($ext_if) to any port $tcp_internet_out
pass out quick on $ext_if inet6 proto tcp from ($ext_if) to any port $tcp_internet_out
pass out quick on $ext_if inet proto udp from ($ext_if) to any port $udp_internet_out
pass out quick on $ext_if inet6 proto udp from ($ext_if) to any port $udp_internet_out
pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type echoreq
## allow icmp6 for getting address using IPv6 autoconfiguration from router
pass inet6 proto ipv6-icmp all icmp6-type routeradv
pass inet6 proto ipv6-icmp all icmp6-type routersol
## allow icmp6 for getting neighbor addressespass inet6 proto ipv6-icmp all icmp6-type neighbradv
pass inet6 proto ipv6-icmp all icmp6-type neighbrsol
## allow icmp6 echo, not required, but sometimes nice
pass in inet6 proto ipv6-icmp all icmp6-type echoreq
## pass icmp-types: unreachable, time exceeded, parameter problem
pass in inet6 proto ipv6-icmp all icmp6-type {1 3 4}

Now today I reinstall the server with these same rules. I also upgraded the server with FreeBSD 12.3 (I've only been using FreeBSD 11 so far) but I doubt it's related.
Do you have any clue why these rules prevent IPV6 connectivity?

I say they do because when I have these rules I can't do
Code: 
pkg search python
it hangs forever.
But
Code: 
pkg -4 search python
works.
When I flush the rules, both work. So it's a problem with the rules but what is it?

I'm adding my /etc/rc.conf here:

Code: 
zfs_enable="YES"
### Added by OVH - block start
# Network configuration (IPv4)
ifconfig_em0="inet xxx.xxx.xxx.xxx netmask 255.255.255.0 broadcast xxx.xxx.xxx.255"
defaultrouter="xxx.xxx.xxx.xxx"

# Network configuration (IPv6)
ifconfig_em0_ipv6="inet6 2001:41d0:xxxx:xxxx::1 prefixlen 128 accept_rtadv no_radr"
ipv6_network_interfaces="em0"
ipv6_default_interface="em0"
ipv6_defaultrouter="2001:41d0:xxxx:xxxx:xx:xx:xx:xx"
ipv6_route_ovhgw="2001:41d0:xxxx:xxxx:xx:xx:xx:xx -prefixlen 128 -interface em0"
ipv6_static_routes="ovhgw"

# Various options
dumpdev="AUTO"
clear_tmp_enable="YES"
accounting_enable="YES"

# Daemons
ntpd_enable="YES"
sshd_enable="YES"
local_unbound_enable="YES"
### Added by OVH - block end
hostname="xxxxxxxxxxxxxxxxx"
pf_enable="YES"
pflog_enable="YES"
pf_rules="/etc/pf.conf"

Any help would be greatly appreciated.
 
Why do you have a /128 prefix ? It is a known bug (well... there are a lot of things to be said about if it is a bug or not...) that the gw must fit within the net mask on FreeBSD, but not on linux.
 
Some of your syntax is off. You're missing spaces and quotation marks for starts. Consolidate your block rules, too.

Code: 
tcp_internet_out = "{ 53, 80, 443, 123, 11371 }"
udp_internet_out = "{ 53 }"
ext_if = "em0"

block log all

set skip on lo0

I'm not familiar with IPv6 so I have no idea what the parameters are you're trying to use. Only that they aren't defined, enclosed or quoted in any way and you have some rules marked routed in and none out.

You might want to set it to log traffic in /etc/rc.conf:

Code: 
pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
 
I'm pretty sure that a /64 is strictly required now if you use rtadv. A /128 makes sense only if you're configuring a point-to-point link like gif(4). If you use a /128 the network stack has no clue how to do the most rudimentary "broadcast" type operations (of course IPv6 doesn't have broadcasts but you get the idea) to reach the other nodes in the connected network segment.
 
Thanks for the replies. But what should I do?
I didn't decide the /128 prefix. As you can see in the comment in my /etc/rc.conf, this part of the config was generated by OVH during the installation.
Should I just change prefixlen to 64 and that's it? Can I do this? What would be the difference? Would that still work with the network?
I must admit I don't understand how ipv6 works and is configured.
 
I still have this problem and I don't understand why these firewall rules block outgoing IPv6 traffic. I tried changing the line ifconfig_em0_ipv6=... in the rc.confto use a prefixlen of 64, or a prefixlen of 48. The problem remains.
Total mystery to me. I don't see what the problem is with these simple pf rules but they block IPv6 traffic.

Note: it's another server now, running FreeBSD 11.2 instead of FreeBSD 12.3. The problem is the same with both servers.
 
japoc said:
use a prefixlen of 64, or a prefixlen of 48. The problem remains.
Click to expand...
Use the prefixlen you were given by the provider.

japoc said:
I don't see what the problem is with these simple pf rules but they block IPv6 traffic.
Click to expand...
At a quick glance it looks like you're not allowing NDP. Which is the IPv6 equivalent of IPv4's ARP. This should help, it did for me: https://content.pivotal.io/blog/a-barebones-pf-ipv6-firewall-ruleset

Also note the copy/paste problem on this line:
Code: 
## allow icmp6 for getting neighbor addressespass inet6 proto ipv6-icmp all icmp6-type neighbradv
That should probably be:
Code: 
## allow icmp6 for getting neighbor addresses
pass inet6 proto ipv6-icmp all icmp6-type neighbradv

japoc said:
running FreeBSD 11.2 instead of FreeBSD 12.3.
Click to expand...
Did you get 12.3 from the future? 12.1 hasn't even been released yet.
 
Here's the result of a few commands in case that would help.
(ip6only.me is a domain that is supposed to be accessible only via ipv6)

Code: 
fetch http://ip6only.me
after about 15 seconds hanging, I get:
fetch: http://ip6only.me: No route to host

Code: 
drill ip6only.me AAAA
Code: 
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10728
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; ip6only.me.	IN	AAAA

;; ANSWER SECTION:
ip6only.me.	7999	IN	AAAA	2607:f0d0:3802:84::128

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Wed Jun 19 17:50:46 2019
;; MSG SIZE  rcvd: 56

Code: 
route -6 show 2607:f0d0:3802:84::128
Code: 
   route to: 8210.0000.0000.0000.4800.2083.0d0f.7062.ip6.static.sl-reverse.com
destination: default
       mask: default
    gateway: 2001:41xx:x:xxff:ff:ff:ff:ff
        fib: 0
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
 
What does netstat -rn6 show? When looking at routes always use the -n option to prevent it from trying to reverse resolve the IP addresses. You're not interested in the hostnames, you need to see the exact IP addresses (regardless if it's IPv4 or 6) and ranges. Having an IP address resolved to a hostname only makes it more difficult.
 
SirDice said:
Use the prefixlen you were given by the provider.
Click to expand...
They set it to 128 in /etc/rc.conf but I keep reading on the internet that it's strange.

Also note the copy/paste problem on this line:
Code: 
## allow icmp6 for getting neighbor addressespass inet6 proto ipv6-icmp all icmp6-type neighbradv
That should probably be:
Code: 
## allow icmp6 for getting neighbor addresses
pass inet6 proto ipv6-icmp all icmp6-type neighbradv
Click to expand...
Man, thanks!! That was it. I don't know how I missed that for so long. There was a comma missing in my Python script and it caused two strings to become concatenated instead of being joined by a carriage return. And I didn't notice the problem even after reading and rereading the pf.conf that the script created.

Thank you!!

Did you get 12.3 from the future? 12.1 hasn't even been released yet.
Click to expand...
My cover has been blown.
 
japoc said:
They set it to 128 in /etc/rc.conf but I keep reading on the internet that it's strange.
Click to expand...
Yeah, for some reason OVH does something weird with their IPv6 setup. But the settings you have look similar to other users also on OVH, so they seem to do the job.

japoc said:
Man, thanks!! That was it. I don't know how I missed that for so long.
Click to expand...
In Dutch we call that "blindstaren" (English 'staring blind'). You get so fixated staring at a problem you overlook the obvious.
 
You must log in or register to reply here.
Back
Top