Firewall – All IPv6 traffic blocked by pf

firewallfreebsdipv6pf

The following pf.conf (FreeBSD 10.3) appears to be blocking all IPv6 traffic and I can't work out why.

tcp_inbound = "{ ssh, domain, http, https }"
tcp_outbound = "{ domain, http, https, imaps, smtps }"

udp_services = "{ domain, ntp }"

block all
pass proto udp to any port $udp_services keep state
pass out proto tcp to any port $tcp_outbound keep state
pass in proto tcp to any port $tcp_inbound keep state

# from https://help.github.com/articles/what-ip-addresses-does-github-use-that-i-should-whitelist/
table <github> { 192.30.252.0/22, 2620:112:3000::/44 }
pass out proto tcp to <github> port { ssh } keep state

pass proto icmp from any to any

How do I allow IPv6 traffic on the same services I allow for IPv4? I added explicit inet6 versions of each rule and it didn't seem to help. If I disable pf then the IPv6 traffic gets through fine.

Best Answer

By enabling logging I managed to work out that this is because the ICMP6 router solicitation was being blocked. Adding

pass proto ipv6-icmp from any to any

to the end of the file fixed the problem.

Related Solutions

Why Firewall Servers – Importance and Benefits

Advantages of firewall:

You can filter outbound traffic.
Layer 7 firewalls (IPS) can protect against known application vulnerabilities.
You can block a certain IP address range and/or port centrally rather than trying to ensure that there is no service listening on that port on each individual machine or denying access using TCP Wrappers.
Firewalls can help if you have to deal with less security aware users/administrators as they would provide second line of defence. Without them one has to be absolutely sure that hosts are secure, which requires good security understanding from all administrators.
Firewall logs would provide central logs and help in detecting vertical scans. Firewall logs can help in determining whether some user/client is trying to connect to same port of all your servers periodically. To do this without a firewall one would have to combine logs from various servers/hosts to get a centralized view.
Firewalls also come with anti-spam / anti-virus modules which also add to protection.
OS independent security. Based on host OS, different techniques / methods are required to make the host secure. For example, TCP Wrappers may not be available on Windows machines.

Above all this if you do not have firewall and system is compromised then how would you detect it? Trying to run some command 'ps', 'netstat', etc. on local system can't be trusted as those binaries can be replaced. 'nmap' from a remote system is not guaranteed protection as an attacker can ensure that root-kit accepts connections only from selected source IP address(es) at selected times.

Hardware firewalls help in such scenarios as it is extremely difficult to change firewall OS/files as compared to host OS/files.

Disadvantages of firewall:

People feel that firewall will take care of security and do not update systems regularly and stop unwanted services.
They cost. Sometimes yearly license fee needs to be paid. Especially if the firewall has anti-virus and anti-spam modules.
Additional single point of failure. If all traffic passes through a firewall and the firewall fails then network would stop. We can have redundant firewalls, but then previous point on cost gets further amplified.
Stateful tracking provides no value on public-facing systems that accept all incoming connections.
Stateful firewalls are a massive bottleneck during a DDoS attack and are often the first thing to fail, because they attempt to hold state and inspect all incoming connections.
Firewalls cannot see inside encrypted traffic. Since all traffic should be encrypted end-to-end, most firewalls add little value in front of public servers. Some next-generation firewalls can be given private keys to terminate TLS and see inside the traffic, however this increases the firewall's susceptibility to DDoS even more, and breaks the end-to-end security model of TLS.
Operating systems and applications are patched against vulnerabilities much more quickly than firewalls. Firewall vendors often sit on known issues for years without patching, and patching a firewall cluster typically requires downtime for many services and outbound connections.
Firewalls are far from perfect, and many are notoriously buggy. Firewalls are just software running on some form of operating system, perhaps with an extra ASIC or FPGA in addition to a (usually slow) CPU. Firewalls have bugs, but they seem to provide few tools to address them. Therefore firewalls add complexity and an additional source of hard-to-diagnose errors to an application stack.

Iptables – Firewall still blocking port 53 despite listing otherwise

I notice that zero packets have actually reached your iptables ACCEPT rules for DNS. I think it is likely that your iptables rules are specifying an inconsistent combination of conditions that never match incoming DNS queries.

In your case, your DNS ACCEPT rules specify that the incoming interface must be eth1, and the destination IP address must resolve to ns.node1.com. You should check whether incoming DNS queries to ns.node1.com can ever arrive over the eth1 network interface.

Another possibility is that you have another packet filter somewhere between your test client and your server that is blocking DNS packets.

Best Answer

Related Solutions

Why Firewall Servers – Importance and Benefits

Iptables – Firewall still blocking port 53 despite listing otherwise

Related Topic