Solved IPv6 client first try

D

Deleted member 45312

Guest


Dear FreeBSD users,

My first IPv6 try with my FreeBSD desktop machine was a bit disappointing.
According to FreeBSD Handbook, I added two lines in my /etc/rc.conf:
Code:
ifconfig_re0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
I added into my fully functional /etc/pf.conf:
Code:
icmp6_types = "{ echoreq, unreach, 133, 134, 135, 136, 137 }"
antispoof quick for $ext_if_adsl inet6
pass inet6 proto icmp6 all icmp6-type $icmp6_types keep state
After reboot I was scared to discover that all my running services was available on the Internet !
So I ran pfctl -s rules and result : nothing, PF was not loaded !
I had to manually run pfctl -v -f /etc/pf.conf to get my rules loaded and functional.
After investigations, I discovered that the statement
Code:
rtsold_enable="YES"
was the problem. After commented out this statement and rebooted, PF rules was loaded at startup and all is working flawlessly.

Code:
FreeBSD 11.1-RELEASE GENERIC  amd64
$ freebsd-version -uk
11.1-RELEASE-p4
11.1-RELEASE-p6
 
OP
OP
D

Deleted member 45312

Guest


I have tried with IPFW and no problems, rules are loaded.
The problem persist with PF.

Any idea somebody ?
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

Dear dlegrand,
I wanted to reply earlier, but since I have also just started with IPv6 it took some longer than expected. For my first tests I used ipfw(8). Now I tried to reproduce your situation with a quite useless firewall configuration as below
Code:
pass in all keep state
pass out all keep state
After reboot pfctl -s rules shows
Code:
pass in all flags S/SA keep state
pass out all flags S/SA keep state
as expected. IPv6 traffic is running as I monitor with tcpdump ip6 -i bge0 -n. If you could provide a simple rule set which is worth to be called ruleset for a firewall I could test again. About rtsold(8) I think it is necessary to make use of the advertisments. Now I will try to switch it off. As far as I have read net/dhcp6 would be a different method. But I have not tested it up to now.
 
OP
OP
D

Deleted member 45312

Guest


Dear dlegrand,
I wanted to reply earlier, but since I have also just started with IPv6 it took some longer than expected. For my first tests I used ipfw(8). Now I tried to reproduce your situation with a quite useless firewall configuration as below
Code:
pass in all keep state
pass out all keep state
After reboot pfctl -s rules shows
Code:
pass in all flags S/SA keep state
pass out all flags S/SA keep state
as expected. IPv6 traffic is running as I monitor with tcpdump ip6 -i bge0 -n. If you could provide a simple rule set which is worth to be called ruleset for a firewall I could test again. About rtsold(8) I think it is necessary to make use of the advertisments. Now I will try to switch it off. As far as I have read net/dhcp6 would be a different method. But I have not tested it up to now.
Thank you very much for your reply chrbr,
With your minimal PF rule set I get the same result as yours. Here is my minimal rule set which is triggering the problem :
Code:
ext_if = "em0"

# ICMP types to allow
icmp_types  = "{ echoreq, unreach }"
icmp6_types = "{ echoreq, unreach, 133, 134, 135, 136, 137 }"

# Don't send rejections. Just drop.
set block-policy drop

# Exempt the loopback interface to prevent services utilizing the
# local loop from being blocked accidentally.
set skip on lo0

# all incoming traffic on external interface is normalized and fragmented
# packets are reassembled.
scrub in on $ext_if all fragment reassemble

# set a default deny policy.
block in log all

# This is a desktop so be permissive in allowing outgoing connections.
pass out quick modulate state

# Enable antispoofing on the external interfaces
antispoof quick for $ext_if inet
antispoof quick for $ext_if inet6

# block packets that fail a reverse path check. we look up the routing
# table, check to make sure that the outbound is the same as the source
# it came in on. if not, it is probably source address spoofed.
block in quick from urpf-failed to any

# Allow ICMP
pass inet proto icmp all icmp-type $icmp_types keep state
pass inet6 proto icmp6 all icmp6-type $icmp6_types keep state
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

So I ran pfctl -s rules and result : nothing, PF was not loaded !
I had to manually run pfctl -v -f /etc/pf.conf to get my rules loaded and functional.
After investigations, I discovered that the statement
Code:
rtsold_enable="YES"
was the problem. After commented out this statement and rebooted, PF rules was loaded at startup and all is working flawlessly.
I could reproduce that behaviour.
 
OP
OP
D

Deleted member 45312

Guest


chrbr,
I found the line which prevent my rule set to load :
Code:
antispoof quick for $ext_if inet6
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

I found the line which prevent my rule set to load :
Code:
antispoof quick for $ext_if inet6
I have almost no idea about pf(4). What is the effect of the command or what if it is skipped? Now I will try to reproduce that as well.
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

dlegrand,
I can reproduce that as well. I forgot to mention that I have the line as below in /boot/loader.conf
Code:
net.inet6.ip6.accept_rtadv="1"
This setting has been zero. As far as I remember the change was necessary to get IPv6 working. How about your system?
 
OP
OP
D

Deleted member 45312

Guest


Antispoofing is blocking packets that appear on interfaces traveling in directions that aren’t logically possible.
But what is the interaction between rtsold and the antispoof rule ?
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

Antispoofing is blocking packets that appear on interfaces traveling in directions that aren’t logically possible.
But what is the interaction between rtsold and the antispoof rule ?
I would not wonder if the antispoof rule would prevent rtsold from working. But it should never be the other way around. I guess you have managed to find some regression or bug. The firewall should never be disabled by some other more or less unrelated tool.
 
OP
OP
D

Deleted member 45312

Guest


Code:
$ sysctl net.inet6.ip6.accept_rtadv
net.inet6.ip6.accept_rtadv: 0
But IPv6 is working, my interface is up and my public ipv6 is allocated.
 
OP
OP
D

Deleted member 45312

Guest


I would not wonder if the antispoof rule would prevent rtsold from working. But it should never be the other way around. I guess you have managed to find some regression or bug. The firewall should never be disabled by some other more or less unrelated tool.
You're right, I was scared to discover this problem.
 

Trihexagonal

Daemon

Reaction score: 897
Messages: 1,558

Doesn't it stop processing rules at this point?

Code:
pass out quick modulate state
Edit: I'm thinking this should be your last rule.
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

But IPv6 is working, my interface is up and my public ipv6 is allocated.
Ok, I have tried to disable it and this setting works, too. I have to dig the exact meaning. At my first tests I have blocked all advertisments by the firewall o_O. I assumed the setting to be the root cause.
 
OP
OP
D

Deleted member 45312

Guest


I think we should investigate for a timing problem at PF launch, because there is no problem with static IPv6. It seems that PF is loading the rule set before IPv6 is up on the network interface.
 
OP
OP
D

Deleted member 45312

Guest


But in all cases the network traffic should be blocked by pf. It's a very bad bug.
 
OP
OP
D

Deleted member 45312

Guest


Found it, it's not a bug. The line in /etc/pf.conf should be :
Code:
antispoof quick for ($ext_if) inet6
because the IPv6 address is dynamic (see parenthesis).
 
OP
OP
D

Deleted member 45312

Guest


But I think it's a bit nasty, PF should block the traffic by default !
 
OP
OP
D

Deleted member 45312

Guest


Doesn't it stop processing rules at this point?

Code:
pass out quick modulate state
Edit: I'm thinking this should be your last rule.
It's not a router, it's my desktop computer so I am permissive on outgoing traffic. If I am permissive, I don't need to evaluate further rules.
 

Trihexagonal

Daemon

Reaction score: 897
Messages: 1,558

It's not a router, it's my desktop computer so I am permissive on outgoing traffic. If I am permissive, I don't need to evaluate further rules.
That was exactly my point.

Unless I'm mistaken this is applicable for the rule I referenced:

The quick keyword

As indicated earlier, each packet is evaluated against the filter ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the filter rules. The last matching rule wins. There is an exception to this: The quick option on a filtering rule has the effect of canceling any further rule processing and causes the specified action to be taken.
https://www.openbsd.org/faq/pf/filter.html#quick


So nothing after that is processed if I'm interpreting it correctly.

Code:
# This is a desktop so be permissive in allowing outgoing connections.
pass out quick modulate state

# Enable antispoofing on the external interfaces
antispoof quick for $ext_if inet
antispoof quick for $ext_if inet6

# block packets that fail a reverse path check. we look up the routing
# table, check to make sure that the outbound is the same as the source
# it came in on. if not, it is probably source address spoofed.
block in quick from urpf-failed to any

# Allow ICMP
pass inet proto icmp all icmp-type $icmp_types keep state
pass inet6 proto icmp6 all icmp6-type $icmp6_types keep state
And it should come last. I'm not an expert though. Perhaps Sir Dice or someone who is can provide input.
 
OP
OP
D

Deleted member 45312

Guest


And it should come last. I'm not an expert though. Perhaps Sir Dice or someone who is can provide input.
This rules does not match for ingoing traffic, so it does not prevent following rules to be evaluated. I put this rule on top because I don't need to evaluate further for outgoing traffic. It's a waste of time and CPU usage.
 

chrbr

Aspiring Daemon

Reaction score: 243
Messages: 676

Hello dlegrand,
I have been digging how to have some kind of correspondance of lo1 with respect to ipv6. I found by chance https://unix.stackexchange.com/questions/295103/freebsd-pf-firewall-doesnt-work-on-restart about some other problem related to the order of starting services. The main message is
Code:
You don't show any of your pf.conf rules, but my guess is that they use static interface configuration.
Normally, hostname lookups and interface name to address translations are carried out when the rules are loaded.
If a hostname or IP address changes, the rules need to be reloaded to update the kernel. However, you can
change this behaviour by surrounding interface names (and any optional modifiers) in parentheses, which will
cause the rules to update automatically if the interface's address changes.
Short story: I have changed the antispoof lines as above to
Code:
antispoof quick for ($ext_if) inet
antispoof quick for ($ext_if) inet6
and the issue disappeared. pfctl -s rules showed a list of rules instead of nothing. I have not confirmed if all rules are in and in original condition. I hope it helps. May be for people with more knowledge than I have it is already an explanation :rolleyes:.

EDIT: Ok, after log out I have seen in all your messages above that you have already found that out... Sorry for the noise.
 
OP
OP
D

Deleted member 45312

Guest


Short story: I have changed the antispoof lines as above to
Code:
antispoof quick for ($ext_if) inet
antispoof quick for ($ext_if) inet6
and the issue disappeared. pfctl -s rules showed a list of rules instead of nothing. I have not confirmed if all rules are in and in original condition. I hope it helps. May be for people with more knowledge than I have it is already an explanation :rolleyes:.

EDIT: Ok, after log out I have seen in all your messages above that you have already found that out... Sorry for the noise.
Many thanks for your involvement in solving this problem. I am closing this thread as solved.
 
Top